Jump to content

    
Sign in to follow this  
=Zap=

Вопрос по стилю программирования

Recommended Posts

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

Речь идёт о контроллерах TI серии Stellaris.

Edited by =Zap=

Share this post


Link to post
Share on other sites

надолго зависать в прерывании любого уровня идеологически неправильно, ИМХО.

Вложенные прерывания - да, пожалуйста...главное - обозначить приоритеты и вперед...

Share this post


Link to post
Share on other sites
Нормально ли писать прошивку для процессора Cortex-M3, где всё время выполняется прерывание с низким приоритетом, а остальные прерывания прерывают его, так как их приоритет выше?

....

Хм.

int main() с вечным while(1) тоже фактически обработчик немаскируемого прерывания Reset.

Так что "идеологически" ваш вариант тоже правильный. Но тут встаёт вопрос: а зачем Вам так делать, если за вас и так уже всё так и сделано?

Share this post


Link to post
Share on other sites

Все равно на каком процессоре пишем - в прерывании ставится лишь самое необходимое, все что можно вынести в основной цикл - убирается туда. Куда ж деваться, у меня несколько временных сеток в прибре крутится и прерывания от последовательного порта и все друг друга дергают. Так и живем.

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение.

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

Конечно, нельзя "подвешивать" процедуры обработки USB. Похоже, у Вас как раз тот случай, когда обработчик прерывания должен выполняться быстро. Следовательно, обработчик не может делать длительные ожидания. Так что надо реализовывать обработку USB и I2C ассинхронно.

Share this post


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

 

Если тело таймерного прерывания будет длиннее интервала прерывания вы получите диво дивное. В Сишных прогах еще как то будет работать, под ОС вероятнее всего грохнется вся ОС через какое-то время.

 

Ну и основной цикл должен тоже получать адекватное время для работы.

 

Share this post


Link to post
Share on other sites
...

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this