roboforum.ru

Столкнулся с проблемой в Bascom при программировании ИК пульта с использованием протокола RC5. В основном цикле МК проблем не возникает. При использовании функции Getrc5 в прерывании (в моем случае Int1) на вызове этой функции все висло. Поискав в некоторых источниках, я нашел выход из этой проблемы. Ниже привожу листинг использования этой функции в обработчике прерывания:

Код: Выделить всё • Развернуть

Learn_rc5:
   Disable Int1
   Enable Interrupts
   Getrc5(rc5byte1 , Rc5byte2)
   Enable Interrupts
   If Rc5byte1 <> 255 And Rc5byte2 <> 255 Then
      Rc5byte2 = Rc5byte2 And &B01111111
      Print Chr(12);
      Print "Address - " ; Rc5byte1
      Print "Command - " ; Rc5byte2
   End If
  Gifr = Gifr Or &B10000000                                 'Clear Flag Int1
  Enable Int1
Return

Обратите внимание на значение регистра GIFR. В этом листинге значение для МК ATMega32.

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

Сброс флага это не на него акцентирую свое внимание (хотя и про него народ тоже забывает иногда) акцент идет на использование фунций разрешения/запрета прерываний

Что-то мне подсказывает, что GetRC5() ждет начала посылки (проверяет поллингом).
А в прерывания что-либо ждать очень плохая идея. Чем прерывание меньше (по тактам) — тем лучше.

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

В принципе, там необходимости в прерывании вообще нет. А стандартный вариант обработки такой:
прерывание,
запрет прерывания,
обработка,
сброс флага,
разрешение прерывания.

почему там необходимости в прерывании вообще нет???

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

тупо циклу?

Не, не совсем по циклу. МК висит на входе до изменения уровня. Когда пришел импульс начинается обработка, с возвратом в исходное если это не стартовый строб.
Допустим, что МК бота кроме ДУ обслуживает бамперы и измеряет батарейку. Если сигналы ДУ проверять/декодировать между процедурами, то все будет нормально. А если по любой помехе, в т.ч. и от бамперов уходить в прерывание, то

а как узнать об изменениее уровня, если не прерыванием и не тупым циклом?

В свободное от выполнения основной программы время делаем BTFSS - bit test или что-нибудь типа
if PORTA==0 then ... else break

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

А что дает прерывание, кроме лишних телодвижений основной программе? Посылка достаточно длинная и не однократная, проще ее обработать проверяя вход в паузах основных процедур.
Даже когда МК только декодер, прерывание ничего не дает. Можно просто висеть на входе без всяких прерываний. Разве что для усложнения себе жизни

ну раз ты всё осознал, я то потру наш флуд.