Созревает проект на LPC213x. Сюдя по всему конечным автоматом на таймере обойтись не получится ввиду большого числа событий и источников прерываний. Это на мой профанский взгляд. Да и надо наконец научиться писать с использованием RTOS. В связи с чем просьба к общественности посоветовать ПРОСТУЮ RTOS. И не просто посоветовать, а подсказать где ее взять. В принципе и купить можно, но сначала хотелось бы пощупать. Главное чтобы софт был качественно задокументирован, а то в С++ я как свинья в апельсинах, разбираться с исходниками не буду да и не смогу наверное. Мне бы на пальцах показать, как создать тред и исполнить в нем мой код. Соответственно хотелось бы иметь готовый порт на мой процик. Вытесняющая она должна быть или невытесняющая, еще не понял. Чтобы это понять, желательно Ваши примеры задач, для которых то или иное больше подходит.
Также просьба не отвечать вроде "да на хрена тебе ртос", "атмел sam7 рулит" и "ваще надо на асме писать"
С уважением, я
Полная версия этой страницы: Требуется совет по выбору RTOS
uCOS-II - распространённая, простая и нетребовательная к ресурсам РТОС; имеется подробная документация, а также разнообразные подключаемые модули (GUI, IP-стек и т.д.). На сайте можно взять готовые шаблоны проектов для LPC.
Цитата
На сайте можно взять готовые шаблоны проектов для LPC.
А так же роскошное руководство.
uCOS-II - первая мысль возникающая по прочтении вашего поста.
В принципе можно посмотреть также FreeRTOS, тоже неплохо описана и на LPC вроде уже портирована.
Еще можно посоветовать Tasking Library из CrossWorks
http://www.rowley.co.uk/documentation/arm/ctl.htm
Предельно простая, на чип портирована, все средства отладки по JTAG (включая отладочный prinf по JTAG, и доступ к файлам на PC через JTAG при помощи готовых С функций) есть.
http://www.rowley.co.uk/documentation/arm/ctl.htm
Предельно простая, на чип портирована, все средства отладки по JTAG (включая отладочный prinf по JTAG, и доступ к файлам на PC через JTAG при помощи готовых С функций) есть.
eCos тоже хвалят
...Я не приминул пригласить его критиков...
...Я не приминул пригласить его критиков...
Цитата(dch @ Apr 19 2006, 02:29) 
eCos тоже хвалят
У LPC213x для eCOS оперативной памяти маловато будет. Да трудно будет недостаточно опытному человеку разобраться в коде eCOS, который написан со всеми наворотами С++ как-то: шаблоны, исключительные ситуации и их обработка.
По теме.
1. FreeRTOS. Адрес - http://www.freertos.org . Сам не использовал, но порт для семейства LPC вроде бы существует. Исходники открыты.
2. embOS. Адрес - http://www.segger.de . Использовал сам при работе с микронтролерами Fujitsu F2MC. Впечатления очень приятные. Исходники недоступны. На сайте выложена библиотека для нескольких компиляторов под ARM. Есть ли среди них LPC213x - не знаю. У библиотеки есть ограничение - приложение может создать не более 3-х задач, но это достаточно легко обходится.
а embOS от UCOS вообще отличается ? Уж больно похоже что сеггер с микриум какое-то соглашение заключили или вообще слились... А вообще Nucleus рулит :-)
Всем спасибо, буду щупать uCOS-II. на местном фтп оно есть кстати? что-то не вижу... точнее, вообще ничего на нем не вижу =)
а CrossWorks не надо, и все иже с ним. Я с этим софтом не подружился как-то...
Цитата(DASM @ Apr 19 2006, 09:11)
а embOS от UCOS вообще отличается ?
В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры.
мужики, вы правда зря Nucleus игнорируете.. неплохая оська то.. Mentor... Accelated Technology/..знакомые слова - не так ли ? При этом скажу я вам - сурцы очень поняты, на чистом С, хорошая дока... А теперь сравним - какой-то Лябросс.. какая-то полудохлая оська, где все задачи надо с разным приоритетом... Сурцы UCOS - я вообще молчу.. попа... То есть что имею ввиду - для нормальной работы с исходниками всем необходим Visual Studio+Visual Assist - это понятно. Так вот - если натравить эту связку на Нуклеус - то все отлично переваривается и ядро как на ладони. На лябросовсские макросы - только красным цветом подсветит и все... По поводу порта, народ спрашивал.. Вобщем запустил... Но порт пока не выложу, впопыхах делал, потестировать бы побыстрее.. надо причесать..
А я решил в попытке решения подобной задачи (LPC2138 и куча всего по самые уши) TNKernel прикручивать. Пока по кусочкам - прикрутил вход-выход для критических секций (практически такой же, как в uCOSII). А вот FreeRTOS после анализа этих самых критических кусочков пришлось забраковать. Посмотрим дальше
...
...
так... а в uCOS-II какое количество задач поддерживается? и что по поводу приоритетов? действительно в uCOS все задачи должны быть разных приоритетов?
64 задачи.
Да, должны быть разными; впрочем, лично мне это до сих пор не мешало.
Да, должны быть разными; впрочем, лично мне это до сих пор не мешало.
Цитата
64 задачи.
Начиная с версии 2.80 255!!!
Цитата(jasper @ Apr 19 2006, 17:54)
Цитата
64 задачи.
Начиная с версии 2.80 255!!!
В тех приложениях, где ucos целесообразно исполльзовать, и 64 много.
В 255 сделали - имхо выпендриваются просто, типа нужно показать, что ось как-то развивается.
Цитата(alogvinov @ Apr 19 2006, 15:31)
Цитата(DASM @ Apr 19 2006, 09:11)
а embOS от UCOS вообще отличается ?
В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры.
что имеется ввиду?
кстати а программу для мониторинга висящих задач/загрузки из под виндовс где бы взять? вроде микриум ее не дает так просто... и как эта фича связана с C-SPY и что это такое?
Цитата(sensor_ua @ Apr 19 2006, 13:14)
А вот FreeRTOS после анализа этих самых критических кусочков пришлось забраковать.
???
Что такое жуткое вскрылось при анализе?
Цитата(Electrovoicer @ Apr 19 2006, 16:53)
кстати а программу для мониторинга висящих задач/загрузки из под виндовс где бы взять? вроде микриум ее не дает так просто... и как эта фича связана с C-SPY и что это такое?
uC-VIEW, качайтеhttp://rapidshare.de/files/18434373/uCOS-V...-V110.ZIP_.html
На ftp оно есть, но самого ftp пока нет.
Цитата(Evgeny_CD @ Apr 20 2006, 02:02)
Цитата(Electrovoicer @ Apr 19 2006, 16:53)
кстати а программу для мониторинга висящих задач/загрузки из под виндовс где бы взять? вроде микриум ее не дает так просто... и как эта фича связана с C-SPY и что это такое?
uC-VIEW, качайтеhttp://rapidshare.de/files/18434373/uCOS-V...-V110.ZIP_.html
На ftp оно есть, но самого ftp пока нет.
А интересно его кто пользовал? Помогает хоть как-то? Или так - веселые картинки?
А то я вроде сначала хотел, а потом лень стало поднимать.
FTP лежит, но думаю вот это оно
http://www.segger.com/embos_iar_plugin.html
http://www.segger.com/embos_iar_plugin.html
Цитата(DASM @ Apr 19 2006, 13:54)
мужики, вы правда зря Nucleus игнорируете.. неплохая оська то.. Mentor... Accelated Technology/..знакомые слова - не так ли ? При этом скажу я вам - сурцы очень поняты, на чистом С, хорошая дока... А теперь сравним - какой-то Лябросс.. какая-то полудохлая оська, где все задачи надо с разным приоритетом...
Проблема в том, что саму Nucleus найти проблема. Ссылки на uCos же есть на любом сайте соответствующей тематики.
Инерцию мышления со счетов тоже сбрасывать не стоит.
спасибо!
и все же что такое C-SPY?
и все же что такое C-SPY?
Цитата
и все же что такое C-SPY?
Так называется дебугер входящий в комлект IARовского компилятора.
Цитата(Andy Mozzhevilov @ Apr 19 2006, 16:18)
Цитата(alogvinov @ Apr 19 2006, 15:31)
Цитата(DASM @ Apr 19 2006, 09:11)
а embOS от UCOS вообще отличается ?
В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры.
что имеется ввиду?
Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС. Таймеров таких может быть произвольное количество. Его можно запустить, остановить, перезапустить, удалить.
Я начал использовать этот механизм в embOS. Мне понравилось.
Цитата(alogvinov @ Apr 20 2006, 11:26)
Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС. Таймеров таких может быть произвольное количество. Его можно запустить, остановить, перезапустить, удалить.
Я начал использовать этот механизм в embOS. Мне понравилось.
Я начал использовать этот механизм в embOS. Мне понравилось.
Реализация достаточно тривиальна, в любом окружении (с ос или без).
Цитата(alogvinov @ Apr 20 2006, 09:26)
Цитата(Andy Mozzhevilov @ Apr 19 2006, 16:18)
Цитата(alogvinov @ Apr 19 2006, 15:31)
Цитата(DASM @ Apr 19 2006, 09:11)
а embOS от UCOS вообще отличается ?
В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры.
что имеется ввиду?
Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС. Таймеров таких может быть произвольное количество. Его можно запустить, остановить, перезапустить, удалить.
Я начал использовать этот механизм в embOS. Мне понравилось.
Гы, я в свое время (да и сейчас часто) собственно всю систему и строю без оси. Некое подобие кооперативки выходит. Вобщем-то неплохо имхо, только задачки простые надо - там клапан включить, кнопку опросить и т п....
Цитата(alogvinov @ Apr 20 2006, 12:26)
Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС.
И на каком уровне эта функция реально вызывается - на уровне прерываний или на уровне задач? Если на уровне задач, то в контексте какой задачи она выполняется (в чьем стеке работает)?
Если я ничего не путаю, в uCOS 2.81 появилась реализация таймеров, как описано выше.
Цитата(zltigo @ Apr 19 2006, 21:27)
Цитата(sensor_ua @ Apr 19 2006, 13:14)
А вот 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 кажется обоснованным и разумным.
нифигаааа не понял......
В TNKernel и uCOS-II сохраняется регистр статуса и это видно по коду, а во FreeRTOS эти функции void. Может оно там тоже как-то сохраняется, но я не смог увидеть куда
Цитата(dxp @ Apr 20 2006, 10:30)
Цитата(alogvinov @ Apr 20 2006, 12:26)
Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС.
И на каком уровне эта функция реально вызывается - на уровне прерываний или на уровне задач? Если на уровне задач, то в контексте какой задачи она выполняется (в чьем стеке работает)?
Функция выполняется в контексте прерывания, со всеми вытекающими отсюда ограничениями.
Цитата(sensor_ua @ Apr 20 2006, 12:36)
В 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 кажется обоснованным и разумным.
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();
}
}
}
{
/* 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. Никаких проблем с реализацией вложений.
Хранения состояния не нужно, переменная для блокировок всего одна.
Специально скачал последнюю FreeRTOS 4.0.1, а то рассматривал 3.2.4, а там то, что теперь прозрачно, было написано асмовыми вставками - мне такое было тяжело читать
Насчет
Ваши замечания мне пришлось учесть (немного раньше, чем сегодня - макросы модифицировать открывающими/закрывающими фигурными скобками, побороться с "персональностью" переменной, соответственно ввести
Параноидальные требования возникли от безысходности - пишу дрова (в широком смысле - зачатки ОСи тоже) для имеющихся программистов - ребята попались с большими амбициями, непредсказуемым стилем программирования и тяжелым наследием незнания железа (непочитания дейташитов) - я завидую белой завистью их пофигизму, но работу делать надо. Пришлось положить избыточность в 500% в ресурсы железа(может больше - меги128 без внешнего ОЗУ на частоте 3.68МГц хватало) и...
А насчет
ещё раз скажу - в uCOS-II такой вариант имелся как самый низкий уровень паранойи - он понятен, имеет свои плюсы, но от него постарались отказаться.
Насчет
Цитата
Для сохрания состояния используется персональная поименованная переменная
Ваши замечания мне пришлось учесть (немного раньше, чем сегодня
- макросы модифицировать открывающими/закрывающими фигурными скобками, побороться с "персональностью" переменной, соответственно ввестиЦитата
обезличеный счетчик запретов
Параноидальные требования возникли от безысходности - пишу дрова (в широком смысле - зачатки ОСи тоже) для имеющихся программистов - ребята попались с большими амбициями, непредсказуемым стилем программирования и тяжелым наследием незнания железа (непочитания дейташитов) - я завидую белой завистью их пофигизму, но работу делать надо. Пришлось положить избыточность в 500% в ресурсы железа(может больше - меги128 без внешнего ОЗУ на частоте 3.68МГц хватало) и...
А насчет
Цитата
просты, как лом, откомментированы, и так-же надежно работают
ещё раз скажу - в uCOS-II такой вариант имелся как самый низкий уровень паранойи - он понятен, имеет свои плюсы, но от него постарались отказаться.
Цитата(sensor_ua @ Apr 20 2006, 20:50)
самый низкий уровень паранойи - он понятен, имеет свои плюсы, но от него постарались отказаться.
Ну а причины отказа? Я теряюсь в догадках!
Цитата
Специально скачал последнюю FreeRTOS 4.0.1, а то рассматривал 3.2.4, а там то, что теперь прозрачно, было написано асмовыми вставками - мне такое было тяжело читать
А аналогичный по назначению ASM код TNKernel 'легко'???
Да и где там ASM удалось углядеть? Там такой 'С' код испокон веку, я даже сам себе не поверил
и заклянул в 3.2.3.....
Все сказанное Вами по отношению к TNKernel прямо противоречит написанному вами-же:
Цитата
пишу дрова (в широком смысле - зачатки ОСи тоже) для имеющихся программистов - ребята попались с большими амбициями, непредсказуемым стилем программирования и тяжелым наследием незнания железа (непочитания дейташитов) - я завидую белой завистью их пофигизму, но работу делать надо.
Я бы понял, если Вы заговорили-бы об некоторой времени в асмописаных обрамителях критических
секций и чем-то подобном. Но то, что написано НЕ ВЯЖЕТСЯ с АККУРАТНО написанной, но
более НЕЖНОЙ в использовании, да и менее обкатанной NTKernel. Практически по тем-же причинам (постороние писатели прикладных программ произвольной квалификации) мною был сделан прямо противоположный вывод.
Цитата(zltigo @ Apr 20 2006, 21:54)
Цитата(sensor_ua @ Apr 20 2006, 20:50)
самый низкий уровень паранойи - он понятен, имеет свои плюсы, но от него постарались отказаться.
Ну а причины отказа? Я теряюсь в догадках!
Вот выдранное из os_cpu.h
/*
********************************************************************************
*************************
* ARM
*
* Method #1: Disable/Enable interrupts using simple instructions. After critical section, interrupts
* will be enabled even if they were disabled before entering the critical section.
* NOT IMPLEMENTED
*
* Method #2: Disable/Enable interrupts by preserving the state of interrupts. In other words, if
* interrupts were disabled before entering the critical section, they will be disabled when
* leaving the critical section.
* NOT IMPLEMENTED
*
* Method #3: Disable/Enable interrupts by preserving the state of interrupts. Generally speaking you
* would store the state of the interrupt disable flag in the local variable 'cpu_sr' and then
* disable interrupts. 'cpu_sr' is allocated in all of uC/OS-II's functions that need to
* disable interrupts. You would restore the interrupt disable state by copying back 'cpu_sr'
* into the CPU's status register.
********************************************************************************
*************************
*/
Цитата
Специально скачал последнюю FreeRTOS 4.0.1, а то рассматривал 3.2.4, а там то, что теперь прозрачно, было написано асмовыми вставками - мне такое было тяжело читать
А аналогичный по назначению ASM код TNKernel 'легко'???
Да, без переводчика и без проблем.
Все сказанное Вами по отношению к TNKernel прямо противоречит написанному вами-же:
Цитата
пишу дрова (в широком смысле - зачатки ОСи тоже) для имеющихся программистов - ребята попались с большими амбициями, непредсказуемым стилем программирования и тяжелым наследием незнания железа (непочитания дейташитов) - я завидую белой завистью их пофигизму, но работу делать надо.
Я бы понял, если Вы заговорили-бы об некоторой времени в асмописаных обрамителях критических
секций и чем-то подобном. Но то, что написано НЕ ВЯЖЕТСЯ с АККУРАТНО написанной, но
более НЕЖНОЙ в использовании, да и менее обкатанной NTKernel. Практически по тем-же причинам (постороние писатели прикладных программ произвольной квалификации) мною был сделан прямо противоположный вывод.
Если насчёт TNKernel применить вааще, то задача не применить ОС, а именно не дать этого увидеть
)) товаришчам
Цитата(sensor_ua @ Apr 20 2006, 22:04)
Ну а причины отказа? Я теряюсь в догадках!
Вот выдранное из os_cpu.h
/*
.....
*/
Вот выдранное из os_cpu.h
/*
.....
*/
Если о 'параное', но 'наивысший уровень' в TNKernel реализован сложнее и ненадежнее, нежели
в той-же FreeRTOS. Вот такие дела. Простое запрещение прерываний вообще никому не запрещено пременять с умом, естественно.
Цитата(zltigo @ Apr 20 2006, 22:28)
Цитата(sensor_ua @ Apr 20 2006, 22:04)
Ну а причины отказа? Я теряюсь в догадках!
Вот выдранное из os_cpu.h
/*
.....
*/
Если о 'параное', но 'наивысший уровень' в TNKernel реализован сложнее и ненадежнее, нежели
в той-же FreeRTOS. Вот такие дела. Простое запрещение прерываний вообще никому не запрещено пременять с умом, естественно.
Насчет "сложнее и ненадежнее", то интересны аргументы. Если только "персональность" переменной для хранения статуса, то уже обсуждали.
А насчет "Простое запрещение прерываний" хотелось бы отклониться в сторону - например, вспомнить spurious interrupt - AN10414 от Philips - ИМХО, это вообще сложный вопрос, и его действительно нужно решать "с умом, естественно".
Цитата(sensor_ua @ Apr 20 2006, 23:12)
Насчет "сложнее и ненадежнее", то интересны аргументы. Если только "персональность" переменной для хранения статуса, то уже обсуждали.
Еще раз повторить?
1. Сложнее - вместо простейшей обертки над стандартной де-факто библиотечной функции гарантированно работающей на любом процессоре. Писанная на асме чисто армовсая, да еще с заточкой под ARM Mode
2. Ненадежнее - легко ошибиться (особенно не зная потрохов и соответствено границ применимости)
при использовании вложеных критических секций. Про macros писал - ну просто подстава чистейшей воды. Практически использование недалеко ушло от аккуратного использования пресловутого запрещения прерывания.
Цитата
А насчет "Простое запрещение прерываний" хотелось бы отклониться в сторону
А ненадо отклоняться, ибо все равно оно имеет место быть.
Это TNKernel:
Код
tn_cpu_save_sr:
mrs r0,CPSR
orr r1,r0,#NOINT
msr CPSR_c,r1
;-- Atmel add-on
mrs r1,CPSR ;-- Check CPSR for correct contents
and r1,r1,#NOINT
cmp r1,#NOINT
bne tn_cpu_save_sr ;-- Not disabled - loop to try again
;--------
bx lr
mrs r0,CPSR
orr r1,r0,#NOINT
msr CPSR_c,r1
;-- Atmel add-on
mrs r1,CPSR ;-- Check CPSR for correct contents
and r1,r1,#NOINT
cmp r1,#NOINT
bne tn_cpu_save_sr ;-- Not disabled - loop to try again
;--------
bx lr
Это кусок IARовской библиотеки:
Код
cfi_ARM_BLOCK_start disableInterrupt_a
CODE32
??DiI_a
mrs r12,CPSR
orr r12,r12,#0xC0
msr CPSR_c,r12
mrs r12,CPSR
ands r12,r12,#+0xC0
beq ??DiI_a
bx lr
cfi_ARM_BLOCK_end disableInterrupt_a
CODE32
??DiI_a
mrs r12,CPSR
orr r12,r12,#0xC0
msr CPSR_c,r12
mrs r12,CPSR
ands r12,r12,#+0xC0
beq ??DiI_a
bx lr
cfi_ARM_BLOCK_end disableInterrupt_a
Как Вам разница?
Цитата(zltigo @ Apr 20 2006, 23:44)
Теперь о FreeRTOS:
void vPortEnterCritical()
void vPortExitCritical()
Имеют исходники. Они просты, как лом, откомментированы, и так-же надежно работают.
При входе прерывания безусловно запрещаются и наращивается обезличеный счетчик запретов.
При выходе разрешаются если счетчик запретов равен 0. Никаких проблем с реализацией вложений.
Хранения состояния не нужно, переменная для блокировок всего одна.
void vPortEnterCritical()
void vPortExitCritical()
Имеют исходники. Они просты, как лом, откомментированы, и так-же надежно работают.
Код
void vPortEnterCritical( void )
{
/* Disable interrupts first! */
[...skipped...]
}
}
{
/* Disable interrupts first! */
[...skipped...]
}
}
При входе прерывания безусловно запрещаются и наращивается обезличеный счетчик запретов.
При выходе разрешаются если счетчик запретов равен 0. Никаких проблем с реализацией вложений.
Хранения состояния не нужно, переменная для блокировок всего одна.
А зачем такие навороты с подсчетом входов, анализом их при выходе и т.д.? Тут, насколько я понимаю:
во-первых, прилично кода - накладные расходы, т.е.
во-вторых, а если при первом вызове прерывания были по какой-то причине запрещены? Ведь при выходе они будут разрешены, что есть нарушение логики работы программы.
Почему бы не использовать простую схему (псевдокод):
Код
CritEnter()
{
SaveInterruptState();
DisableInterrupt();
}
CritExit()
{
RestoreInterruptState();
}
{
SaveInterruptState();
DisableInterrupt();
}
CritExit()
{
RestoreInterruptState();
}
Все, ничего подсчитывать и анализировать не надо и логическая целостность программы не нарушается. Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функиций, но это надо делать при любом подходе. На С, к сожалению, это приходится делать руками, тут ничего не поделать. К счастью, на С++ этот момент поддается автоматизации, поэтому использование критических секций там тривиально и совершенно безопасно. :-)
объясните неразумному, почему EnterCriticalSection у вас ассоцируется с запретом прерываний ? Мне это как-то неочевидно..
Цитата(DASM @ Apr 21 2006, 11:46)
объясните неразумному, почему EnterCriticalSection у вас ассоцируется с запретом прерываний ? Мне это как-то неочевидно..
Назначение критических секций - сделать участок кода атомарным, то есть не допустить прерывания последовательности команд, заключенных в критическую секцию.
а мне всегда казалось, что назначение критических секций - это не допустить одновременного использования одного расшаренного ресурса разными потоками...... Про прерывания течения кода как-то читать не доводилось... Где я могу просветить свою темноту ?
Цитата(dxp @ Apr 21 2006, 08:42)
А зачем такие навороты с подсчетом входов, анализом их при выходе и т.д.?
-Ну про 'навороты' это уж перебор :-)
-Безболезненная вложенность.
-При использовании этого механизма без левых запретов прерывания будет отсутствовать
это:
Цитата
во-вторых, а если при первом вызове прерывания были по какой-то причине запрещены? Ведь при выходе они будут разрешены, что есть нарушение логики работы программы.
Цитата
прилично кода - накладные расходы, т.е.
Одного порядка, на самом деле, в FreeRTOS случае дополнительная работа со счетчиком
в памяти, в варианте "с сохранением" тоже работа с памятью - считать-запомнить-прочитать-записать.
Цитата
Почему бы не использовать простую схему (псевдокод):
....
Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функций, но это надо делать при любом подходе.
....
Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функций, но это надо делать при любом подходе.
-Увы, не единственное, вроде уже распинался :-(.
- в варианте "со счетчиком" комплементарность можно слегка нарушить :-) лишними вызовами
конца критической секции.
Цитата(DASM @ Apr 21 2006, 08:46)
объясните неразумному, почему EnterCriticalSection у вас ассоцируется с запретом прерываний ? Мне это как-то неочевидно..
У меня не ассоциируется, просто здесь речь идет о двух реалиациях оных в двух конкретных
системах, которые обе базируются на таком решении. Обсуждаются отличия, причем автором
во главу угла была поставлена (если я правильно все это понимаю) мнимая большая дуракоустойчивость TNKernel в сравнении c FreeRTOS.
Цитата(DASM @ Apr 21 2006, 12:01)
а мне всегда казалось, что назначение критических секций - это не допустить одновременного использования одного расшаренного ресурса разными потоками......
Нет, этот сервис предоставляется семафорами.
Цитата
Про прерывания течения кода как-то читать не доводилось... Где я могу просветить свою темноту ?
Да хоть не любимого тобой Лябрусса
, книгу по uCOS
назначение критических секций - не допустить одновременного выполнения одного и того же кода разными потоками.
Andy , ты перепутал семафор с мьютексом. К тому же критическая секция нужна именно для того что я сказал. Дж.Рихтер "Windows для профессионалов". Цитировать или веришь ? И совет - не читайте Лябруса :-D
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.