Вопросы по С/С++ (СИ)

[WiseLord]

Мне думается, что, cli() и sei() внутри ISR - лишнее.

[Эйлер Леонард]

Вот, вот! Существуют разные мнения на сей счет. Остановка прерывания внутри прерывания. Типа того "а вдруг бы чего не вышло не того". Ко мне давно подкрадывался этот вопрос. И, все таки я так же считаю cli() и sei() внутри ISR - лишними. К тому же где то находил убедительные разъяснения по этому поводу.
Я называю это "Копипастинг кусает за пятки".

[ARV]

cli() внутри ISR, вероятнее всего лишнее, а вот sei() может быть оправдано.

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3765069#p3765069"]а вот sei() может быть оправдано.[/uquote]А можно узнать, как тогда вы попадаете в прерывание, если они у вас были запрещены?

[ARV]

А можно узнать, как тогда вы попадаете в прерывание, если они у вас были запрещены?

любознательность - это очень похвально!
в обработчик прерывания я попадаю уже при запрещенных прерываниях, хотя до момента установки флага запроса прерывания они были разрешены

[Starichok51]

а вот sei() может быть оправдано.

такое может понадобиться, если есть необходимость, чтобы другое прерывание (более важное) могло прервать ход выполняемого прерывания.

[Эйлер Леонард]

Частный случай;

Код: Выделить всё

ISR(INT0_vect)//External Interrupt
{
   ips++;//На порт PB2 подаем импульсы  _П_П_П_П_П_
}; 
ISR(TIM0_COMPA_vect)//прерывание по совпадению
{   
MAX7219_display_number(ips);//выводим на дисплей цифры  
   ips=0;
};

С внешнего прерывания считаем (инкрементируем) импульсы. Далее, через определенный период тиков, установленных в таймере-компараторе, подаем их на цифровой дисплей, обнуляем инкремент. Сначала я тренировался на чипе MAX7219, но и с 74HC595 так же считаю необходимым подружиться. А в ISR(TIM0_COMPA_vect){ /* необходимо добавить немного if-ов для усреднения значений */}. Ну и какое из прерываний кого хочет перебороть? Да вроде бы всё мирно должно быть.

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3765088#p3765088"]в обработчик прерывания я попадаю уже при запрещенных прерываниях, хотя до момента установки флага запроса прерывания они были разрешены[/uquote]Уже начал забывать это как страшный сон

[Эйлер Леонард]

-->приоритет прерываний AVR. Пока для меня этот вопрос не столь актуален. Если что, подкуюсь теорией и Гугли.

[WiseLord]

Внутри ISR() прерывания запрещены и так, так что cli() не нужен. Равно как и sei() в конце - после выхода из обработчика прерывания и без этого включатся.

А вот если нужно неблокирующее прерывание (так, чтобы другие были разрешены), есть ISR_NOBLOCK:

Код: Выделить всё

ISR(TIM0_COMPA_vect, ISR_NOBLOCK)

avr-libc обо всём позаботится.

[Эйлер Леонард]

Есть такое дело.

ISR_NOBLOCK.png

ISR_NOBLOCK в interrupt.h

(15.02 КБ) 227 скачиваний

[ARV]

ISR_NOBLOCK не совсем то же самое, что и sei() внутри обработчика. все дело в моменте разрешения прерываний: макрос делает это сразу после входа, а самодобавленный sei() - когда надо программисту.

[Мурик]

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

[ARV]

Нормальный МК должен иметь контроллер прерываний поддерживающий вложенные прерывания и иметь возможность назначать приоритет вложенности

например, любой из семейства MCS51, включая древность типа КР1816ВЕ31

функционально разрешение прерываний внутри прерывания решает все ничуть не хуже, чем аппаратный контроллер, разве что на нескоько тактов дольше это длится.

[Мурик]

например, любой из семейства MCS51, включая древность типа КР1816ВЕ31

С ними не работал. Даташит или другую документацию где есть описание контроллера прерываний по быстрому найти не удалось. Так что не могу не подтвердить и не опровергнуть.
Я не конкретизировал модель МК. У многих имеется подобный контроллер прерываний. Он точно есть в МК с ядром ARM (контроллер встроен в ядро).
У PIC (10, 12, 16) и AVR (тини, меги) вложенные прерывания не поддерживаются.

функционально разрешение прерываний внутри прерывания решает все ничуть не хуже

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

[ARV]

Даташит или другую документацию где есть описание контроллера прерываний по быстрому найти не удалось

это потому что очень древние МК

только в древних МК

2 уровня приоритетов, независимые маски.

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

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

[Мурик]

Предположим имеются 8 источников прерываний (в реальном проекте их может быть гораздо больше).

• 1 - внешнее прерывание, по которому нужно все отключить. Задержка недопустима, иначе электроника потеряет "белый дымок" и это в лучшем случае.
• 2 - внешнее прерывание которое нужно обработать с минимальной задержкой.
• 3 - прерывание от USART. Задержка не должна превышать времени поступления нового байта.
• 4 - прерывание от USB. Некоторая задержка допустима, но она приведет к снижению скрости обмена.
• 5 - прерывание от DMA. Некоторая задержка допустима.
• 6 - внешнее прерывание. Допустима задержка 1 мс.
• 7 - прерывание от таймера. Задержка допустима.
• 8 - прерывание от встроенного RTC. Допустима задержка до 1 секунды.

В случае если приоритеты вложенных прерываний аппаратно поддерживаются, все просто. Назначаем приоритеты 0, 1, 2 3, 4, 5, 6 и 7 соответственно и остальное забота контроллера прерываний. Более высокоприоритетное прерывание в любой момент может прервать прерывание с меньшим приоритетом, но не наоборот.
Если же нет поддержки вложенных приоритетов прерываний и разрешать другие прерывания при входе в прерывание, может произойти более низкоприоритетное, которое не должно обрабатываться пока выполняется код высокроприоритетного. Контроль придется осуществлять программно, из-за чего усложнится код, увеличится время перехода в высокопроиоритетное прерывание и если произойдет низкоприоритетное, нужно будет думать как вернутся назад в вывокоприоритетное, а после его обработки перейти в низкоприоритетное. Когда таких прерываний десяток другой, разрулить будет не просто.

[Starichok51]

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

[Мурик]

А если больше одного приоритета? Выше пример с 8 уровнями приоритетов и это не придел. Может быть больше.

[ARV]

"Может быть" не равно "обязательно потребуется". Изобилие хорошо, но не самоцель. Случаи, когда это изобилие действительно необходимо, пожалуй, единичны, а когда оно вообще не востребовано, имхо, подавляющи.
Все это неоднократно было сказано во множестве тем: 80% потребителей необходимы только 20% предлагаемых продавцом возможностей.