реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Вопрос по стилю программирования, Cortex-M3 и вечные прерывания
=Zap=
сообщение Apr 23 2011, 04:58
Сообщение #1


Участник
*

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



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

Сообщение отредактировал =Zap= - Apr 23 2011, 04:58
Go to the top of the page
 
+Quote Post
swisst
сообщение Apr 23 2011, 06:46
Сообщение #2


Частый гость
**

Группа: Свой
Сообщений: 163
Регистрация: 16-02-07
Из: Харьков
Пользователь №: 25 425



надолго зависать в прерывании любого уровня идеологически неправильно, ИМХО.
Вложенные прерывания - да, пожалуйста...главное - обозначить приоритеты и вперед...
Go to the top of the page
 
+Quote Post
aaarrr
сообщение Apr 23 2011, 06:56
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448



А зачем это нужно?
Go to the top of the page
 
+Quote Post
Petka
сообщение Apr 23 2011, 08:58
Сообщение #4


Профессионал
*****

Группа: Свой
Сообщений: 1 453
Регистрация: 23-08-05
Пользователь №: 7 886



Цитата(=Zap= @ Apr 23 2011, 08:58) *
Нормально ли писать прошивку для процессора Cortex-M3, где всё время выполняется прерывание с низким приоритетом, а остальные прерывания прерывают его, так как их приоритет выше?
....

Хм.
int main() с вечным while(1) тоже фактически обработчик немаскируемого прерывания Reset.
Так что "идеологически" ваш вариант тоже правильный. Но тут встаёт вопрос: а зачем Вам так делать, если за вас и так уже всё так и сделано?
Go to the top of the page
 
+Quote Post
firstvald
сообщение Apr 23 2011, 13:30
Сообщение #5


Знающий
****

Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041



Все равно на каком процессоре пишем - в прерывании ставится лишь самое необходимое, все что можно вынести в основной цикл - убирается туда. Куда ж деваться, у меня несколько временных сеток в прибре крутится и прерывания от последовательного порта и все друг друга дергают. Так и живем.
Go to the top of the page
 
+Quote Post
=Zap=
сообщение Apr 24 2011, 09:44
Сообщение #6


Участник
*

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



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

Если интересны детали, то я решаю проблему о пересылке команд управления из USB в несколько устройств по шине I2C и обратно. У I2C так организован протокол, что ведомое устройство не может само прислать ответ на команду. Поэтому удобно сразу после пересылки команды требовать ответа на неё. То есть проводить одну транзакцию вопрос-ответ не выходя из прерывания USB. С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение.
Go to the top of the page
 
+Quote Post
scifi
сообщение Apr 24 2011, 09:57
Сообщение #7


Гуру
******

Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136



Цитата(=Zap= @ Apr 24 2011, 13:44) *
С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение.

С этого надо было начинать. Тут вопрос вовсе не в стиле программирования, когда и тот, и другой вариант работают, а хочется выбрать вариант "покрасивее".
Конечно, нельзя "подвешивать" процедуры обработки USB. Похоже, у Вас как раз тот случай, когда обработчик прерывания должен выполняться быстро. Следовательно, обработчик не может делать длительные ожидания. Так что надо реализовывать обработку USB и I2C ассинхронно.
Go to the top of the page
 
+Quote Post
firstvald
сообщение Apr 24 2011, 10:20
Сообщение #8


Знающий
****

Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041



Цитата(=Zap= @ Apr 24 2011, 12:44) *
Я как раз колеблюсь между мнением swisst про идеалогическую неправильность и мнением Petka, про то, что вечный while тоже как бы зависание в самом низком приоритете. Как я понимаю из дискуссии, никаких принципиальных отличий или ограничений зависание в прерывании не накладывает.


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

Ну и основной цикл должен тоже получать адекватное время для работы.
Go to the top of the page
 
+Quote Post
Petka
сообщение Apr 24 2011, 11:44
Сообщение #9


Профессионал
*****

Группа: Свой
Сообщений: 1 453
Регистрация: 23-08-05
Пользователь №: 7 886



Цитата(=Zap= @ Apr 24 2011, 13:44) *
...
Если интересны детали, то я решаю проблему о пересылке команд управления из USB в несколько устройств по шине I2C и обратно. У I2C так организован протокол, что ведомое устройство не может само прислать ответ на команду. Поэтому удобно сразу после пересылки команды требовать ответа на неё. То есть проводить одну транзакцию вопрос-ответ не выходя из прерывания USB. С другой стороны, зависание USB в ожидании ответа по I2C может сломать USB соединение.

В таком контексте в прерывании сидеть нельзя. Т.к. ответ по I2C абсолютно независимое от времени внешнее событие. Его железка теоретически может и не дождаться. Не, это моветон.
Go to the top of the page
 
+Quote Post
нечитатель
сообщение Apr 24 2011, 20:57
Сообщение #10


Местный
***

Группа: Участник
Сообщений: 235
Регистрация: 20-11-10
Пользователь №: 61 032



Цитата(=Zap= @ Apr 24 2011, 13:44) *
вечный while тоже как бы зависание в самом низком приоритете
Сохранение+восстановление контекста.

(написал глупость, зато отметился)
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 2nd July 2025 - 20:32
Рейтинг@Mail.ru


Страница сгенерированна за 0.01423 секунд с 7
ELECTRONIX ©2004-2016