|
|
  |
Вопрос по стилю программирования, Cortex-M3 и вечные прерывания |
|
|
|
Apr 23 2011, 04:58
|
Участник

Группа: Участник
Сообщений: 29
Регистрация: 7-01-09
Пользователь №: 42 985

|
Нормально ли писать прошивку для процессора Cortex-M3, где всё время выполняется прерывание с низким приоритетом, а остальные прерывания прерывают его, так как их приоритет выше? Контроллер NVIC в процессоре достаточно навороченный и вроде умеет прерывать одни прерывания более высокоприоритетными. С другой стороны даже надолго зависать в низкоприоритетном прерывании уже идеалогически неправильно, ИМХО. Какие могут возникнуть проблемы от такого подхода? Речь идёт о контроллерах TI серии Stellaris.
Сообщение отредактировал =Zap= - Apr 23 2011, 04:58
|
|
|
|
|
Apr 23 2011, 08:58
|
Профессионал
    
Группа: Свой
Сообщений: 1 453
Регистрация: 23-08-05
Пользователь №: 7 886

|
Цитата(=Zap= @ Apr 23 2011, 08:58)  Нормально ли писать прошивку для процессора Cortex-M3, где всё время выполняется прерывание с низким приоритетом, а остальные прерывания прерывают его, так как их приоритет выше? .... Хм. int main() с вечным while(1) тоже фактически обработчик немаскируемого прерывания Reset. Так что "идеологически" ваш вариант тоже правильный. Но тут встаёт вопрос: а зачем Вам так делать, если за вас и так уже всё так и сделано?
|
|
|
|
|
Apr 24 2011, 09:44
|
Участник

Группа: Участник
Сообщений: 29
Регистрация: 7-01-09
Пользователь №: 42 985

|
Я как раз колеблюсь между мнением swisst про идеалогическую неправильность и мнением Petka, про то, что вечный while тоже как бы зависание в самом низком приоритете. Как я понимаю из дискуссии, никаких принципиальных отличий или ограничений зависание в прерывании не накладывает.
Если интересны детали, то я решаю проблему о пересылке команд управления из USB в несколько устройств по шине I2C и обратно. У I2C так организован протокол, что ведомое устройство не может само прислать ответ на команду. Поэтому удобно сразу после пересылки команды требовать ответа на неё. То есть проводить одну транзакцию вопрос-ответ не выходя из прерывания USB. С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение.
|
|
|
|
|
Apr 24 2011, 09:57
|
Гуру
     
Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136

|
Цитата(=Zap= @ Apr 24 2011, 13:44)  С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение. С этого надо было начинать. Тут вопрос вовсе не в стиле программирования, когда и тот, и другой вариант работают, а хочется выбрать вариант "покрасивее". Конечно, нельзя "подвешивать" процедуры обработки USB. Похоже, у Вас как раз тот случай, когда обработчик прерывания должен выполняться быстро. Следовательно, обработчик не может делать длительные ожидания. Так что надо реализовывать обработку USB и I2C ассинхронно.
|
|
|
|
|
Apr 24 2011, 20:57
|
Местный
  
Группа: Участник
Сообщений: 235
Регистрация: 20-11-10
Пользователь №: 61 032

|
Цитата(=Zap= @ Apr 24 2011, 13:44)  вечный while тоже как бы зависание в самом низком приоритете Сохранение+восстановление контекста. (написал глупость, зато отметился)
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|