http://www.tnkernel.com/

У меня работает без вопросов...

А начем работает? Там два проца указано, или на чём-то третьем.
--------------------
Посмотрел, взял на заметку.

А можно подробнее, раз уж оно у Вас работает:
1. Тип ОС - кооперативная, вытесняющая, ...?
2. Требования по памяти (для самой ОС + память для задачи)
3. Время переключения контекста?
4. Гарантии по латентности реакции на прерывание?

2 ADMIN: просьба перенести этот топик в форум по операционным системам
http://forum.electronix.ru/index.php?showforum=88

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

Все параметры ТNKkernel очень близки к uC/OS-II.

Вввиду отстутствия Mutex или подобных механизмов (Priority Inversion/Priority Inheritance/Priority Ceiling)
время переключения в реальных задачах может быть непредсказуемо долго - т.е. все это только для очень простых применений.

Priority inversion используется в подавляющем большинстве случаев
как один из методов избежания dead locks, и поэтому не имеет никакого
отношения к времени переключения контекста.

IMHO,не стоит играться с изменениями приоритетов "на лету"
в real-time OS т.к. решая таким образом проблему блокировок,
можно словить весьма неприятные проблемы с приоритетом -
задачи которые должны получать наибольшее время процессора
будут получать малопредсказуемый piece of time ).

I am very sorry, в предыдущем письме вместо Priority inversion должно
быть Priority Inheritance/Priority Ceiling (Priority inversion - это проблема,
а Priority Inheritance и Priority Ceiling - пути ее решения)

Всегда считал с точностью до наоборот, и практические результаты это подтверждают. Это уже механизмы ОС должны следить за корректностью изменений приоритетов.

А как быть в этом случае ?

"The high priority task must block until the low priority task releases the resource. This
problem is exacerbated when the low priority task is prevented from executing by one or
more medium priority tasks. Because the low priority task is not executing, it cannot
complete its interaction with the resource and release that resource. The high priority task
is effectively prevented from executing by lower priority tasks."

В приложениях со сложной логикой такие проблемы сплошь и рядом.
И вручную их трудно предугадать и разрешить, приходится надеятся на правильность ОС.
IMHO простейший Mutex как в UCOS многим не помешал бы, если не сейчас, так на вырост, по мере усложнения программы.

М-да, без mutex трудновато, особенно если к ним привык.
А к хорошему привыкаешь быстро.

В следующей версии TNKernel я добавлю расширенные ф-ции синхрони-
зациии ( Mutex и Rendezvous), а так же ф-ции типа DeleteTask,
DeleteSemaphore etc.

И еще бы добавить генератор ORTI файлов. Получился бы хит

А на каких процессорах её запускали. кроме указанных на сайте? (Меня интересуют AT91SAM7S)

На Atmel ARM не запускал,но AT91SAM семейство в планах(просто пока
нет под рукой hardware c AT91SAM).