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

[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 -- хороший стандар однако уж больно там имена функций корявые мне своим русским умом японские сокращения не понять

[VslavX]

miTRON -- хороший стандар однако уж больно там имена функций корявые мне своим русским умом японские сокращения не понять

Хм, а какое отношение имена функций имеют к идеологии?

останавливает, что она написана на C++

Имхо, в "плюсах" очень много возможностей для генерации неявного кода, чтобы грамотно пользовать C++ в embedded надо знать язык _очень_ хорошо. Вот здравое сомнение в своем уровне владения языком и останавливает.

[dxp]

Имхо, в "плюсах" очень много возможностей для генерации неявного кода, чтобы грамотно пользовать C++ в embedded надо знать язык _очень_ хорошо. Вот здравое сомнение в своем уровне владения языком и останавливает.

Насчет много, это вы погорячились. Основной генератор неявного кода - шаблоны, исключения и RTTI. В embedded реально используются только шаблоны, вот с ними надо быть внимательным, но сюрпризов там нет - все достаточно легко прогнозируется. Остальное: неявная передача this в функции-члены при вызове, все эти vtpr/vtbl и прочее - это, во-первых, мелочи, во-вторых, это не оверхед, а реализация необходимой функциональности, которую в противном случае (например, на С) пришлось бы писать руками.

Не пренебрегайте плюсами, применяйте - очень скоро почувствуете уверенность и обратно уже не захочется.

[AlexandrY]

Обратно никогда не хочется!
Став все время работать на C++ вы забываете постепенно паттерны программирования на C и вам затруднительно использовать фреймворк который нынче весь исключительно на C написан. Или сидите на двух стульях и пишите медленнее обычного и делаете больше багов.
Либо вы вообще узкий специалист и это не ваша игра.

Освоение С++ меньше всего сводится к синтаксису и объектной модели, надо иметь экосистему, как модно нынче говорить, для использования этого языка.
C++ в embedded просто неконкурентоспособен.
Т.е. написав ось на C++ вам придется писать и фреймворк и прикладные стеки на C++
А это абсолютная утопия еще в ближайшие десятилетия.
Сделать заново целиком весь embedded фреймворк способны только гиганты типа Microsoft.
Но они уже сделали ставку на C# и .NET.
А нишу малых RTOS они занимают micro framework у которого HAL уровень на том же C написан.

Насчет много, это вы погорячились. Основной генератор неявного кода - шаблоны, исключения и RTTI. В embedded реально используются только шаблоны, вот с ними надо быть внимательным, но сюрпризов там нет - все достаточно легко прогнозируется. Остальное: неявная передача this в функции-члены при вызове, все эти vtpr/vtbl и прочее - это, во-первых, мелочи, во-вторых, это не оверхед, а реализация необходимой функциональности, которую в противном случае (например, на С) пришлось бы писать руками.

Не пренебрегайте плюсами, применяйте - очень скоро почувствуете уверенность и обратно уже не захочется.

[VslavX]

Обратно никогда не хочется!
Став все время работать на C++ вы забываете постепенно паттерны программирования на C и вам затруднительно использовать фреймворк который нынче весь исключительно на C написан. Или сидите на двух стульях и пишите

Ну, это смотря насколько в C++ углубиться. Идеи в ++ есть, немало, и среди них есть даже полезные. Я, например, довольно часто использую сам объектный подход - неважно, что функции обычные С-шные и изолирование методов и данных производится примитивно вручную на уровне файлов и операторов static. Да, нет перегрузки, наследования и прочего, но проект в целом видится яснее.

Т.е. написав ось на C++ вам придется писать и фреймворк и прикладные стеки на C++

Имхо, при желании вполне можно подружить C++ приложение и C-framework. Придется поработать, не без этого, но - возможно. Меня скорее напрягает вероятная проблема с компиляторами - спектр применяемых архитектур широкий - ARM/XScale, PowerPC, X86, возможно скоро будет MIPS, маячит Nios/CortexM1. На "чистом C" как-то все пока получалось переносить без особых проблем. Но - все равно тема интересная, думаю надо таки ++ попробовать - на каком-то ограниченном проекте (и, кстати, на сишном фреймворке), только бы вот время на это все найти . Паттерны вряд ли забудутся - я любитель частенько смотреть в ассемблерный листинг.