В этой версии оси появилось такое вообщем-то нужное средство как переключение стека во время выполнения isr на стек прерываний. Решил попробовать эту фичу. Объявил объект TISRW_SS в обработчике, залил в проц. На первый взгляд вроде бы все работает. Но... Посмотрел листинг обработчика и впал в некоторое недоумение. Перед переключением стека выполняется сохранение некоторых регистров в "старый" стек, чего в данном случае, насколько я понимаю, быть не должно. Ладно. Изменил макрос OS_INTERRUPT на __raw __interrupt. Сохранение регистров перед переключением стека соответственно исчезло, но программа работать перестала.

Вопрос к тем, кто глубоко копал эту ось. Описанное выше это нормально или это ошибка в коде или что-то еще? Может кто прокомментировать?

Это нормально. Это небольшая плата за независимость от компилятора и от трюков с __raw и связанных с этим сложностей в версии 2.0

[quote name='Сергей Борщ' date='Jan 23 2007, 17:17' post='200364']
[/quote]Это нормально. Это небольшая плата за независимость от компилятора и от трюков с __raw и связанных с этим сложностей в версии 2.0
[/quote]



Не понял. Нормально что? Сохранение регистров в стек пользовательского процесса перед переключением на стек прерывания при входе в isr? Так ведь переключение на стек прерывания и задуманно для того, чтобы не сохранять регистры в стек текущего процесса. Разве не так?

Зато все вложенные прерывания будут сохраняться в стеке прерываний.

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

А всякие финты с __raw, как уже сказали, в v3 убраны, т.к. как показала практика в этом кроется чуть ли не 90% причин неработоспособности программы. Тут требуется очень аккуратное использование (включая руление опциями компилятора) и отслеживание вручную результатов компиляции, т.к. поведение очень компиляторозависимое. Теперь код на входе в прерывание хоть и не такой оптимальный, зато вполне безопасный и не зависит от "причуд" компилятора.

На MSP430, кстати, очень маленький пролог - всего 4 регистра, т.ч. получается все достаточно неплохо. В в AVR картина намного печальнее.

Вот теперь все стало на свои места. Спасибо за ответы.

Кстати, насчет пролога:

как правило я это и наблюдаю, но были случаи когда сохранялись 7 регистров.

Да и еще вопросик. Если прерывание содержит оператор return где-нибудь в середине тела обработчика прерывания, например в инструкции if, то компилятор генерит предупреждение "Warning[Ta020]: Register SP updated while data is placed on the stack, code will probably not execute as expected
". Как бы, то есть, где бы правильно его подавить?
Если тело обработчика линейно- есть один опрератор return в конце- то предупреждения нет. По-видимому, предупреждение подавляется в коде ос (где-то я это видел).

Под прологом имелся в виду набор scratch регистров, т.е. тех, которые не сохраняются при вызове функций. Если внутри ISR имеет место вызов невстраиваемой функции, то компилятор просто обязан сохранить эти регистры (сохраняемые регистры - local - буду сохранены внутри вызываемой функции). Вот этот набор у MSP430&IAR и составляет 4 регистра.

Разумеется, если код самого ISR требует многих регистров, то все необходимые будут сохранены. Хоть все 12.



Хм, подавить-то не вопрос: #pragma diag_suppress=Ta20. Но тут надо внимательно разобраться, что является причиной - неспроста ж он ругается. Само по себе выражение return никак не может быть причиной - там же используется враппер, значит при любом выходе будет вызван деструктор, который восстановит стек прерванного процесса и вызовет планировщик. И этот самый return реально будет внутри сгенеренного кода переадресован к общему выходу. В общем, тут советую проявить осторожность. Если это просто компилятор "не въехал в тему", то тогда да, безопасно просто подавить "глупое" предупреждение . Лучше посмотреть по сгенеренному коду, что там реально меняется при добавлении этого выражения в середину ISR. На всякий случай.

Может натолкнет на размышления как грамотно подавить сообщение.
Файл OS_Target.h, функции SetISRStackPointer и SetStackPointer находятся именно в такой прагме. Если подавление убрать, то сообщения генерятся для каждого прерывания, где есть объявление объекта TISRW_SS независимо от количества и расположения точек выхода. Если подавление оставить, то, как уже писал, сообщения только в том случае, если есть выход из середины обработчка.
Конечно, можно написать обработчик так, чтобы return был один и в конце, но хочется разобраться в проблемной ситуации.