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

В RL ARM у TCB размер 12 слов, а по функционалу оно TN уделает пожалуй.

Ну я бы не сказал, что "уделывает". Но спорить насчет цвета и вкуса фломастеров не буду

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

Потому, что обычно Авторы реальных систем думают не только о том, как поставить рекорд по минимуму TCB. Естественно, приложив определенные усилия действительно можно соптимизировать для конкретных применений. Бывают, конечно и практически необъяснимые решения, типа раздельных блоков памяти для стека и TCB у FreeRTOS (у себя похерил), но в основном Авторы действительно получивших распространение систем не дураки.

Ну вот посмотрите на Адама Дункелься!!! Это не его ли мини мини стэком TCP пользуються большинство микромикроконтроллистов!
Так вот он вообще придумал Contikki -- по два байта на поток. Правда у него не поток а протопоток (protothread). И реалтаймом не пахнет, но он своё детище операционнкой называет.

Ну тут всё просто, как мне кажеться -- это чтобы облегчить жизнь процедурам выделения/освобождения памяти. Говорят в ранних версиях FreeRTOS был пул, как-то заранее нарезаных блоков памяти.

И Вы тоже нечто нерожденное называете . Вопрос не в названии, а в пригодности не для демонстрации рекордной экономии системной памяти (тут вообще любую операционку уделать можно индивидуальным кодированием по месту ), а в беcпроблемном использовании отработанных решений для разумно широкого круга задач.



Очень сомнительное облегчение. TCB они конечно, одного размера, но стеки в общем случае разного. Получаем большее число фрагментов при гипотетически легче утилизируемом блоке освобожденного TCB под новую задачу.

В явных минусах - увеличение расхода памяти на TCB, MCB и времени на двойной запуск менеджера памяти.  



Не принципиально, поскольку менеджер памяти у FreeRTOS абсолютно абстрактный. А нарезку блоков применяю безонносительно к системе - выделяется болок памяти и в нем создается еще одина структура блоков в котором выделятся блоки только одного одинакового размера.

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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



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