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

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

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

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

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

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

Мнения?

Вопросы?

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

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

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

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

Ну покажите класс. Кто вас знает, мож вы гений.
512 Kb RAM-а - это очень много. Не советую ориентироваться на такие числа.
Ограничтесь лучше 2-я Кб. Во всяком случае для uCOS, ThreadX, CMX и других мощных осей этого вполне хватает для пары тройки задач.
Вообще-то нынче каждый уважающий себя компилер идет с встроенной RTOS.
У CodeWarrior - MQX, у Keil - RL ARM, у Tasking - OSE, у IAR - PowerPac и т.д

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

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

Второй уникальной фичей мог бы стать сборщик мусора.
Задачи в момент инициализации могут захватить кучу памяти под разные буфера.
Потом при выгрузке задачи надо долго выискивать где там че было выделено.
Неплохо было бы чтоб все автоматом освобождалось.

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

Ну и еще дальше есть идеи...
Зависит от вашей реакции

Ну а я и не знал, что в свое время походя добавил во FreeRTOS "уникальную" вещь - всего-то в Memory Control Block менежера памяти запоминается адрес TCB задачи его запросившей.


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




 

LR еще запоминать надо Или любой произвольный отладочный параметр, передаваемый malloc'у при таргете Debug.

LR? А если это не ARM? . Лучше __LINE__ + __FILE__ (по крайней мере, IAR/GCC/MSVC про них знают ) Например:

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

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

А вот реализация:


Подход очень неплох - когда завершаемся - можно пробежать по списку неосвобожденной памяти и сразу ответить на вопрос "кто виноват". Но есть и минус - когда делаем MM_Free - надо пробежать по списку, найти блок (если не нашли - тоже класс - сразу assert), и удалить из списка. Когда таких блоков много и частые alloc/free - список тормозит. Но для отладки - самое оно.
А в embedded я стараюсь "кучу" не пользовать - у меня обычно ясно сколько объектов будет "в деле" - для них пул блоков фиксированной длины пользуется - в TN Kernel под это дело даже системные вызовы сделаны.

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

Конечно, если мельчить задачи, то решение zltigo тоже работает неплохо - если в одной задаче обозримое количество аллокаций. Хотя грань понятия "мельчения" у каждого своя. Кому и 2 аллока - смерть

А как Вы ищете потом процедуру по этому адресу? Я подсчитал - у меня в TCP за сотню вызовов pbuf_alloc(), по листингам смотреть-считать? Есть автоматизация какая?

В IDA пробовали грузить .elf-файлы с нестрипнутым debug-info? Дальше все просто, кнопочку G, вводите адрес LR, оценяете, где находитесь.

Зачем плодить наследованные глупости? Выделяйте память , используя дескрипторы, которые можно располагать в отдельном сегменте. Заодно ответы на вопросы: Дефрагментация? Размер блока? Уборка мусора?

В общем, сейчас закритикуют... Жду

Спасибо, про IDA я как-то не подумал, попробую! А для IAR-а тоже сработает?


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

Ага. 4.42 точно стреляет. 5.x - надо проверять, пока не пользую.

Так я в общем-то это и делаю, точнее лучше , для текущей задачи задачи известен указатель на ее Task Control Block он и сохраняется в менеджером памяти в Memory Control Block.

Я не очень понял, кто сохраняется? Указатель на TCB? Но это локализация с точностью до задачи.

Естественно до задачи. Нужно зачем-то меньше? Тогда при вызове malloc у меня можно явно указать не NULL, а некое число идентификатор и сохранено будет оно, а не указатель на TCB. В качестве идентификатора можно использовать, и указатель на текстовую строчку или сруктуру в котрой уже есть и TCB задачи и локализация конкретного места.

Не возражаю

Я вот тут как-то задумался - у меня потребность знать какая задача выделила память редко возникает. Под Windows - в User Mode ОС сама следит и чистит, в Kernel Mode драйверу обычно тоже все равно какой контекст. В простых ОС для embedded понятие задача вообще упрощено и сведено до потока - в системных сервисах запоминать TCB тоже не особо нужно. Я как-то стараюсь привязать память к объекту который ее использует, а не к потоку. Например, сокет TCP - создается, живет, для него выделяются pbuf-ы, ведется четкий учет, квотирование, в самом pbuf есть ссылка на socket-владелец. А вот TCB - нету. Сокет может быть создан в одном потоке, выполнять обмен в совершенно другом, и завершить свою жизнь в третьем. И какой смысл помнить какой поток выделял для него pbuf?
Аналогично для USB pipe - вся память "записана на владельца" - структуру описывающую pipe, и поля TCB там тоже как-то нету.
Конечно, это не значит в общем случае что TCB знать не полезно, просто подход, наверное, другой.

Плохо только то, что армовский IAR почему-то не склеивает функции. Ну типа


AVR'овский отлично изготавливает нечто типа
, а армовский, к сожалению, так не делает

Значит там хранится не указатель на TCB, а на то, что хотите. Более того, что на самом деле у меня, например, для блока памяти выделенного очереди там на автомате сохраняется, естественно указатель на Queue Control Block. Ну а в самом QCB уже TCB .

 

Попробуйте применить к функции модификатор static. Вероятно, компилятор Вас приятно удивит .
PS: я уже этим static даже злоупотреблять немного начал

Не удивит

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



А что тогда не нравится?
Вот Ваш пример:

У меня превратился в:

Имхо, вполне ничего.
А функции, да, не конкатенирует - я это только в IAR AVR встречал - там он даже что-то вроде архиватора Лемпеля-Зива применяет - ищет в совершенно разных функциях одинаковые куски, составляет из них "словарь" и вовсю его "пользует".

Дык я об этом. Сделайте #pragma optimize=no_inline и поймете о чем я.



Ну кросскол - это от лукавого, я так мыслю.

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



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


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


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


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


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



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


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

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

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

посмотрел

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



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

Ужимается в полтора раза без потери функционала. У меня сейчас 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 наплевать.



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

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

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

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

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

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

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