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

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> Размер стека
rezident
сообщение Nov 23 2012, 13:09
Сообщение #16


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



Цитата(_Артём_ @ Nov 23 2012, 01:35) *
Мне как-то трудно представить, зачем допускать ситуацию, когда вложенность одного и того же прерывания больше 1. Разрешить работать другим прерываниям - понятно, а так - не очень.
Ну мало ли какие алгоритмы работы встречаются. Иногда бывает, что весь алгоритм выполняется внутри одного единственного прерывания, а main при этом просто пустой цикл. Сходу могу припомнить только один пример - перерывание "системных тиков" в котором работает программный RTC. Счетчик RTC должен инкрементироваться на каждый "системный тик", а все остальное, обслуживаемое в данном прерывании, может и подождать. В случае, когда период вызова "системных тиков" оказывается меньше, чем время его обработки, часть его можно "обойти", вызвав лишь функцию RTC. Но для этого нужен какой-то детектор вложенности прерываний, хотя бы в виде счетчика.
Цитата(_Артём_ @ Nov 23 2012, 01:35) *
Обычно так и делаю (на АВР правда, но какая разница). Но перед этим запрещаю тот обработчик, который выполняется в текущий момент.
Да, так и делают при необходимости. Дело в том, что у MSP430 не все флаги прерываний сбрасываются автоматически при переходе по вектору прерывания. Некоторые сбрасываются лишь при определеных условиях (после чтения регистра статуса UART, например), а другие вообще только программно очищаются (P1IFG и P2IFG, например). Бит GIE же при переходе по вектору прерывания автоматически сбрасывается всегда.
Go to the top of the page
 
+Quote Post
Steve Key
сообщение Dec 5 2012, 11:43
Сообщение #17





Группа: Новичок
Сообщений: 2
Регистрация: 6-05-09
Пользователь №: 48 738



Цитата(_Артём_ @ Nov 23 2012, 00:35) *
Мне как-то трудно представить, зачем допускать ситуацию, когда вложенность одного и того же прерывания больше 1.

Это называется "реэнтерабельность" прерываний, т. е., способность входить в прерывание, пока оно не закончено, и не разрушить программу, видимо, иногда нужная штука... biggrin.gif
Go to the top of the page
 
+Quote Post
zhevak
сообщение Dec 5 2012, 17:25
Сообщение #18


Знающий
****

Группа: Свой
Сообщений: 723
Регистрация: 29-08-05
Из: Березовский
Пользователь №: 8 065



Реентерабебльность (от re-enter -- повторный вход) -- это, конечно, хорошо! Но всему должна быть мера.

Реентерабельность обычных функций (не обработчиков прерываний) -- это нормальное явление. Хотя оно и требует к себе повышенного внимания. То есть вполне допустимо, если вы понимаете, что вы делаете, и что на самом деле у вас в системе происходит.

Реентерабельность прерываний -- это уже из области работы со взрывчаткой. Тут, в отличие от простых функций, внимание этому вопросу нужно уделять максимальное. Если вы профи, то, если что, вы наверняка разберетесь со странным поведением системы. Но если вы только-только, то геммор на несколько дней вам обеспечен без гарантии того, что вам вообще удастся обуздать ситуацию.

Вообще реентерабельность прерываний подразумевает то, что прерывания разбиты на несколько уровней -- по приоритетам. Более приоритетные прерывания имеют право прерывать работу обработчиков прерываний с более низким приоритетом. (Блин, ну и тавтология. Сам поражаюсь!) Реентерабельность прерываний -- это вынужденная мера. Это нужно делать только тогда, когда другими способами не удается разрулить работу системы (девайса). По возможности нужно избегать реентерабельности прерываний.

Если реентерабельность прерываний одного уровня -- очень и очень сомнительна (это явно не от великого ума), то реентерабелность одного прерывания -- это мега-зло!

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

Во всех остальных случаях, следует придерживаться следующей логики. Из нескольких, одновременно возникших в системе событий мы должны создать очередь, и последовательно их обработать. Например, одновременно пришедшие события от клавиатуры, мышки и RS485, могут быть обработаны в ЛЮБОМ порядке относительно друг друга. Собственно, порядок их обработки может быть легко измениться, если какое-то событие возникнет на мгновение раньше другого. Невозможно учесть абсолютно все жизненные ситуации, поэтому проще считать, что

"мы будем бороться с проблемами в порядке их возникновения" (с) не помню чье высказывание

Вообще это очень большая тема и конкретное решение по реентерабельности прерываний нужно рассматривать не абстрактно, а применительно и конкретно.


--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
Go to the top of the page
 
+Quote Post

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

 


RSS Текстовая версия Сейчас: 25th August 2025 - 20:53
Рейтинг@Mail.ru


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