Требуется совет по выбору RTOS, программист я хреновый Опции

[Electrovoicer]

Созревает проект на LPC213x. Сюдя по всему конечным автоматом на таймере обойтись не получится ввиду большого числа событий и источников прерываний. Это на мой профанский взгляд. Да и надо наконец научиться писать с использованием RTOS. В связи с чем просьба к общественности посоветовать ПРОСТУЮ RTOS. И не просто посоветовать, а подсказать где ее взять. В принципе и купить можно, но сначала хотелось бы пощупать. Главное чтобы софт был качественно задокументирован, а то в С++ я как свинья в апельсинах, разбираться с исходниками не буду да и не смогу наверное. Мне бы на пальцах показать, как создать тред и исполнить в нем мой код. Соответственно хотелось бы иметь готовый порт на мой процик. Вытесняющая она должна быть или невытесняющая, еще не понял. Чтобы это понять, желательно Ваши примеры задач, для которых то или иное больше подходит.
Также просьба не отвечать вроде "да на хрена тебе ртос", "атмел sam7 рулит" и "ваще надо на асме писать"

С уважением, я

[sensor_ua]

А я решил в попытке решения подобной задачи (LPC2138 и куча всего по самые уши) TNKernel прикручивать. Пока по кусочкам - прикрутил вход-выход для критических секций (практически такой же, как в uCOSII). А вот FreeRTOS после анализа этих самых критических кусочков пришлось забраковать. Посмотрим дальше...

[zltigo]

А вот FreeRTOS после анализа этих самых критических кусочков пришлось забраковать.

???
Что такое жуткое вскрылось при анализе?

[sensor_ua]

А вот FreeRTOS после анализа этих самых критических кусочков пришлось забраковать.

???
Что такое жуткое вскрылось при анализе?

Сразу оговорюсь, что сам не программист, потому прошу сильно не пинать.
В TNKernel наблюдаю

int tn_cpu_save_sr(void);
void tn_cpu_restore_sr(int sr);
#define tn_disable_interrupt() tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg)

Во FreeRTOS

/* The code generated by the Keil compiler does not maintain separate
stack and frame pointers. The portENTER_CRITICAL macro cannot therefore
use the stack as per other ports. Instead a variable is used to keep
track of the critical section nesting. This necessitates the use of a
function in place of the macro. */

void vPortEnterCritical( void ){...}

void vPortExitCritical( void ){...}

В uCOS-II, IMHO, подобное называлось уровнем (паранойи?)) то ли 1, то ли 2, а теперь прописано, что пользуют уровень 3 - практически то же по асму, что и в предпоследней TNKernel (в последней заменили (в tn_cpu_save_sr() и tn_cpu_restore_sr(..))
bx, lr
на
mov pc,lr

Мне решение в TNKernel и uCOS-II кажется обоснованным и разумным.

[zltigo]

В TNKernel наблюдаю

int tn_cpu_save_sr(void);
void tn_cpu_restore_sr(int sr);
#define tn_disable_interrupt() tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg)

Во FreeRTOS

void vPortEnterCritical( void ){...}

void vPortExitCritical( void ){...}

Мне решение в TNKernel и uCOS-II кажется обоснованным и разумным.

В TNKernel и uCOS-II сохраняется регистр статуса и это видно по коду, а во FreeRTOS эти функции void. Может оно там тоже как-то сохраняется, но я не смог увидеть куда

Самый странный критерий выбора операционной системы, какой я только встречал на данный момент.
Или я чего-то не понял :-(
В TNKernel много чего хорошего, но реализация ограждения критических секций более чем спорная.
Для сохрания состояния используется персональная поименованная переменная и за этим необходимо
следить глазами и руками. Не дай бог вам пару раз подряд вызвать tn_cpu_save_sr() с сохранением
в одну и ту-же переменную. А макросами tn_disable_interrupt() и tn_enable_interrupt() вообще
находясь в здравом уме и твердой памяти пользоваться нельзя, ибо при вложенном вызове их
критической секции еще одной критической секции кирдык в виде запрещенных навсегда
прерываний наступит незамедлительно. Несимметричное количество вызовов тоже черевано.

Теперь о FreeRTOS:
void vPortEnterCritical()
void vPortExitCritical()
Имеют исходники. Они просты, как лом, откомментированы, и так-же надежно работают.

Код

void vPortEnterCritical( void )
{
    /* Disable interrupts first! */
    __disable_interrupt();

    /* Now interrupts are disabled ulCriticalNesting can be accessed
    directly.  Increment ulCriticalNesting to keep a count of how many times
    portENTER_CRITICAL() has been called. */
    ulCriticalNesting++;
}
void vPortExitCritical( void )
{
    if( ulCriticalNesting > portNO_CRITICAL_NESTING )
    {
        /* Decrement the nesting count as we are leaving a critical section. */
        ulCriticalNesting--;

        /* If the nesting level has reached zero then interrupts should be
        re-enabled. */
        if( ulCriticalNesting == portNO_CRITICAL_NESTING )
        {
            __enable_interrupt();
        }
    }
}

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

[dxp]

Теперь о FreeRTOS:
void vPortEnterCritical()
void vPortExitCritical()
Имеют исходники. Они просты, как лом, откомментированы, и так-же надежно работают.

Код

void vPortEnterCritical( void )
{
    /* Disable interrupts first! */

[...skipped...]

    }
}

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

А зачем такие навороты с подсчетом входов, анализом их при выходе и т.д.? Тут, насколько я понимаю:

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

Почему бы не использовать простую схему (псевдокод):

Код

CritEnter()
{
    SaveInterruptState();
    DisableInterrupt();
}

CritExit()
{
    RestoreInterruptState();
}

Все, ничего подсчитывать и анализировать не надо и логическая целостность программы не нарушается. Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функиций, но это надо делать при любом подходе. На С, к сожалению, это приходится делать руками, тут ничего не поделать. К счастью, на С++ этот момент поддается автоматизации, поэтому использование критических секций там тривиально и совершенно безопасно. :-)

[zltigo]

А зачем такие навороты с подсчетом входов, анализом их при выходе и т.д.?

-Ну про 'навороты' это уж перебор :-)
-Безболезненная вложенность.
-При использовании этого механизма без левых запретов прерывания будет отсутствовать
это:

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

прилично кода - накладные расходы, т.е.

Одного порядка, на самом деле, в FreeRTOS случае дополнительная работа со счетчиком
в памяти, в варианте "с сохранением" тоже работа с памятью - считать-запомнить-прочитать-записать.

Почему бы не использовать простую схему (псевдокод):
....
Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функций, но это надо делать при любом подходе.

-Увы, не единственное, вроде уже распинался :-(.
- в варианте "со счетчиком" комплементарность можно слегка нарушить :-) лишними вызовами
конца критической секции.

объясните неразумному, почему EnterCriticalSection у вас ассоцируется с запретом прерываний ? Мне это как-то неочевидно..

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