Цитата(amaora @ Jun 27 2016, 23:20)

Если переходит на rtos, то я надолго закопаюсь в переписывание всего кода под нее.
...
Да в документах arm об этом, что-то было. Только подразумевается смена приоритета для прерываний которые возникнут после этой смены. А не смена приоритета того, что выполняется в данный момент.
Берёте любой неиспользуемый в программе вектор аппаратного прерывания и используете его (возбуждаете это прерывание программно).
Никаких изменений приоритета на ходу делать конечно не надо. Если нужно чтобы управление попало в этот, программно возбуждаемый вектор, после завершения инициировавшего прерывания, то его приоритет делаете ниже чем у инициировавшего прерывания. Лучше даже ниже чем у любого настоящего аппаратного прерывания. Получается что-то типа задачи ОС, получающей управление по событию в инициирующем ISR.
Делал так не раз в разных проектах (и в давно работающих) на разных МК, там где и ОС при этом работает - всё прекрасно работает без проблем. Да и почему не должно работать?
Цитата(amaora @ Jun 27 2016, 23:20)

На стеке хранится значение регистра PSR в котором номер ISR, по которому похоже определяется приоритет прерывания после, например выхода из вложенного. А приоритеты хранятся в регистрах NVIC, может случится нехорошо если после выхода из вложенного прерывания окажется, что приоритет уже другой.
На стеке сохраняется
предыдущее значение PSR (и поле IPSR его в том числе) сохранённое при стэкинге. При выходе из прерывания оно будет просто восстановлено в PSR.
Текущее содержимое IPSR имхо просто маскирует содержмое регистра запросов NVIC (маскируются все прерывания с приоритетом ниже указанного в IPSR).
Цитата(GetSmart @ Jun 28 2016, 03:04)

То есть процессором это значение создаётся, но потом им не читается и ни на что не влияет.
Не может быть. Если более приоритетный ISR (номер N) прервал выполнение менее приоритетного (номер K), то после возврата из ISR N, что CPU должен записать в IPSR? Откуда он это определит? Вот как раз со стека он это считывает и заносит в PSR.