Технический форум по робототехнике.
galex1981 » 23 мар 2009, 02:11
Столкнулся с проблемой в 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.
bolt » 23 мар 2009, 17:05
Извините, но сброс флага источника прерывания - обязательное условие для всех МК
galex1981 » 23 мар 2009, 17:20
Сброс флага это не на него акцентирую свое внимание (хотя и про него народ тоже забывает иногда) акцент идет на использование фунций разрешения/запрета прерываний
Vooon » 23 мар 2009, 17:37
Что-то мне подсказывает, что GetRC5() ждет начала посылки (проверяет поллингом).
А в прерывания что-либо ждать очень плохая идея. Чем прерывание меньше (по тактам) — тем лучше.
galex1981 » 23 мар 2009, 17:53
нет, она без ожидания работает, насколько я понял, либо поймала сигнал, либо нет (практически проверял). В прерывании вызывается потому, что само прерывание срабатывает по приему посылки от ИК пульта
bolt » 23 мар 2009, 20:01
В принципе, там необходимости в прерывании вообще нет. А стандартный вариант обработки такой:
прерывание,
запрет прерывания,
обработка,
сброс флага,
разрешение прерывания.
EdGull » 23 мар 2009, 21:53
почему там необходимости в прерывании вообще нет???
bolt » 24 мар 2009, 23:27
Я пару лет назад мелкочиповские примеры ИК декодеров смотрел, так там тупо отслеживают изменение по входу, без всяких прерываний. Если не надо загонять декодер в спячку или срочно выпадать из основной программы, то прерывания не нужны.
EdGull » 24 мар 2009, 23:33
тупо циклу?
bolt » 25 мар 2009, 11:12
Не, не совсем по циклу. МК висит на входе до изменения уровня. Когда пришел импульс начинается обработка, с возвратом в исходное если это не стартовый строб.
Допустим, что МК бота кроме ДУ обслуживает бамперы и измеряет батарейку. Если сигналы ДУ проверять/декодировать между процедурами, то все будет нормально. А если по любой помехе, в т.ч. и от бамперов уходить в прерывание, то

EdGull » 25 мар 2009, 11:14
а как узнать об изменениее уровня, если не прерыванием и не тупым циклом?
bolt » 25 мар 2009, 11:27
В свободное от выполнения основной программы время делаем BTFSS - bit test или что-нибудь типа
if PORTA==0 then ... else break
EdGull » 25 мар 2009, 11:30
а что мешает запрещать прерывания в основной программе?
а где гарантия что не проспишь посылку RC5 ?
bolt » 25 мар 2009, 16:28
А что дает прерывание, кроме лишних телодвижений основной программе? Посылка достаточно длинная и не однократная, проще ее обработать проверяя вход в паузах основных процедур.
Даже когда МК только декодер, прерывание ничего не дает. Можно просто висеть на входе без всяких прерываний. Разве что для усложнения себе жизни

EdGull » 25 мар 2009, 17:53
ну раз ты всё осознал, я то потру наш флуд.