Вопросы настройки, программирования, прошивки микроконтроллеров и микросхем программируемой логики
Тема закрыта

Re: AVR прерывание прерывания

Вт июл 24, 2012 11:58:53

ILYAUL писал(а):Ну вообще-то это стандартный подход к написанию обработчиков прерываний.
Я бы скорее сказал не "стандартный", а "более корректный". Я удивлюсь, если окажется, что хотя бы один из десяти разработчиков встроенных программ пишет именно так.
ILYAUL писал(а):Это Вы давненько с asm не работали, портировать его с платформы на платформу не так уж и сложно. Главное правильно сразу написать макросы.
То есть Керниган и Ритчи потратили время на разработку достаточно хорошо портируемого языка впустую, не зная про макросы? И достаточно просто, скажем, перейти с CISC на RISC (или обратно) разной разрядности простым набором макросов?

Re: AVR прерывание прерывания

Вт июл 24, 2012 13:51:43

Ну, в этом случае и с трудами Кернигана и Ритчи тоже не всё так гладко. Те же макросы, прослойки, HALы всякие...

Re: AVR прерывание прерывания

Вт июл 24, 2012 14:31:46

Не гладко, но хотя бы реально при разумных трудозатратах. Кабы каждую машинную команду пришлось переносить, не видать бы нам сегодня UNIX'а и его наследников на всевозможном железе - почили бы в бозе вместе со своими монструозными непортабельными собратьями.

Впрочем, это нас уже немного в сторону высоких материй утянуло. Как насчет первоначального вопроса (о вложенных вызовах нереентерабельного обработчика и связанных с этим проблемах), прояснил ситуацию или не совсем?

Re: AVR прерывание прерывания

Вт июл 24, 2012 20:24:29

В общих чертах понятно . Если появится конкретика , понятно кому написать.

Re: AVR прерывание прерывания

Вт июл 24, 2012 21:40:01

конечно если обнулять переменную то можно и не одну милисекунду потерять.а если вычесть из большего чем 1000 тысячу, то ничего страшного не произойдет.
ну конечно еще нужно учитывать,что прерывание может произойти между сравнением и действием, тогда конечно может произойти неправильное действие(с устаревшим результатом)
в общем случае счетчик самих секунд можно добавлять и отнимать из милисекунд в основном цикле я так понимаю эту картину.
а вообще в самом прерывании можно разрешить вложенные только после выполнения критической части,которая может вызвать такие казусы в процессе работы.

Re: AVR прерывание прерывания

Вт июл 24, 2012 22:05:33

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

Re: AVR прерывание прерывания

Вт июл 24, 2012 22:15:30

vitalik_1984 писал(а):а вообще в самом прерывании можно разрешить вложенные только после выполнения критической части,которая может вызвать такие казусы в процессе работы.
Правильно. Выделение критической секции кода и введение блокировки, которая позволяет лишь одному потоку управления одновременно находиться в критической секции (а временный запрет вложенных прерываний как раз и есть наиболее простая реализация такой блокировки при отсутствии объектов ядра ОС наподобие семафоров или мьютексов) делает подпрограмму обработки прерывания реентерабельной, так что к ней уже не относятся указанные проблемы.

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

Re: AVR прерывание прерывания

Вт июл 24, 2012 22:15:42

по нормальному так и надо делать в обработчике прерывания, сохранять все используемые обработчиком регистры и обязательно флаговый регистр

А разве получится как-то иначе? Я думал, это давно аксиома. Так же, как и обеспечение атомарного доступа к данным.

как раз и есть наиболее простая реализация такой блокировки при отсутствии объектов ядра ОС наподобие семафоров или мьютексов

Ну тут не стоит сравнивать, процессы (потоки) в многозадачной ОС - несколько другое. Каждый из них выполняется в отдельном контексте, и задача программиста лишь синхронизировать обмен данными между ними.

Re: AVR прерывание прерывания

Вт июл 24, 2012 22:30:11

zero648 писал(а):Чтобы прерывания не испортили результат сравнения перед действием, флаги сохранить бы не плохо, по нормальному так и надо делать в обработчике прерывания, сохранять все используемые обработчиком регистры и обязательно флаговый регистр, тогда и думать лишний раз не придется, что прерывание чего-то там испортит.
Проследите внимательнее последовательность действий в предложенном примере. Там вложенное прерывание происходит уже после того, как произошел условный переход, и флаги уже не имеют никакого значения. Сохранение флагов ничего не изменит в данной ситуации. А вообще сохранение контекста при входе в обработчик с последующим восстановлением перед выходом и без того должно делаться обязательно, иначе первое же прерывание обрушит фоновую программу, даже если не будет никакой вложенности.

Re: AVR прерывание прерывания

Вт июл 24, 2012 22:40:52

Ну всяко бывает, может и не получиться :tea:

Re: AVR прерывание прерывания

Вт июл 24, 2012 22:54:19

Если по примеру, то получается каждый обработчик разрешает вложенное прерывание, так чтоли? Получается ведь снежный ком. А если, допустим, какой то конкретный обработчик будет разрешать только определенное вложенное прерывание, а остальные отключать до конца работы обработчика.

Re: AVR прерывание прерывания

Вт июл 24, 2012 23:04:30

ploop писал(а):А разве получится как-то иначе? Я думал, это давно аксиома. Так же, как и обеспечение атомарного доступа к данным.
Более того, при использовании, например, GCC (другими не пользуюсь, поэтому не в курсе) нужно специально постараться, чтобы сохранение РОН и флагов не было сделано автоматически. Равно как и атомарность обработчика.

ploop писал(а):процессы (потоки) в многозадачной ОС - несколько другое. Каждый из них выполняется в отдельном контексте...
От реализации модели потоков зависит. Например, в Protothreads, где кооперативная многопоточность реализована через сопрограммы, контекст вовсе отсутствует, а синхронизация все равно необходима (впрочем, это опять лежит далеко за пределами данной темы).

Re: AVR прерывание прерывания

Вт июл 24, 2012 23:10:55

zero648 писал(а):Получается ведь снежный ком.
Именно так. Поэтому нужно очень крепко подумать, прежде чем решиться реализовать в своей системе вложенные прерывания (под вложенными я имею в виду повторно входящие в тот же обработчик до его завершения). Польза весьма сомнительна (если прерывания поступают быстрее, чем их успевают обрабатывать, и начинают укладываться в матрешку, все равно при таком подходе быстро исчерпается стек), а проблем, как мы уже видели, возникает масса.

Re: AVR прерывание прерывания

Вт июл 24, 2012 23:31:27

А если, допустим, какой то конкретный обработчик будет разрешать только определенное вложенное прерывание, а остальные отключать до конца работы обработчика.

При такой тактике в принципе, можно поднять приоритет любому прерыванию, если обработчик прерывания с высшим приоритетом разрешит ему это, если например таймеру необходимо уложиться в срок, чтобы считать миллисекунды, мы впринципе тогда можем задать ему наивысший приоритет, даже выше чем INT0, скажем так, попросив любезнейший INT0 пропустить таймер вперед, все таки время не ждёт! :beer: , а остальные прерывания по боку, фейс контроль 8)

Re: AVR прерывание прерывания

Ср июл 25, 2012 00:18:09

zero648 писал(а):При такой тактике в принципе, можно поднять приоритет любому прерыванию
Да, в принципе можно назначить всем прерываниям собственные приоритеты и написать подпрограмму, которая при входе в обработчик будет запрещать прерывания с приоритетом ниже текущего. Возможно, для каких-то задач это окажется действительно полезно.

Впрочем, правильно написанный обработчик будет иметь минимальную длину (и время выполнения). Вполне может оказаться, что он выполняется быстрее, чем наш планировщик приоритетов решает, какие прерывания включить, а какие выключить. Главное, чтобы накладные расходы не превысили выгоды от такой гибкой системы приоритетов. А то получится, что лекарство хуже болезни, которую оно должно лечить.

Ну и еще такое соображение: кристаллы начального уровня с плоской одноуровневой системой прерываний обычно решают простые задачи, где такое сложное планирование, скорее всего, будет избыточным. А более серьезные устройства поддерживают многоуровневую систему аппаратно, там такие ухищрения попросту не понадобятся.

Re: AVR прерывание прерывания

Ср июл 25, 2012 12:19:39

Я считаю , что при написании обработчиков прерываний , нужно исходить из конкретно поставленной задачи. Даже самому низшему аппаратному прерыванию можно сделать наивысший приоритет программно.
Собтвенно прерывания высшего приоритета ( исходя из задачи) разрешены всегда и не требуют арбитража. Их обычно не много. Всегда можно отделить важное , от не очень - задача поставлена, приоритеты определены. Остальным можно написать арбитр. И вообще уйти в фоновый режим и обрабатывать младшие приоритеты не в основной программе , где опять могут действовать свои приоритеты. При этом вызов старших - прерывает фоновую задачу и проц может вообще "забыть" , что у него вообще существуют какие-то другие прерывания. При этом последующий возврат в фоновую задачу продолжится с прерванного места. Но тут уже "игрушки" со стеком.

Re: AVR прерывание прерывания

Ср июл 25, 2012 21:10:29

хе можно немного увеличить приоритет другого прерывания методом проверки флага запроса нужного прерывания.
сделать внутри другого прерывания добавку счетчика или другие действия, но опять же за счет увеличения нагрузки на ядро.
выглядит это следующим образом:
вместо разрешения прерываний 1.проверяем готовность флага
2.если необходимо, делаем вызов процедуры обработки флага.
3.сбрасываем флаг запроса прерывания.
в меньшем случае три слова кода внутри прерывания если только инкремент 1байтной переменной сделать.
а обработку в основном цикле.
поправьте если не прав в расчете, в асме я плаваю.:oops:

Re: AVR прерывание прерывания

Ср июл 25, 2012 23:40:09

Большое спасибо Goldsmith за очень информативный ответ. На нашем курсе программирования МК в универе такое слово как реентерабельность даже не упоминалось, поэтому я сильно удивился, увидев незнакомый термин :)) . Буду штудировать литературу.
Только еще один вопрос конкретного характера: AVR'ки (простые, типа mega, tiny) при входе в прерывание сами блокируют перерывания и насколько (полностью, только того же типа...) и зависит ли это поведение от языка программирования (асм или Сишка)?

Re: AVR прерывание прерывания

Ср июл 25, 2012 23:45:33

Флаг I (глобальный запрет прерываний) регистра SREG сбрасывается аппаратно при входе в прерывание, и устанавливается по команде RETI (по сути это RET + SEI ) . Так что тут не важно, какой язык.

Re: AVR прерывание прерывания

Ср июл 25, 2012 23:51:51

Опять большое спасибо. Можно не боятся вложенных прерываний :))
Тема закрыта