Колибри для встроенных систем?

Using Kolibri in embedded systems
  • Кстати говоря, до ревизии 1055 карусель возвращалась на старое место, после выхода из задачи v86.
    Потому-что нарушалась синхронизация 3-х вышеупомянутых магических переменных.
    Менялась только одна, а shed цеплялся за две неизменные...
    Это я только недавно понял, после сравнительного анализа ревизий в ответ на "fixed V86 task switch on IRQ broken in rev. 1055" :)
    Сегодня все правильно и синхронно, зато карусель сбоит. Не должна сбоить, даже теоретически.

    Ну а некое повышение приоритета - не производит впечатления. Этими вопросам должен заниматься shed.
    Точнее - вопрос дожен быть сконцентрирован в одном месте, а не размазан по всему репозиторию
    Мне так думается.

    Собственно я кажется все понял: в пункте в) надо не iret ловить, а факт открытия прерываний. Настоящие которые.
    И все становится на свои места.
    Это единственное стороннее использование do_change_task (которое было моей головной болью с самого начала) становится в один ряд с остальными прерываниями.
    Которые должны быть короткими, чтобы у разработчика встроенных систем были "некие гарантии"

    Да-да, я ничего не забыл, и супер-продвинутый RT-shed - за мной.
    Просто без понимания вышеобсужденного - рановато, мне казалось.
    И сейчас еще рановато. Но время придет
  • Чтобы у разработчика встроенных систем были "некие гарантии", необходимо тупо отключить работу через BIOS - иначе никаких гарантий не будет, а для встроенных систем с вполне предсказуемым железом достаточно реально написать все драйвера в конкретном случае.
  • Ну не знаю, неужели все так кошмарно...
    В смысле, что биос может закрыть прерывания на не контролируемое время.
    Неужели они там все без башки... Вряд ли, по-моему.

    Даже в ДОС-овские времена существовали "резиденты", которые могли форматировать дискету в фоновом режиме

    Главное-то в чем. Что бы появилась возможность создать реальную систему вовсе не надо гарантировать все и по любому поводу.
  • Насколько я понял, diamond говорит о необходимости глобальной перестройке ядра ОС, со сменой API, как следствие и GUI. Т.е. это означает, что придеться переписывать каждую программу. Режим V86, частный случай.
  • Ну в принципе - да, интересно бы уточнить
    Зацепимся за конкретную фразу :)
    diamond wrote:Если так определять абсолютные плюс и минус, то не в нашей власти выбирать, к какому из них двигаться - локальные изменения либо приведут к глобальным качественным, либо не приведут. Я склонен считать, что в данном конкретном случае - нет
    Ну во-первых, мне кажется, что в нашей... Типа, сила человеческой мысли - безгранична.
    Во-вторых, diamond, какие глобальные изменения ты считаешь необходимыми, которые мы никогда не сможем достигнуть "локальными" изменениями :?:
    Как-то, из твоего вышеизложенного списка, мне такой кошмар на глаза не попался... Ну или не понял.
    Last edited by Galkov on Wed Jun 17, 2009 11:04 am, edited 1 time in total.
  • Я предлагаю API функции, которые присуствуют сейчас в ядре вынести в подключаемую библиотеку. Сгруппировать функции по функциональности, дублирующие функции убрать. Частично вынести некоторый код в драйвера, разработать API взаимодействия драйвера с ядром ОС.
  • Ну и ладно, будем цитировать из другого топика :D
    diamond wrote:Мнэээ? Кто-то совсем недавно что-то говорил про гарантии, и мне казалось, что этот кто-то тоже подписывался ником Galkov. Ну а реальная система, которая вовсе не гарантирует всё и по любому поводу, - это и есть текущее состояние планировщика...
    Неправда Ваша, дяденька
    Никогда я не говорил, что надо гаранитровать ВСЕ, иначе типа полный кердык...
    С самого начала (этого топика) я говорил, что нужно сделать ВСЕГО ЛИШЬ две небольшие вещи, чтобы совершить качественный скачок: "применимость KoOS для встроенных систем"
    Это:
    • а) планировщик, который гарантированно предоставляет "сигнал" приложению не медленнее, чем за заранее заказанное время
      б) не "вешать" исполнение приложения прерываниями, или иными мероприятиями, на время сравнимое с квантом переключения задач. Как минимум, чтобы была возможность подобрать железо (ну там частота проца, шины, и т.п.) для выполнения этого.
    И все.
    После этого, я смогу решать, как минимум, некоторые задачи.
    И это качественный скачок - сегодня не могу.
    Естественно, в своем понимание того, что такое реальная система.
    А в чьем еще, если за конечный результат отвечать именно мне........

    Первое - мне представляется вполне преодолимым. Несколько увеличившиеся за последнее время, мои познания в архитектуре KoOS - не отменяют пока этого.
    Второе - преодолеваем по мере поступления. В первую очередь те вопросы, без которых не обойтись.
    Например, сбой карусели "кем ни попадя" - это ТАКОЙ вопрос.
    А вот ожидание мьютекса "потенциально неограниченное время" даже при конечном времени захвата - это уже НЕ такой вопрос.

    Ответственность оси - только время доставки сигнала (каковым также является и факт принудительнго по int0 прерывания исполнения), и предоставление временного ресурса для его обработки. Хочешь RT-характеристики - работай с монопольным захватом ресурсов, вот и вся проблема.
    Причем не проблема оси, а разработчика
    Монопольное - в широком смысле: в моем проекте могут быть несколько RT-потоков, которые общаются с моим же "драйвером" железа. Но это - мои проблемы а не оси. Всякий захват мьютекса "драйвера" я сделаю конечным во времени. Планировку предоставления ресурса моим (и ни чьим более) ожидающим потокам - так я этим как раз сейчас и занимаюсь.
    И если сигналы от мьютекса будут доходить клиентам за предсказуемое время - у меня все сварится.
    В том смысле, что именно я смогу отвечать за работоспособность именно моей системы.

    Да, общие системные ресурсы упоминались. Винт, Аллокатор памяти...
    И что :?: Это вовсе не отменяет возможности создания RT-приложения.
    Да, с винта загружу все в память. Подкачки страниц уже и так нет (как во всех уважающих себя RT-осях). Если возникнет необходимость подкачки данных, то сделаю это через не-RT-поток, с такими временными характеристиками, что по исчерпании половины которого, можно будет включить сирену в рабочем зале, чтобы оператор пришел и исправил положение. Без остановки технологического процесса. В конце концов, даже исполнение договора, в рамках которого и выполняется данный технологический процесс - это тоже процесс в реальном времени.
    Если системным аллокатором пользуются "все", то отстегну себе один раз сотню метров, и буду пользоваться своим, в 3-м кольце (каковой имеется практически во всех ЯВУ).

    То же мне проблемы...
    Проблема, это когда винда начинает менять размер файла подкачки, например :wink: Тут уже и "сирена" не поможет.
    Более приземленно: железо сигнализирует о готовности, а у меня нет гарантия, что я узнаю об этом раньше чем завтра - вот это проблема.
    Блин, народ ведь еще ДОС-ом пользоваться не прекратил, по всем этим причинам :)
    Ну вот, моя простенькая задача и заключается в том, чтобы лишить его поледней аргументации к этому.
  • Что-то не видно глубоких отличий между этим "всего лишь" и глобальным "всё". Если не отвлекаться на общефилософские рассуждения, а брать применительно к BIOS: BIOS может запрещать прерывания; никто ничего не гарантирует насчёт времени этих запретов (на практике оно мало, но ведь мы говорим о теоретических гарантиях); следовательно, при включённой поддержке железа через BIOS нельзя ничего гарантировать о времени доставки прерывания.
    Насчёт "Если системным аллокатором пользуются "все", то" - цитирую сам себя:
    diamond wrote:На всякий случай уточняю, если кто не понял: если первый пример можно было обойти, просто не обращаясь к жёстким дискам, то в этом примере независимо от крутости обработчика он может просто не получить вовремя управления из-за других процессов в системе.
    Повторяю ещё раз - это всего лишь пример блокировки, уже второй. Всего блокировок несколько сотен.
    Полный пост всё ещё можно просмотреть здесь: viewtopic.php?p=22153#p22153.
    Ушёл к умным, знающим и культурным людям.
  • diamond, ты озвучил достаточно фундаментальные мысли, которые раньше никто не осмеливался озвучивать. Но ты только описал ситуацию (хотя уже это радует), однако не стал делать выводов и каких либо предпосылок к каким бы то ни было решениям. ...?
    Я ни в коем случае этого не требую)
  • diamond wrote:Мда. Похоже, комментарий в конце поста хотя и услышали, но не восприняли. Ну ладно, попробую ещё раз.
    Есть много разных алгоритмов сортировки, в том числе быстрая (quicksort) и пирамидальная (heapsort). В среднем быстрая сортировка быстрее, но в худшем случае она ведёт себя просто ужасно. В ядре обычной системы имеет смысл использовать быструю сортировку вместо пирамидальной, потому что практически во всех случаях она быстрее. Но ядру RTOS быстрая сортировка категорически противопоказана, потому что теоретически вполне возможна ситуация "фатального невезения", когда быстрая сортировка будет выполняться слишком долго, а вот пирамидальная вполне подходит, хотя она в среднем и медленнее.
    Один момент применительно к Колибри. Есть такая функция, как alloc_page - выделение физической страницы. Которая вызывается из кучи разных мест всеми подряд и выполняется с запрещёнными прерываниями. Она не использует под необходимые структуры много памяти (всего по одному биту на каждую существующую физическую страницу, занята/свободна, плюс две вспомогательные переменные) и в типичной ситуации (практически во всех ситуациях) находит свободную физическую страницу очень быстро. Но легко представить ситуацию, при которой этой функции понадобится несколько миллионов тактов, что даже на гигагерцовых процессорах приводит к запрещению прерываний на несколько миллисекунд, а на процессорах послабее соответственно увеличивает время до вполне ощутимых макроскопических величин. Кроме того, порядок величины указан исходя из того, что сейчас Колибри не знает ничего ни о PAE, ни о x64 и адресовать память больше 4 Гб в принципе не может, а потенциально эту величину следует ещё увеличить пропорционально объёму памяти, что опять-таки становится вполне ощутимым временем, даже если несколько миллисекунд ничего не решают. Но попытки переделать эту конкретную функцию уже могут натолкнуться на сопротивление, если окажется, что в типичной ситуации оно замедляет процесс (функция, между прочим, критичная для производительности системы) или существенно раздувает объём необходимой памяти, пусть и снижает гарантированное время работы - то, что хорошо для RTOS, вовсе необязательно хорошо для обычной системы.
    На всякий случай уточняю, если кто не понял: если первый пример можно было обойти, просто не обращаясь к жёстким дискам, то в этом примере независимо от крутости обработчика он может просто не получить вовремя управления из-за других процессов в системе.
    Повторяю ещё раз - это всего лишь пример блокировки, уже второй. Всего блокировок несколько сотен.
    diamond wrote:... при организации связанным списком перебор делать всё равно придётся, чтобы при выделении непрерывного блока страниц найти блок нужной длины. А освобождение памяти превратится в кошмар из-за того, что нужно будет просмотреть все блоки с целью проверить, не нужно ли склеить только что освобождённый с каким-то из старых.
    Для менеджера памяти идеально подходит сортировка вставками в бинарное дерево. Поиск, сортировка и вставка в более-менее упорядоченном дереве в худшем случае занимают порядка log2N шагов. Чтобы добавить/удалить одну страницу памяти из тысячи, нужно не больше 10 шагов! Места для дерева требуется столько же, сколько и для двусвязного списка.

    Правда, в отсутствие "садовника" деревья имеют тенденцию "дичать", выбрасывая длинные "черенки" без ветвления, что в самом худшем случае вырождает всю структуру в односвязный список, поэтому время от времени система должна их приводить в божеский вид. Переподвешивание бинарного дерева - несложная операция, занимающая ровно 2 N log2N шагов - столько же, сколько в среднем нужно для быстрой сортировки. Безусловные плюсы налицо:

    1) аллокация памяти ускоряется в N раз и перестает быть RT-проблемой;

    2) упорядочение дерева требуется редко (скажем, после каждой сотни обычных вызовов менеджера памяти) и выполняется гарантированно быстро;

    3) система может проводить упорядочивание дерева без блокировки прерываний;

    4) можно объединить упорядочивание дерева с другой важной функцией - "сшивкой" смежных страниц памяти.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Для всех разработчиков (всех - это yogev_ezra и art_zh) - что думаете о статье о Колибри и Ко в самом крупном журнале индустрии? http://industrial-embedded.com/
  • А ссылка на статью есть ?
  • А сама статья вообще в природе есть?
  • Если я понял правильно, то он имел в виду, чтобы мы им предложили написать статью о Колибри. Ну предложить-то можно, только захотят ли они.
  • Who is online

    Users browsing this forum: No registered users and 3 guests