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

[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.