>> Существенное ограничение. Это затрудняет появление
>> портов операцинки на других МК, где имеется более
>> развитый, чем у ARM7, контроллер прерываний.

не затрудняет. В моем порте PIC24/dsPIC вложение явно разрешено. Только как правильно тут заметили - при активных прерываниях стека вам нужно будет очень много. Подтверждаю =(

Кстати, хороший контроллер прерываний (например как в PIC24, каждое прерывание физически на свой вектор, 7 пользовательских приоритетов) не всегда совместим с вытеснением: при возникновении прерывания стек автоматом сохраняется адрес возврата и часть SR (вход в обработчик прерывания - 5 тактов). Если в этот момент возникнет более приоритетное прерывание (в котором разрешено переключение контекста) будут кранты, так как счетчик вложенности инкрементировать некому.
Так что в следующей версии порта PIC24 прерывания с сервисами RTOS будут иметь только один фиксированный приоритет.

Противоречишь сам себе. Если бы было без затруднений, то не пришлось бы отказываться от вложенных прерываний с сервисами.

>> Противоречишь сам себе. Если бы было без затруднений,
>> то не пришлось бы отказываться от вложенных прерываний
>> с сервисами.

Читай внимательнее. TNKernel - обычная вытесняющая RTOS с отличной реализацией. Портировать ее на другую архитектуру проблем нет.
Проблемы есть с совместимостью контроллеров с аппаратной вложенностью прерваний с вытеснением задач из вложенного прервания - с uCOS, например, будет то же самое.

Если бы все прерывания в PIC24 аппаратно запрещались до момента выполнения первой инструкции в обработчике прерывания - проблем бы не было, так как в этой архитектуре можно запретить прерывания одной инструкцией на нужное количество тактов

Может мы о разном?
В uCOS-II вытеснение из любого уровня вложенного прерывания выполняется нормально, без крантов, проверено.

Господа, а не пойти ли вам в другую ветку ? Я серьезно. Бегло оглядел код порта ЮКОС под АРМ - вроде засада таже самая. Но может и нет - не важно. Кстати - никто не забыл, сколько ЮКОС стоит ? Надеюсь тут все законопослушны и купили её? А TNKernel - бесплатна, и при этом хороша. Господа, эта ветка про неконтролируемый расход стека в TNKernel при неудачном стечении обстоятельств. Как автор ветки - закрою нафик, от флуда. Давайте по делу. Пока что единственное чего я не услышал от Юрия - так это что проблема не надуманна - и в новых версиях исправления будут. Все остальное - ПЛИЗ - НЕ сюда

Дело в том, что ситуация, когда OS не может полностью войти в задачу, а уже вытесняется
прерыванием и это происходит постоянно, а не изредка, говорит о том, что OS работает очень близко к пределу своей производительности.
Эта ситуация нежелательна. Поэтому и в uCOS, и во многих других OS (коммерческих и
свободных) проблема, которую вычислил DASM, тоже присутствует. Ну просто никто не использовал OS на пределе...
Надо ли устранять проблему или просто уменьшить нагрузку на OS + увеличить стек ? Как я сейчас вижу, надо устранять - молодые люди любят выжимать из системы все и, наверное, они правы...


P.S To spf - Порт uCOS для ARM, кстати, не поддерживает вложенных прерываний. Там для отслеживания вложенности есть специальная переменная. Вступать в дискуссию на эту тему я не стану: хотите - верте, хотите - нет...

Нагрузка на систему со сторны обработчика прерывания естественно увеличивает вероятность 'эффекта' и меру пожирания стека, но сам эффект принципиально не исчезает и при слабой загрузке. В общем-то надо устранять, ибо никакими внешними организационными мерами 100% гарантии добиться не удастся .

Посмотрел - нет. Там везде такое:

cpsr одновременно с pc восстанавливается из spsr, соответственно никаких неуместных разрешений прерываний не образуется.

В uCOS это исправлено только в последних версиях, а в версии,
например, uCOS 2.76 проблема присутствует в полный рост.

Ноги у этой проблемы растут из кода (свободного), написанного
Michael Anburaj. Он использовался как основа для context switch как в
ранних версиях uCOS, так и в TNKernel. И Jean J. Labrosse, и я, наехали
на одни и те же грабли...

В uCOS это уже исправлено, в версии 2.4 TNKernel это будет исправлено.

А поддержка вложенности прерываний туда войдёт как вариант?

Я бы не стал - вложенные в приличной системе это уже в большей части отрыжка бессистемного писания. Практически при наличии у ARMов FIQ и использовании приличной операционной системы об использовании вложенных прерываний нужно ОЧЕНЬ крепко думать, прежде чем использовать. Если кому надо - пусть сам делает и заодно подумает а оно это надо такие навороты делать и цену которую платит за вложенность осознает.

zltigo, ну если цена высока, то может и не надо.
С другой стороны эту функциональность можно было бы добавить через условную компиляцию, кому как понадобится.
И в третьих Юрию самому виднее целесообразность этого шага и я бы не стал чуть что советовать всё делать самому, мало ли в какой степени мы все специалисты, а то уж больно смахивает на расхожую фразу: "Не нравится Windows (Linux, ...) - напиши себе лучше".

Прошу прощения у DASM за отклонение от темы.

Против такого подхода возразить сложно , разве только не провоцировать пользователей на потенциально туманное использование системы...

Приличная -- с многократным запасом производительности?
А как же золотая середина ?
Случаи бывают разные - http://electronix.ru/forum/index.php?showtopic=29678

"Запас по производительности" это даже не совсем характеристика системы.
В данном случае это система с малыми затратами на переключение задач.
По ссылке собственно случай и не описан. Только "хочу" что-бы каждое из восьми прерываний немедленно прерывало предыдущее. Вот такой "случай" и точка.