Сб июл 21, 2012 23:29:20
Вс июл 22, 2012 00:04:13
Вс июл 22, 2012 00:16:52
Вс июл 22, 2012 06:49:47
Вс июл 22, 2012 19:01:46
Вс июл 22, 2012 19:33:36
Вс июл 22, 2012 20:10:53
Совершенно верно. Если установлено одновременно несколько флагов запроса прерывания и установлен флаг Global Interrupt Enable, начнет выполняться разрешенное прерывание с наивысшим приоритетом.sx386 писал(а):Прочитал что прерывания выполняются в очереди приоритета, если срабатывают одновременно
Согласно старшинству приоритетов (см. выше): чем меньше адрес вектора, тем выше приоритет. Обычно приоритет INT0 выше, чем у INT1, но моделей AVR много, поэтому за все не могу ручаться.sx386 писал(а):Т.е. при одновременной подаче сигнала на INT0 и INT1 выполниться сначала INT0, а затем INT1
При входе в прерывание флаг Global Interrupt Enable автоматически сбрасывается, запрещая дальнейшие прерывания. Если он будет явно установлен в программе обработки прерывания, то новый запрос с наивысшим приоритетом прервет текущий обработчик. Приоритет прерывания уже запущенного обработчика при этом не имеет значения: если одновременно выставлены запросы INT0 и INT1 и оба они разрешены, начнет обрабатываться INT0; если далее в обработчике INT0 будет установлен флаг Global Interrupt Enable, то текущий обработчик будет вытеснен обработчиком INT1, а по его завершении будет продолжен (если кто-то еще снова не вытеснит).sx386 писал(а):А что будет если подать сигнал на INT0 в то время, когда выполняется код в INT1
Контроллер дождётся выполнения INT1, а затем запустит INT0 или прервёт INT1 и выполнит INT0 ?
Пн июл 23, 2012 01:06:39
BCluster писал(а):объем стека как бы при всем)))
Пн июл 23, 2012 10:28:42
Пн июл 23, 2012 22:10:37
Можете рассказать об этом подробнее или кинуть ссылочку, где об этом можно почитать?Goldsmith писал(а): Если обработчик прерывания нереентерабелен (что вполне вероятно), то повторное прерывание, возникшее во время обработки предыдущего, приведет к непредсказуемым последствиям.
Пн июл 23, 2012 23:16:08
где об этом можно почитать?
Что обычно делается процессором автоматически при входе в обработчик прерывания , если это прерывание разрешено или всё таки нет?Ну а если уж это невыполнимо, то хотя бы сбрасывать флаг разрешения данного прерывания в начале его обработки.
Пн июл 23, 2012 23:38:32
Пн июл 23, 2012 23:43:39
Если хотите подробно, то можно почитать, например, здесь:DrHlus писал(а):Goldsmith писал(а):Можете рассказать об этом подробнее или кинуть ссылочку, где об этом можно почитать?
void обработчик_прерывания_1кГц(void)
{
счетчик_миллисекунд++;
if (счетчик_миллисекунд >= 1000)
{ // прошла секунда
счетчик_миллисекунд = 0;
счетчик_секунд++;
}
// еще какие-то действия
}
Вт июл 24, 2012 00:21:34
Наличие нескольких пользователей вовсе не обязательно, иначе получилось бы, что весь код в однопользовательской системе автоматически становится реентерабельным, а это отнюдь не так. Реентерабельный код может выполняться параллельно несколькими потоками в процессе одного пользователя и даже в одном потоке, если это рекурсивный вызов.ILYAUL писал(а):Насколько я помню , реентерабельность относится к одному и тому же куску кода , которым одновременно могут воспользоваться несколько пользователей не мешая друг другу , при этом на код накладывается куча условий. И как это понятие применимо к вложенным прерываниям?
Jack Ganssle, Michael Barr. Embedded Systems Dictionary.reentrant adj. Said of software that can be executed multiple times simultaneously. A reentrant function can be safely called recursively or from multiple tasks. The key to making code reentrant is to ensure mutual exclusion whenever accessing global variables or shared registers.
Обычно в известных мне архитектурах (хотя, конечно, известны мне далеко не все) при входе в обработчик прерывания автоматически сбрасывается флаг запроса этого прерывания. Бит (он же флаг) разрешения прерывания остается неизменным, его следует устанавливать/сбрасывать явно в коде.Что обычно делается процессором автоматически при входе в обработчик прерывания , если это прерывание разрешено или всё таки нет?
Вт июл 24, 2012 00:44:16
Довольно часто (из собственной практики я бы даже сказал: "всегда", но жизнь зачастую оказывается разнообразнее наших представлений о ней) удается все же сократить обработчик прерывания до разумно-минимальных размеров, оставив в нем лишь действительно критичные по времени операции (например, забрать из регистров ввода данные, пока они не затерлись следующей порцией). Затем обработчик помещает событие в очередь и завершает работу. Обработкой данных из очереди займется уже другая задача в соответствии с назначенным ей приоритетом, которая никак не мешает прерываниям.ploop писал(а):Например: есть прерывание с относительно длительным обработчиком (и без него никак, либо очень сложно).
Вт июл 24, 2012 06:32:47
Вт июл 24, 2012 08:12:19
Точно. К тому же пример-то специально упрощенный, чтобы читателям проще логику отследить. А если к тому же обработчиков не два, а поболее, да к тому же глобально прерывания постоянно разрешены, и любой обработчик в любой момент перебивается другим экземпляром, в том числе самим собой по вложенной обработке, то получим неиссякающий источник непериодических глюков, причем очень трудно воспроизводимых в системе отладки (а то, что возможно в принципе, все равно рано или поздно произойдет).ploop писал(а):Я хотел сказать то, что вы в своём примере очень хорошо подчеркнули фразой "тем временем прошла миллисекунда", то есть второй обработчик может (т.е. такая ситуация в принципе возможна) перекрыть по времени первый.
Тут да, применять не в коем случае нельзя.
Goldsmith писал(а):Помимо переполнения стека, есть еще одни грабли, на которые можно наступить, разрешая прерывания внутри обработчика. Если обработчик прерывания нереентерабелен (что вполне вероятно), то повторное прерывание, возникшее во время обработки предыдущего, приведет к непредсказуемым последствиям. Причем диагностировать такую ситуацию гораздо сложнее, чем переполнение стека.
Вт июл 24, 2012 08:38:46
Вт июл 24, 2012 09:22:15
Тут ключевой момент:ploop писал(а):Так что не так страшен чёрт, если подходить с умом.
С таймером проще: вы точно знаете период прерываний, и если так же точно знаете длительность его обработки (в обработчике нет циклов и непредсказуемых условных операторов), то можете дать гарантию, что повторного вхождения в обработчик не будет. Заведомо кратковременный другой обработчик также не создает проблем (если только по INTx гарантированно исключен шквал запросов). В данном частном случае проблема реентерабельности не возникнет, конечно.ploop писал(а):2. Таймер ... сам на себя наложиться не может.
Вт июл 24, 2012 11:40:49
...Затем обработчик помещает событие в очередь и завершает работу.
...проще будет портировать на другую платформу при необходимости, если, конечно, они не на ассемблере писаны;