Уже в нескольких ветках вы ссылаетесь на эту "бескомпромисность" одних ОС (FreeRTOS,..?) относительно других (TNKernel, uCOS,...?), как на важнейший критерий вашего выбора оси. Не могли бы вы пояснить, что имеете в виду.

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



Блин, для списоков не нужно каких-то массивов.




Правильно я понял(упрощенно): структура "получено сообщение", в ней - список задач, получивших сообщения,
планировщик их смотрит и разблокирует если они receive-блокированные

А можно привести пример системы, если она с открытыми исходниками? Чтоб поподробнее, что представляет эта event структура?






Для начала берутся разные типы данных для порта (примерно как portCHAR, portXXX во freertos-e)
Сначала хочу отработать механизм на слабейшем, а переписывать - для ARM7.. Еще вопрос, как себя компилятор будет вести может и не надо переписывать. Вообще это все сейчас пока не так важно.

Для ясности:
1. не в нескольких ветках, а кроме этой только в одной по TN-Kernel
2. речь шла более конкретно - о шедулерах.

Так уж вышло, что еще с 90x годов (практически доинтернетовской эпохи) приходилось писать "свои" системки гордясь большей частью экономией байтов и тактов и обходя вылезающие проблемы многочисленными наслоениями. Когда почти два года назад в качестве новой базы выбрал ARM линейку контроллеров, то решил (и не пожалел!) не продолжать практику перетаскивания своего кода, а взять готовую базу для RTOS и дорабатывать уже ее.
Критериями выбора исходя из предыдущего разнообразного опыта на тот момент были -
Поддержка задач с одинаковыми приоритетами. Возможность динамического создания и удаления задач, что сразу тянет за собой автоматически и третье условие - наличие менеджера памяти.
Не хотелось и ограничивать число задач. Приятным бонусом в последствии явилось появление на выбранной платформе возможности запускать часть задач в невытесняющем режиме.

Речь вел не проблемах портирования а о соразмерности системы используемому контроллеру
Ну это как если движок созданный для, например Жигулей простым увеличением его геометрических размеров использовать для автомобиля класса, например, Ягуара. Ездить-то он будет, но ведь "что-то", согласитесь, не так .
Портируется-то легко...

P.S.
А по крайней мере пробовать писать "свою" систему надо - очень развивающее, увлекательное и затягивающее занятие!

Един да един-это два, а несколько-это более одного.


Так этим условиям(кроме последнего?) удовлетворяют и FreeRTOS, и TNKernel. Поэтому, прежде чем начать более глубоко разбираться с обеими(или сразу выбрать одну), интересно мнение того, кто уже копал обе. Чем не устроил шедулер TNKernel и понравился FreeRTOS? В предыдущих ветках вы часто их сравнивали(более двух раз ), но как-то невнятно(для меня ).

Похоже перехвалил, о механизмах планировки еще разговора не было.
Идет пока речь только о реализации механизмов синхронизации.
И они в действительности очень разные.
В ThreadX, например реально сделано более топорно и именно на основе нескольких разнородных списков для семафоров отдельно, для очередей отдельно и т.д.
Кстати это в ThreadX всего 32 приоритета.
Но операционка тем не менее для ARM-ов очень популярная.
В ThreadX память для элементов списка выделяется самим юзером, в отличие от uCOS. И такая практика на мой взгляд плохая. Одна ошибка в процедуре выделения-восстановления памяти в одной задаче и посыпется вся Ось. В uCOS такого не будет.

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

Есть еще более популярные решения - "а зачем вообще эта операционка". Ну и что?

Немеряно!

А я не отмахиваюсь - почти все имеет право на существование и свою нишу для применения.
Я только хотел сказать, что рассмотрение минималистичных решений заточеных под восьмибитовики на ARM платформе лично мне уже совсем не интересны.

TNKernel 2.x весьма привлекательна, о чем я уже ранее писал. Но FreeRTOS появилась в пригодном ( для меня ) к стартовому использованию варианте раньше, что и обусловило выбор. На данный момент вопросы перехода на что-то другое не рассматриваются ввиду больших собственных доработок и наработок, ну и отсутствия сколь-нибудь обьективной необходимости. Все устраивает

В кодах 2.83, 2.84 поддерживается до 256 приоритетов = мах числу задач.
В коде 2.52 максимальное число приоритетов = 64. (за вычетом Idle и если используется,
Stat процессов, 255 и 63 или 254 и 62 соответственно)

Конечно, можно увеличить priority bitmap до размера 8KB и переменную группы
соответственно, чтобы отыскать младший установленный бит в 65536-битовом
числе.



TS в системе где нет двух процессов с равным приоритетом? Проще (и логичнее)
переделать алгоритм планировщика uCOS, чем моделировать тоже самое из уровня
приложения...

--
Андрей