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

[Electrovoicer]

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

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

[sensor_ua]

У меня железка с неким ногодрыганием, устроенным типа импровизированной шины. Как известно, GPIO сами не имеют в АРМ операций чтение-модификация-запись, дык ещё в железке есть выборки внешних устройств на "шине" через опять же GPIO. Если подвигать GPIO в прерывании, а оно может возникнуть когда двигались GPIO вне прерывания, чегой-то нужно сохранять. Т.е. либо в административном порядке запрещать использовать GPIO в прерывании, либо реализовать атомарность каким-либо способом. АРМ позволяет, например, выполнить SWI, можно просто запрещать прерывания на входе в критическую секцию, при выходе - разрешать, но тогда если при входе если были запрещены прерывания, при выходе они разрешатся... иначе нужно при входе не просто запрещать, а сохранять регистр статуса, затем запрещать прерывания, а при выходе всего-лишь восстанавливать что было. Можно вообще завести обработчик IRQ, в который вваливаться через VICSoftInt, а там творить чего угодно, пока не разрешили вложенные прерывания...

А DASM вроде как прав получается, касательно критической секции.
Если Таненбаума книгу "Современные ОС" посмотреть, так там написано, что
Критическая секция служит для того, чтобы предотвратить одновременный доступ к обшим данным. Одно из требований, это то, что в критической области не могут находиться одновременно 2 процесса.
Но для этого действительно не обязательно запрещать прерывания. Поток находящийся в крит.секции, может вытесниться, но если какой другой поток захочет в нее войти, он должен ожидать пока она освободится.

В общем, спор о терминах.
В принципе можно называть критической секцией любую секцию, где предотвращается одновременный доступ к каким-либо ресурсам из разных процессов. Способ реализации может быть, как методом запрета прерываний, так и с организацией доступа через бинарный семафор (или можно применить модное слово мютекс ) или какой-нибудь флаг.
Причем иногда доступ запретом прерываний вообще может оказаться не приемлем, потому как ресурс, доступ к которому разделяется, может сам работать через прерывания, например захватили uart, передали строку символов, освободили uart. Понятно, что разделить доступ к такому ресурсу через запрет прерываний нельзя.
Другое дело, когда надо сделать действие, достаточно короткое и быстрое, но требующее также гарантий ограничения доступа к этом ресурсу. Например, работа со связанными списками. Вставка элемента списка в цепочку должна быть сделана в критической секции. Но пользование в этом случае системных сервисов ОС (типа мютексов) - нецелесообразно, потому как накладные расходы возрастут раз в 100 по сравнению с методом разрешения/запрещения прерываний.
И совсем другое дело, когда говорится о критических секциях, используемых в самой ОС, то есть когда сервисы ОС прописываются. Здесь термин "критическая секция" как раз всегда означает запрещение прерываний. А речь как раз о них и была (выше по теме).
У меня терминология (моя локальная) устоялась так, что критической секцией я называю секцию, где запрещены прерывания, и не важно, используется в проекте ОС или нет.

Пока пороюсь поищу что такое #+0xC0, а то "чукча не читатель";)))
Может подскажете, где? А то ARM7TDMI Data Sheet (ARM DDI 0029E) не помогает...

#0xC0 маска для запрета IRQ и FIQ прерываний
Маска 0x80 для регистра CPSR - это запрет IRQ , а 0x40 - для запрета FIQ.

Простите, не указал точно - мне непонятно только "#+"

[zltigo]

У меня железка с неким ногодрыганием, устроенным типа импровизированной шины. Как известно, GPIO сами не имеют в АРМ операций чтение-модификация-запись, дык ещё в железке есть выборки внешних устройств на "шине" через опять же GPIO. Если подвигать GPIO в прерывании, а оно может возникнуть когда двигались GPIO вне прерывания, чегой-то нужно сохранять. Т.е. либо в административном порядке запрещать использовать GPIO в прерывании, либо реализовать атомарность каким-либо способом. АРМ позволяет, например, выполнить SWI, можно просто запрещать прерывания на входе в критическую секцию, при выходе - разрешать, но тогда если при входе если были запрещены прерывания, при выходе они разрешатся... иначе нужно при входе не просто запрещать, а сохранять регистр статуса, затем запрещать прерывания, а при выходе всего-лишь восстанавливать что было. Можно вообще завести обработчик IRQ, в который вваливаться через VICSoftInt, а там творить чего угодно, пока не разрешили вложенные прерывания...

Я не понял :-( Вообще ничего из вышеизложенного не понял.
Если речь идет о том, что Вы имеете некоторую процедуру,которая для обеспечения ее непрерывности
обрамлена critical и по этой причине ее нельзя вызывать из обработчика прерывания, то
0. Нужно делать вещи максимально близкие к естественным.
1. Делается процедура без запретов.
2. Для работы в прерывании вызывается прямо или через прямую макроподстановку
3. Для прочего использования через макрос-обертку с __disable/enable.
Если обработчики прерываний в отдельном файле, то макроимена могут быть вообще одинаковыми.
В результате начисто отпадают все ненужные навороты как в виде 'счетчиков', так и ввиде 'сохранений', заодно не надо вникать в реализацию critical в каждой конкретной операционке.

Все выглядит (живой пример) примерно так:

Код

//-----------------------------------------------------------
// Read/Write SLIC Registers with CLOSED interrupts
void wr_sreg_int( BYTE channel, BYTE reg,  BYTE value );
......
//-----------------------------------------------------------
// Read/Write SLIC Registers
#define wr_sreg( x, y, z )             \
{    __disable_interrupt();          \
    wr_sreg_int( x, y, z );            \
    __enable_interrupt();  }

......

Если всенеприменнейше хотите critical, то можете добавить свой critical для обработчиков прерываний,
единственной функцией которого будет наращивание/уменьшение 'счетчика'.

2 zltigo

У меня насчёт правильности запрещения/разрешения прерываний вопрос к Вам остался.
Представьте себе, что пишет подпрограмму с критической секцией не Вы, а коллега. Вы эту подпрограмму интегрируете в свой проект.
Ответьте, пожалуйста, на каком основании Ваш коллега имеет право разрешать прерывания (при выходе из критической секции), если он не узнаЁт при запрещении (при входе в критическую секцию), были ли они (прерывания) разрешены?

Так они и не будут разрешены если Вы вызвали его из критической секции и соответственно
счетчик на входе в подпрограмму колеги уже не будет 0. Ежели коллега, или Вы пожелает в _прикладной_ программе воспользоваться прямым запретом/разрешением вместо critical , то, как здесь уже было замечено, надо наказывать, ибо против лома нет приема.

Сообщение отредактировал zltigo - Apr 21 2006, 16:26

[sensor_ua]

У меня железка с неким ногодрыганием, устроенным типа импровизированной шины. Как известно, GPIO сами не имеют в АРМ операций чтение-модификация-запись, дык ещё в железке есть выборки внешних устройств на "шине" через опять же GPIO. Если подвигать GPIO в прерывании, а оно может возникнуть когда двигались GPIO вне прерывания, чегой-то нужно сохранять. Т.е. либо в административном порядке запрещать использовать GPIO в прерывании, либо реализовать атомарность каким-либо способом. АРМ позволяет, например, выполнить SWI, можно просто запрещать прерывания на входе в критическую секцию, при выходе - разрешать, но тогда если при входе если были запрещены прерывания, при выходе они разрешатся... иначе нужно при входе не просто запрещать, а сохранять регистр статуса, затем запрещать прерывания, а при выходе всего-лишь восстанавливать что было. Можно вообще завести обработчик IRQ, в который вваливаться через VICSoftInt, а там творить чего угодно, пока не разрешили вложенные прерывания...

Я не понял :-( Вообще ничего из вышеизложенного не понял.
Если речь идет о том, что Вы имеете некоторую процедуру,которая для обеспечения ее непрерывности
обрамлена critical и по этой причине ее нельзя вызывать из обработчика прерывания, то
0. Нужно делать вещи максимально близкие к естественным.
1. Делается процедура без запретов.
2. Для работы в прерывании вызывается прямо или через прямую макроподстановку
3. Для прочего использования через макрос-обертку с __disable/enable.
Если обработчики прерываний в отдельном файле, то макроимена могут быть вообще одинаковыми.
В результате начисто отпадают все ненужные навороты как в виде 'счетчиков', так и ввиде 'сохранений', заодно не надо вникать в реализацию critical в каждой конкретной операционке.

Все выглядит (живой пример) примерно так:

Код

//-----------------------------------------------------------
// Read/Write SLIC Registers with CLOSED interrupts
void wr_sreg_int( BYTE channel, BYTE reg,  BYTE value );
......
//-----------------------------------------------------------
// Read/Write SLIC Registers
#define wr_sreg( x, y, z )             \
{    __disable_interrupt();          \
    wr_sreg_int( x, y, z );            \
    __enable_interrupt();  }

......

2 zltigo

У меня насчёт правильности запрещения/разрешения прерываний вопрос к Вам остался.
Представьте себе, что пишет подпрограмму с критической секцией не Вы, а коллега. Вы эту подпрограмму интегрируете в свой проект.
Ответьте, пожалуйста, на каком основании Ваш коллега имеет право разрешать прерывания (при выходе из критической секции), если он не узнаЁт при запрещении (при входе в критическую секцию), были ли они (прерывания) разрешены?

Так они и не будут разрешены если Вы вызвали его из критической секции и соответственно
счетчик на входе в подпрограмму колеги уже не будет 0. Ежели коллега, или Вы пожелает в _прикладной_ программе воспользоваться прямым запретом/разрешением вместо critical , то, как здесь уже было замечено, надо наказывать, ибо против лома нет приема.

Я о варианте, когда в основной программе прерывания в какой-то прекрасный момент выключены не в критической секции. Как быть с разрешением в подпрограмме коллеги?

[zltigo]

Я о варианте, когда в основной программе прерывания в какой-то прекрасный момент выключены не в критической секции. Как быть с разрешением в подпрограмме коллеги?

Мне казалось, что я ответил. У меня, тогда больше нет слов для обьяснения :-(.
Попробуйте перечитать написанное в моем предыдущем посте.

[sensor_ua]

Я о варианте, когда в основной программе прерывания в какой-то прекрасный момент выключены не в критической секции. Как быть с разрешением в подпрограмме коллеги?

Мне казалось, что я ответил. У меня, тогда больше нет слов для обьяснения :-(.
Попробуйте перечитать написанное в моем предыдущем посте.

ИМХО, Вы приняли как за оскорбление мое мнение об критической секции в конкретной ОС - FreeRTOS и, рассказав о недостатках реализации в другой ОС- TNKernel (а точнее других, потому как ассемблерная часть в uCOS-II и TNKernel совпадает, вероятно и в других ОС) пытаетесь доказать, что сам механизм выбран неверно, а я от Вас пытаюсь получить четкие пояснения преимуществ/недостатков механизма, который в коммерческой ОС uCOS-II не применяется, хотя написано, что о нем хорошо знают. Я не понимаю как можно не проверив, было ли разрешено прерывание перед входом в критическую секцию, после окончания таковой его взводить. Вы же мне о Вашем мнении об разных ОС и макрообертках