=Zap= 0 23 апреля, 2011 Опубликовано 23 апреля, 2011 (изменено) · Жалоба Нормально ли писать прошивку для процессора Cortex-M3, где всё время выполняется прерывание с низким приоритетом, а остальные прерывания прерывают его, так как их приоритет выше? Контроллер NVIC в процессоре достаточно навороченный и вроде умеет прерывать одни прерывания более высокоприоритетными. С другой стороны даже надолго зависать в низкоприоритетном прерывании уже идеалогически неправильно, ИМХО. Какие могут возникнуть проблемы от такого подхода? Речь идёт о контроллерах TI серии Stellaris. Изменено 23 апреля, 2011 пользователем =Zap= Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
swisst 0 23 апреля, 2011 Опубликовано 23 апреля, 2011 · Жалоба надолго зависать в прерывании любого уровня идеологически неправильно, ИМХО. Вложенные прерывания - да, пожалуйста...главное - обозначить приоритеты и вперед... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 23 апреля, 2011 Опубликовано 23 апреля, 2011 · Жалоба А зачем это нужно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 апреля, 2011 Опубликовано 23 апреля, 2011 · Жалоба Нормально ли писать прошивку для процессора Cortex-M3, где всё время выполняется прерывание с низким приоритетом, а остальные прерывания прерывают его, так как их приоритет выше? .... Хм. int main() с вечным while(1) тоже фактически обработчик немаскируемого прерывания Reset. Так что "идеологически" ваш вариант тоже правильный. Но тут встаёт вопрос: а зачем Вам так делать, если за вас и так уже всё так и сделано? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 22 23 апреля, 2011 Опубликовано 23 апреля, 2011 · Жалоба Все равно на каком процессоре пишем - в прерывании ставится лишь самое необходимое, все что можно вынести в основной цикл - убирается туда. Куда ж деваться, у меня несколько временных сеток в прибре крутится и прерывания от последовательного порта и все друг друга дергают. Так и живем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=Zap= 0 24 апреля, 2011 Опубликовано 24 апреля, 2011 · Жалоба Я как раз колеблюсь между мнением swisst про идеалогическую неправильность и мнением Petka, про то, что вечный while тоже как бы зависание в самом низком приоритете. Как я понимаю из дискуссии, никаких принципиальных отличий или ограничений зависание в прерывании не накладывает. Если интересны детали, то я решаю проблему о пересылке команд управления из USB в несколько устройств по шине I2C и обратно. У I2C так организован протокол, что ведомое устройство не может само прислать ответ на команду. Поэтому удобно сразу после пересылки команды требовать ответа на неё. То есть проводить одну транзакцию вопрос-ответ не выходя из прерывания USB. С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 24 апреля, 2011 Опубликовано 24 апреля, 2011 · Жалоба С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение. С этого надо было начинать. Тут вопрос вовсе не в стиле программирования, когда и тот, и другой вариант работают, а хочется выбрать вариант "покрасивее". Конечно, нельзя "подвешивать" процедуры обработки USB. Похоже, у Вас как раз тот случай, когда обработчик прерывания должен выполняться быстро. Следовательно, обработчик не может делать длительные ожидания. Так что надо реализовывать обработку USB и I2C ассинхронно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 22 24 апреля, 2011 Опубликовано 24 апреля, 2011 · Жалоба Я как раз колеблюсь между мнением swisst про идеалогическую неправильность и мнением Petka, про то, что вечный while тоже как бы зависание в самом низком приоритете. Как я понимаю из дискуссии, никаких принципиальных отличий или ограничений зависание в прерывании не накладывает. Если тело таймерного прерывания будет длиннее интервала прерывания вы получите диво дивное. В Сишных прогах еще как то будет работать, под ОС вероятнее всего грохнется вся ОС через какое-то время. Ну и основной цикл должен тоже получать адекватное время для работы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 24 апреля, 2011 Опубликовано 24 апреля, 2011 · Жалоба ... Если интересны детали, то я решаю проблему о пересылке команд управления из USB в несколько устройств по шине I2C и обратно. У I2C так организован протокол, что ведомое устройство не может само прислать ответ на команду. Поэтому удобно сразу после пересылки команды требовать ответа на неё. То есть проводить одну транзакцию вопрос-ответ не выходя из прерывания USB. С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение. В таком контексте в прерывании сидеть нельзя. Т.к. ответ по I2C абсолютно независимое от времени внешнее событие. Его железка теоретически может и не дождаться. Не, это моветон. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_noise 0 24 апреля, 2011 Опубликовано 24 апреля, 2011 · Жалоба вечный while тоже как бы зависание в самом низком приоритетеСохранение+восстановление контекста. (написал глупость, зато отметился) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться