Выявил неприятное поведение при переключении задач в ОС, порт под msp430X.

Использую схему переключения задач


В обработчике прерывания используется обвертка TISRW или TISRW_SS.
При выходе из обработчика прерывания вызывается планировщик Kernel.SchedISR();



Установиться флаг прерывания, и должно сработать прерывание по переключению задач.
Но, пока мы находились в предыдущем обработчике, приходит время сработать системному таймеру (его обработчику).
Выходит, по выходу из прерывания мы попадаем в более приоритетное прерывание от таймера, а в нем разрешаются прерывания



и вот уже здесь вызовется обработчик прерывания по переключению задачи.
Ни к чему хорошему это не приводит, так как переменная ядра Kernel.ISR_NestCount будет инкрементирована и после переключения задач уже запорченой.
Как результат из задачи, куда мы переключились мы уже никогда не выйдем - зависнем.
Я правильно понял, что при scmRTOS_CONTEXT_SWITCH_SCHEME = 1 в других прерываниях никогда нельзя разрешать вложенных прерываний? Не только в системном таймере, а в любом прерывании, особенно если в нем используется TISRW или TISRW_SS?

Интересный эффект. Навскидку, обычные прерывания (без контакта с ядром ос) не должны портить картину - ну, возникло внутри них прерывание переключения контекста, управление ушло в другой процесс... когда оно обратно вернется в этот прерванный, выполнение продолжится в этом прерывании. Т.е. с точки зрения целостности выполнения кода ничего фатального нет (хотя надо, конечно, проверять, возможно есть какие-то побочные эффекты). Но вот точки зрения программы это все очень неправильно и нехорошо. Во-первых, прерывание вместо того, чтобы выполниться быстренько, просто "зависло" на непредсказуемое время. Во-вторых, прерывания, как правило не очень реентерабельны. В общем, лучше так не делать.

И вообще, я бы рекомендовал следующее - если процессор аппаратно не поддерживает какие-то средства, то надо очень хорошо подумать при использовании программных "костылей", которые как-то выполняют требуемую функциональность. Это касается, как раз, прерываний: использование отдельного стека на процессоре, где нет аппаратной поддержки отдельного стека прерываний и вложенных прерываний при одноуровнвом неприоритетном контроллере прерываний. В частности, обсуждаемый MSP430 как раз не имеет ни того, ни другого.

Использование отдельного стека прерываний следует применять очень осторожно и соблюдая следующую рекомендацию: не писать в теле обработчика прерываний код, а поместить этот код в отдельную вызываемую функцию (ни в коем случае не встраиваемую, чтобы компилятор не видел ее потрохов в точке вызова) и в теле обработчика сделать вызов. Это на практике гарантирует, что компилятор не производит никаких финтов с указателем стека до вызова переключателя стеков (которые, если имеют место, то приводят к фатальным последствиям). Но лично я придерживаюсь другого подхода - не делать ISR длинным (долгим), выполнить в нем минимум функций и как можно быстрее отдать управление в основную программу (дабы не держать другие ISR) - это позволяет, как правило, и не расходовать много стека в ISR, поэтому необходимости в переключении на отдельный стек в прерывании не возникает.

С вложенными прерываниями - ровно то же самое. Если процессор не имеет аппаратного приоритетного контроллера прерываний, то надо несколько раз подумать об использовании вложенных прерываний. И не только с осью, но и без нее (лично налетал еще на AVR по внешнему прерыванию (в котором было разрешение вложенных сделано), когда из-за помехи на входной пин валился "лес" импульсов и прерывание получилось существенно рекурсивным, а стек не резиновым оказался ). Стратегия та же самая - обеспечивать короткое время реакции на прерывание не путем разрешения вложенных, а тем, чтобы сделать прерывания короткими и быстрыми.

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

В случае с msp-gcc - не гарантирует Именно поэтому пришлось ввести доп. #define TISRW_SS_STACK_PAD, чтоб хоть как-то этим управлять. (Но это для просто msp).

Т.е. если просто вызов:


то все равно резервирует зачем-то в стеке место?

Да. Для массивного деструктора TISRW_SS.

вот это:


даёт вот что:

C переключением стека в прерывании для msp430 действительно как-то многовато кода получается, его не использую.
Его упомянул в связи с тем, что и для TISRW и для TISRW_SS в моем случае одинаковый эффект.
Как только в обработчике используется TISRW и разрешаются прерывания, то с большой вероятностью зависнет.
По этому, использовать схему переключения по прерыванию решил и дальше.
Ну а в обработчиках либо не использовать TISRW, либо не разрешать прерываний (я раньше использовал).

Да, я тоже предпочитаю не извращаться с возможностями, которых аппаратно нет. Тут все работает без сюрпризов.