- Не пытайтесь повысить быстродействие уже существующих RTOS
путем доработки их исходного кода. Код RTOS обычно небольшой
по размеру, но требует тщательной проверки на десятках разнообразных
задач. Не хватает быстродействия - тщательней конструируйте проект
( число и назначение задач, их приоритет, размер блоков для передачи
данных между задачами, etc.)

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

- Не используйте malloc(), используйте fixed-sized blocks memory allocators.
Очень мало аппликаций, где malloc() действительно нужен (GUI).

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

- При обмене данными между задачами через очереди для повышения
быстродействия пересылайте данные блоками, а не байтами. Элементом
очереди при этом будет указатель на блок памяти, полученный от fixed-sized
blocks memory allocators.

- Избегайте использование синхронизационных функций RTOS с таймаутами.
Хорошо сконструированной системе очень редко нужны таймауты,
отличные от INFINITE. Длинные временные задержки можно получать вызовом
системных функций типа Sleep().

- Уменьшайте,насколько возможно, число прерываний в системе.

Совершенно верно.

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

Не совсем понял - это против использования менеджеров памяти вообще, или пусть будут,
но выделяют память солидными блоками, дабы не дефрагментировать "излишне"??
Менеджер памяти должен быть - ибо ее почти всегда не хватает :-( Ну а борьба с дефрагментацией - думать надо :-( при проектировании ....

Само собой!

Как вариант - да. Но опять от реализации зависит - приходилось очереди уже _сразу_ на указателях
на буфер из фиксированных блоков реализовавать, причем все на ASM c размерами степени двойки
и с расположением по красивым адресам - быстрее уже не сделать :-)

Очень! зависит от реализации ядра и не всегда можно "хорошо сконструировать" систему ввиду того,
что далеко не все в руках творца, а определяется внешним миром.

В качесте общей рекомендации типа "не плодить сущности" - да.


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

- Не пытайтесь повысить быстродействие уже существующих RTOS путем доработки их исходного кода.
А почему не пытайтесь. Ноборот нада пытатся. Скорее всего не получится, зато после мучений неисправленная ОС у Вас станет ГОРАЗДО послушней. Ковырятся однозначно.


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

Не всегда !!! По крайней мере один раз - сегодня и у меня нельзя было решить успешно тем что было (очереди). Можно было без очередей извращнутся но я не захотел.

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

Пока Вы не начнете КОВЫРЯТСЯ В ПОТРОХАХ не будет у Вас просветления и музы, даже если вам самую суперновую ОС дадут и мегапроцессор.

Напомню оду из поговорок - ХОШ ИЗОБРЕСТИ НОВОЕ, БУДЬ МИЛ ИЗУЧИ СТАРОЕ.

хм.. главное с водами не выплеснуть младенца :-/

напомню название топика - "Для начинающих пользователей RTOS"
вообще подобные лозунги напоминают советы из серии: "Настоящий эмбеддер должен в своей жизни сделать 3 вещи: .... "
а работать когда?.. вам хорошо - вы сейчас в отпуске..
рутина редко предоставляет время для подобных изысканий

Сейчас RTOS достаточно много, пожтому модифицировать не имеет особенного смысла лудше потратить время на изучение новых

Это почему?


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