Пишу ОС РВ, Вот пишу ОС Реального времени, у какого какие предложения? пожелания? Опции

[ddiimmaa]

Знаю, знаю дело не шибко благодарное. И люди могут тухлыми помидорами закидать. "Мол зачем ещё одна ОС?". Развелось тут понимаешь ОСеписателей.

В своё время был без ума от FreeRTOS. И всем она казалась хороша. Однако, покопавшись понял, что можно сделать немного по другому и немного лучше.

В общем моя цель добится примерно анологичной функциональности, но с меньшим числом затрачиваемой RAM ибо эта штука есть очень дефицитная ;-). Ну и сделать как можно открытие, чтобы можно было людям дописывать то, что им нужно самим.

Исходя из выше сказанного -- никаких POSIX, ну и сфера применения МК с ОЗУ от 512 до 256кбайт (ну выше там наверно что другое пойдёт).

У кого какие пожелания?

Наставления?

Мнения?

Вопросы?

что вы скажете по поводу выбора лиценции?

Что кому нравиться не нарвиться в их осях?

[sergeeff]

Это для общего развития или сейчас творческий простой?

[ddiimmaa]

Это для общего развития или сейчас творческий простой?

Это нужен инструмент аля FreeRTOS но с меньшими аппетитами по RAM и с правом копаться в ядре, с тем чтобы получившееся можно было и в коммерческих разработках выдавать.

А scmRTOS?
Вроде бы как раз, для дохленьких контроллеров задумана, с полкилом рама, с минимизацией издержек.
Единственный минус (имхо) - написана на плюсах.
Хотя для кого-то это плюс.
По-моему, лучше подключиться к раскрученному проекту, чем начинать собственный с нуля

Вот вот в том то и дело что она Си плюс плюснутая. А так ничего ОC, правда тоже есть недочёты, в виде жёсткости системы приоритетов. Так например не может быть двух задач с одинаковыми приоритетами

Ну покажите класс. Кто вас знает, мож вы гений.
512 Kb RAM-а - это очень много. Не советую ориентироваться на такие числа.
Ограничтесь лучше 2-я Кб. Во всяком случае для uCOS, ThreadX, CMX и других мощных осей этого вполне хватает для пары тройки задач.

Ну конечно она должна влезать в сотни бацт по ОЗУ. Я это просто прикинул, что при 512 кб уже смысла нет ставить то, что я думаю

Вообще-то нынче каждый уважающий себя компилер идет с встроенной RTOS.
У CodeWarrior - MQX, у Keil - RL ARM, у Tasking - OSE, у IAR - PowerPac и т.д

Ну судя этой логике gcc -- не уважающий себя компилер

Этой уникальной фичей мог бы стать realtime профайлер.
Все как бы декларируют себя RTOS-ами, но реального тулса для тюнинга приоритетов задач, нарезок временных интервалов активности задач, тюнинга шедулеров в готовом дивайсе никто не предлагает. Всегда нужен PC, софтварный спец агент тормозящий приложение и захватывающий ресурс и IDE online.

А можно по подробнее что есть realtime профайлер и какую статистику он должен собирать?

Третья уникальная фича - проработка протокола вплоть до физического уровня межпроцессорного обмена.
Это оч востребованная фича, поскольку времена когда все делается на одном проце стремительно уходят.

Хм а вот тут тоже не совсем ясно? Что имееться в виду? Соединять несколько процов по какому-либо протоколу? С целью? Протокол обычно соответствует часто использемым функциям, т. е. реализует базовую функциональность чего-либо! А тут малость мне не понятно что может быть общего между различными устройствами в которых есть не один ЦП? И честно говоря, по этому ничего не видел ни инфы ни протоколов ни таких ОСей может подкините что-нибудь!

Для "немного" того-другого просто надо доработать ту-же FreeRTOS. Хотели немножко памяти? - небольшие резервы по памяти там прямо под ногами лежат.

Можно можно, но вот в один прекрасный день (хотя у нас в России пока на это мало глядят) мне тут скажут "мужик -- ты же доработал FreeRTOS" -- ну тогда у тебя проект на GPL -- давай выкладывай все свои исходники.

А при сильно сэкономить и сделать систему под 512 байт, так такая система будет уродлива уже для десяткокилобайтовых...

А как на ваш взгляд scmRTOS? Уродлива для десяткокилобайтовых?

Дык, assert - для примера только. Я текст с alloc() сразу поленился выложить. Так лучше?

Код

#if (DEBUG == 0)
#define MM_Alloc( a, b)                         \
         MM_AllocFree( a, b)
#else
#define MM_Alloc( a, b)                         \
         MM_AllocDebug( a, b, __LINE__, __FILE__)
#endif

Вот это да идея!!! первый раз такое вижу. Может буду применять. Честно говоря, меня шас память мало волнует. Больше приоритеты и прочее. И вообще мне не нравиться например что в FreeRTOS нельзя полностью работать на статической памяти.

[VslavX]

Посмотрите TN Kernel
Написана на чистом C, "понятным языком", хорошо структурирована. API сделано "по мотивам" спецификации uTRON 4.x - на таких ОС японцы большую часть своей электроники делают. Приоритеты не фиксированы, есть round-robin для задач с одинаковым приоритетом, есть механизмы борьбы с priority inversion, достаточно быстрая. Я на ней остановился после знакомства с uCOS и FreeRTOS. Еще очень понравилась scmRTOS - изящнейшая вещь, но я не настолько уверено "++" владею, и, к сожалению, узнал о ней уже после значительного "перелопачивания" TN.

[ddiimmaa]

Посмотрите TN Kernel
Написана на чистом C, "понятным языком", хорошо структурирована. API сделано "по мотивам" спецификации uTRON 4.x - на таких ОС японцы большую часть своей электроники делают. Приоритеты не фиксированы, есть round-robin для задач с одинаковым приоритетом, есть механизмы борьбы с priority inversion, достаточно быстрая. Я на ней остановился после знакомства с uCOS и FreeRTOS. Еще очень понравилась scmRTOS - изящнейшая вещь, но я не настолько уверено "++" владею, и, к сожалению, узнал о ней уже после значительного "перелопачивания" TN.

посмотрел

Код

//----- Task Control Block ------------
typedef struct _TN_TCB
{
   unsigned int * task_stk;  //-- Pointer to task's top of stack
   CDLL_QUEUE task_queue;    //-- Queue is used to include task in ready/wait lists
   CDLL_QUEUE timer_queue;   //-- Queue is used to include task in timer(timeout,etc.) list
   CDLL_QUEUE block_queue;   //-- Queue is used to include task in blocked task list only
                               // uses for mutexes priority seiling protocol
   CDLL_QUEUE create_queue;  //-- Queue is used to include task in create list only
   CDLL_QUEUE mutex_queue;   //-- List of all mutexes that tack locked  (ver 2.x)
   CDLL_QUEUE * pwait_queue; //-- Ptr to object's(semaphor,event,etc.) wait list,
                               // that task has been included for waiting (ver 2.x)
   struct _TN_TCB * blk_task; //-- Store task,that blocked our task(for mutexes's
                               // priority ceiling protocol only (ver 2.x)

   unsigned int * stk_start;          //-- Base address of task's stack space
   int   stk_size;           //-- Task's stack size (in sizeof(void*),not bytes)
   void * task_func_addr;    //-- filled on creation  (ver 2.x)
   void * task_func_param;   //-- filled on creation  (ver 2.x)

   int  base_priority;       //-- Task base priority  (ver 2.x)
   int  priority;            //-- Task current priority
   int  id_task;             //-- ID for verification(is it a task or another object?)
                               // All tasks have the same id_task magic number (ver 2.x)

   int  task_state;          //-- Task state
   int  task_wait_reason;    //-- Reason for waiting
   int  task_wait_rc;        //-- Waiting return code(reason why waiting  finished)
   int  tick_count;          //-- Remaining time until timeout
   int  tslice_count;        //-- Time slice counter

   int  ewait_pattern;       //-- Event wait pattern
   int  ewait_mode;          //-- Event wait mode:  _AND or _OR

   void * data_elem;         //-- Store data queue entry,if data queue is full

   int  activate_count;      //-- Activation request count - for statistic
   int  wakeup_count;        //-- Wakeup request count - for statistic
   int  suspend_count;       //-- Suspension count - for statistic

// Other implementation specific fields may be added below

}TN_TCB;

очень впечатляет во FreeRTOS и того меньше, ну да ладно нечего пинять на других коли сам не сделал

Там модифицированный GPL. Почитайте, ну может десять баксов пожертвуйте.... Ну и если действительно заметно доработали, то прежде, чем кто-то это скажет Вы сначала должны зачем-то выложить исходники Да и купить на самом деле можно OpenRTOS при малейшей необходимости - время дороже .

Мда, а если я хочу выложить исходники (ну типа посмотрите как я крут ), ну да ладно если бы да кабы.. да росли бы грибы....

[VslavX]

посмотрел

Код

//----- Task Control Block ------------
typedef struct _TN_TCB
{
...
}TN_TCB;

очень впечатляет во FreeRTOS и того меньше

Ужимается в полтора раза без потери функционала. У меня сейчас TCB составляет 22 слова. FreeRTOS имеет TCB поменьше (я 16 слов насчитал по-минимуму), конечно, но и функционал победнее. Из синхрообъектов TN очень хороши мутексы (владелец + управление приоритетом) и события (хоть какая-то замена WaitForMultipleObjects). В-общем - размер TCB - это еще не показатель.

[ddiimmaa]

Ужимается в полтора раза без потери функционала.

Странно! А вот интересно? А что же тогда автор не удосужился сам ужимать своё детище? или принимать заплатки от кого либо?

[VslavX]

Странно! А вот интересно? А что же тогда автор не удосужился сам ужимать своё детище? или принимать заплатки от кого либо?

Есть такой анекдот:

Жили-были в лесу серые мыши, жизнь у них была трудная и пошли они к мудрому Филину за советом:
- Мы, мыши серые, звери мелкие, все нас обидеть и съесть норовят. Скажи нам, Мудрейший из Мудрейших, как нам быть?
Филин, подумал, подумал, и говорит:
- А вы, мыши, станьте ежиками колючими, и никто вас тогда трогать не будет!
Мыши обрадовались, поблагодарили и собрались уже было уходить:
- Погоди, Мудрейший, а как же нам ежиками стать?
- Млин, ну чего вы ко мне с такой ерундой пристаете - я же только Стратегией занимаюсь! Вот!

Вот и авторы универсальных вещей точно так же - им думать про максимально широкий круг задач нужно, оптмизацией под конкретное применение пусть уже "мыши" занимаются .

Так вот он вообще придумал Contikki -- по два байта на поток. Правда у него не поток а протопоток (protothread). И реалтаймом не

Дык, "Контики" - плот он и есть плот. А хочется, если уж не лайнер (Linux/WinCE), то хотя бы океанскую яхту . Если ресурсы (финансовые или аппаратные ) позволяют. А современные недорогие массовые ARM-ы - типа LPC/SAM - "яхту" позволить вполне могут.
Ну океанскую или нет, а "река-море" - запросто.

[AlexandrY]

Что то непонятны ваши потуги интуитивно выразить мысль.

Есть скорость работы самой операционки на целевой платформе.
Есть скорость разработки приложения на базе операционки (определяется объемом middleware )
И есть скорость отладки приложения и поддержки либо на целевой платформе либо на host системе. (определяется интегрированными тулсами)
Эти скорости сильно противоречат обычно друг другу.
Поэтому лайнер здесь в проекции на другую плоскость будет трактором.

Малые RTOS нужны для малых процов.
Малых процов на самом деле становиться только больше.
Взять какой-нить netbook:
на HMI один, на управление питанием - другой, на расширяемый ввод-вывод - третий, спец коммуникации - четвертый и т.д.
И на каждый из них имеет смысл ставить RTOS чтобы ускорить разработку. И спрос на малые RTOS соответственно тоже растет.
И универсальность от них требуется достаточно большая и скорость тоже, поскольку от нее зависит энергопотребление.
Выбрав непродумано ось для этих применений можно сильно пролететь.

Заигрываться тоже понятно не стоит. Цена вопроса смены оси где-то месяц.
Но бывает что и это слишком долго поэтому пообсуждать вижу смысл.

А вот рассматривать малую RTOS в плане открытости лицензии или открытости тулсов не вижу смысла. На это есть рефакторинг.
Чем, подозреваю, автор и занимается.

Дык, "Контики" - плот он и есть плот. А хочется, если уж не лайнер

[VslavX]

Что то непонятны ваши потуги интуитивно выразить мысль.

Да я ничего особенного выразить не хотел - топикстартер начал размеры TCB обсуждать, поэтому я привел образное сравнение плавсредств - меньше размер/меньше удобств. Само средство, конечно, желательно выбирать согласно задачи - в луже побарахтаться, Днепр переплыть или Тихий океан пересечь.

[ddiimmaa]

топикстартер начал размеры TCB обсуждать, поэтому я привел образное сравнение плавсредств - меньше размер/меньше удобств.

Ну не хотелось бы уж осень заострять внимание на размере TCB, просто первое на что смотришь, когда изучаешь ОС -- на TCB, (ну есть такое мнение что важнее не функции а структуры данных) вот и поразил меня, нафаршированый TCB у TNKernel. Конечно размер тут тоже имеет значение (в виду малого числа RAM), но больше удивило то, что на каждый объект (семафор мютекс и т. д.) у разработчика свой элемент в TCB.

[VslavX]

но больше удивило то, что на каждый объект (семафор мютекс и т. д.) у разработчика свой элемент в TCB.

Это где там на каждый объект свое поле в TCB? Есть свои списки для мьютексов - но это для реализации протоколов наследования приоритета. BTW, я через авторский вариант мьютексов "не продрался", сделал упрощенный вариант PIP/PCP (приоритет снижаем при освобождении мьютекса - сканируем захваченные мьютексы и выбирает макс уровень) - тогда один список не нужен. А так -
все списки в TCB очень даже на месте и лишних нет:

CDLL_QUEUE task_queue; - включен или в список диспетчера (и такой список свой для каждого уровня приоритета - планировщик работает очень быстро) или в список объекта который ждет -mutex/sem/event/queue

CDLL_QUEUE timer_queue; - включен в список проверки на тайм-аут ожидания. Теоретически можно и выкинуть - тогда в процедуре системного таймера бежать не по этому списку, а по списку всех задач и смотреть "кто ждет" и проверять тайм-аут. Но это - неоптимально, поэтому список таймера стоит этих 2-х слов в TCB, имхо.

CDLL_QUEUE block_queue; - этого у меня нет, используется для протоколов управления приоритетами, я схему немного упростил, но все "в рамках приличий", которые допускает uTRON 4.x. Насколько я смог разобраться, авторский вариант реализует полные версии PIP/PCP, что, имхо, несколько избыточно, хотя и приятно.

CDLL_QUEUE create_queue; - просто список всех задач в системе. Не особо нужен (кажется, даже реально в оригинале не используется), но полезен при отладке (выводим список всех задач в системе) и при контроле повторного использования TCB.

CDLL_QUEUE mutex_queue; - просто необходимый список для реализации протоколов PIP/PCP, чтобы по этим протоколам вычислить приоритет задачи надо иметь список залоченных задачей мьютексов. Ну, альтернатива - можно иметь один глобальный список мьютексов в системе, сканировать его - проверять наш/не наш. Но мьютексов в системе может быть очень много, а вот реально залочено задачей - один/два/три. Поэтому выигрыш в скорости - существенный. Также используется для автоматического освобождения мьютексов при завершении задачи (типа автоочистки) - бесплатный бонус

Да, списки можно сделать и односвязными. Ессно, потеряв в скорости и в предсказуемости времени операций добавления/удаления элемента - имхо, в данном случае - моветон.

Итак, ужать еще кое-что можно. Но - упадет скорость и потеряем кое-что полезное.
Еще момент - при написании/рефакторинге ОС неплохо бы определится с целевой платформой, тогда не будет таких вопросов - "а почему такой относительно сложный TCB". Например, когда я "осваивал" TN - сразу задал для себя некоторую минимальную планку ресурсов - минимум 32-битник и 8К оперативки и 32К флеша - на сегодня это младшие представители семейств LPC/SAM - так что такая планка вполне оправдана. Под 32-битностью я также понимаю атомарность операций извлечения/записи в память 32-битного слова/указателя -это позволило значительно пооптимизировать кое-какие места.

[AlexandrY]

Да, тема портирования высокомерно замалчивается, хотя она наверно тут самая важная.
Имеет ли смысл делать непривязанную к платформе операционку?
Тут как раз время начать кому-то кажущуюся религиозной войну на тему популярности и юзабельности uC.

На мой взгляд универсальность в этом плане делать не стоит.
Я тоже за ARM-ы, но только за Cortex-ы

И че сразу надо учесть - это соглашения из Application Binary Interface.
Неучет ABI - бесконечный источник траблов даже в солидных осях.
Даже в uCOS не знаю как сейчас, но раньше не брали в расчет нюансы ABI
И получали сюрпризы типа: а у меня из задачи стандартные либы так-то и так-то сбоят.

Под 32-битностью я также понимаю атомарность операций извлечения/записи в память 32-битного слова/указателя -это позволило значительно пооптимизировать кое-какие места.

[ddiimmaa]

На мой взгляд универсальность в этом плане делать не стоит.
Я тоже за ARM-ы, но только за Cortex-ы

И че сразу надо учесть - это соглашения из Application Binary Interface.
Неучет ABI - бесконечный источник траблов даже в солидных осях.

Хм, если ОСь -- оpen source, тогда какие могут быть траблы, главно API не часто менять, а на ABI наплевать.

Кстати копнув глубже в архитектуру ARMv7-M (ядро Cortex-а) обнаружил там команды чем-то напоминающие вход и выход из критических секций в мультипроцессорной системе.
Неплохой задел для операционок будущего!

Ну дак поделитесь хоть мнемоникой.

[aaarrr]

а на ABI наплевать.

Сильное заявление Плевать на стандарты, мягко говоря, не рекомендуется. Особенно осестроителям.

[ddiimmaa]

Сильное заявление Плевать на стандарты, мягко говоря, не рекомендуется. Особенно осестроителям.

Когда будут хотя бы 10 приложений для ОСи тогда будет не наплевать на АПИ
А когда будет загрузчик и две три либы тогда будет не наплевать на АБИ

А сейчас... кхм кхм.... начхать на них мона.

[aaarrr]

А сейчас... кхм кхм.... начхать на них мона.

Это заблуждение. Лучше соблюдать стандарты с самого начала, чем потом исправлять уже растиражированные ошибки.

[ddiimmaa]

Это заблуждение. Лучше соблюдать стандарты с самого начала, чем потом исправлять уже растиражированные ошибки.

Даааа? Я буду рад если вы мне покажите нормальный стандарт под такую ОСь. POSIX не предлагать слишком монструозно для таких осей. miTRON -- хороший стандар однако уж больно там имена функций корявые мне своим русским умом японские сокращения не понять

[aaarrr]

Даааа? Я буду рад если вы мне покажите нормальный стандарт под такую ОСь.

Сначала придется уяснить, о чем мы говорим:
Application Binary Interface

[ddiimmaa]

Сначала придется уяснить, о чем мы говорим:
Application Binary Interface

В таких ОСях думаю, что вводить специальный формат вызова не целесообразно. То есть как передавать параметры из функции в функцию из приложения в ядро, должен решать компилятор.

Никаких int 80h как в Menuet или Linux с регистрами и прочее -> ведёт к сильной привязке к архитектуре, да и зачаем оно? лишняя головная боль.

И ещё о Си ++. Незнаю почему но даже в Windows системные вызовы и прочее оно основано на Си (хотя создатели позиционируют свою систему как Объектно-Ориентированнцю, где есть про крайней мерее графические объекты, которые должны быть подчинены логике ООП)

Так вот, из всего что я знаю, так говорят, что BeOS -- объектно ориентирована и scrmRTOS. BeOs не видел, а вот последняя надо сказать очень элегантна сделана.


Жаль что это единственное исключение из правил.

[aaarrr]

В таких ОСях думаю, что вводить специальный формат вызова не целесообразно. То есть как передавать параметры из функции в функцию из приложения в ядро, должен решать компилятор.

Компилятор все решить не может, некоторые вещи придется сделать самому в соответствии с ABI.

Простой прнимер: стандарт ARM ATPCS требует выравнивать стек при вызове функции по границе двух слов. Автор FreeRTOS на это требование забил, в результате мы имеем глючащие библиотеки плавучки на некоторых компиляторах.

[ddiimmaa]

Компилятор все решить не может, некоторые вещи придется сделать самому в соответствии с ABI.

Простой прнимер: стандарт ARM ATPCS требует выравнивать стек при вызове функции по границе двух слов. Автор FreeRTOS на это требование забил, в результате мы имеем глючащие библиотеки плавучки на некоторых компиляторах.

Хм, а что ему мешает это выравнивать, что нельзя в файле port.c забить проверку стека при инициализации (если не делиться адрес на 8 то убавлять ещё 4 байта в стек поинтере?)?
А далее уже дело компилятора!

Или что? тут не поможет данное решение????????

Или далее компилятор уже не выравнивает?

"некоторые вещи придется сделать самому в соответствии с ABI."
Ну конечно к ним относиться стековые веши, согласен!!! Ясень пень что стек инициализировать надо в соотвесвии с ABI, но что тут определяться то?
Сама то ОС, главная часть то бишь! она каким тут боком?

Почему надо думать об ABI, зачем создавать какой то свой интерфейс вызовов, почему тупо не следовать уже написанному и то только в портируемой части? вот что я не пойму?Как? простите инициализация стека корреным образом влияет на ОС?

[aaarrr]

Или что? тут не поможет данное решение????????

Поможет, конечно, хотя лажа на самом деле в tasks.c:

Код

#if portSTACK_GROWTH < 0
{
    pxTopOfStack = pxNewTCB->pxStack + ( usStackDepth - 1 );
}
#else
{
    pxTopOfStack = pxNewTCB->pxStack;    
}
#endif

Помимо направления роста стека (portSTACK_GROWTH) должен быть еще один параметр, определяющий пре- или постдекремент при стековых операциях.

Почему надо думать об ABI, зачем создавать какой то свой интерфейс вызовов, почему тупо не следовать уже написанному и то только в портируемой части? вот что я не пойму?Как? простите инициализация стека корреным образом влияет на ОС?

Да кто Вас призывает придумывать свой интерфейс вызовов? Как раз и нужно следовать существующему. Просто при создании ОС нужно учитывать все многообразие архитектур, а не забивать жестко направление того же стека.