Вопрос по стилю программирования, Cortex-M3 и вечные прерывания Опции

[=Zap=]

Нормально ли писать прошивку для процессора Cortex-M3, где всё время выполняется прерывание с низким приоритетом, а остальные прерывания прерывают его, так как их приоритет выше? Контроллер NVIC в процессоре достаточно навороченный и вроде умеет прерывать одни прерывания более высокоприоритетными. С другой стороны даже надолго зависать в низкоприоритетном прерывании уже идеалогически неправильно, ИМХО. Какие могут возникнуть проблемы от такого подхода?
Речь идёт о контроллерах TI серии Stellaris.

Сообщение отредактировал =Zap= - Apr 23 2011, 04:58

[=Zap=]

Я как раз колеблюсь между мнением swisst про идеалогическую неправильность и мнением Petka, про то, что вечный while тоже как бы зависание в самом низком приоритете. Как я понимаю из дискуссии, никаких принципиальных отличий или ограничений зависание в прерывании не накладывает.

Если интересны детали, то я решаю проблему о пересылке команд управления из USB в несколько устройств по шине I2C и обратно. У I2C так организован протокол, что ведомое устройство не может само прислать ответ на команду. Поэтому удобно сразу после пересылки команды требовать ответа на неё. То есть проводить одну транзакцию вопрос-ответ не выходя из прерывания USB. С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение.

[Petka]

...
Если интересны детали, то я решаю проблему о пересылке команд управления из USB в несколько устройств по шине I2C и обратно. У I2C так организован протокол, что ведомое устройство не может само прислать ответ на команду. Поэтому удобно сразу после пересылки команды требовать ответа на неё. То есть проводить одну транзакцию вопрос-ответ не выходя из прерывания USB. С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение.

В таком контексте в прерывании сидеть нельзя. Т.к. ответ по I2C абсолютно независимое от времени внешнее событие. Его железка теоретически может и не дождаться. Не, это моветон.