Обработка нескольких прерываний AVR (вопрос)

[ra9mig]

Без включения Usart работает вроде нормально, но как только включаешь, программа сбивается, а в некоторых случаях всё просто останавливается.

По порядку:
- "time" и "err" находятся по одному и тому же адресу 0х0140 ($140) в SRAM;
- в прерываниях не сохраняете рабочие регистры и SREG (там где проверки - обязательно!), после выхода из обработчика дальнейшая реакция непредсказуемая;
- "ADC_Complete" и "wait" думается вообще можно убрать - контролируй сброс ADSC;
- и вообще зачем прерывания, у вас агоритм линейный (исключая UART).
Ну вот помелочи.
Обработчик по UART ("u") в алгоритме ни где не вызывается. Где должен быть вызов или переход?
Вот ADC без прерывания...

-- Прилагается рисунок: --

[nml]

1) при входе в прерывание надо сохранить SREG и используемые регистры (TMP).
2) при выходе - восстанавливать сохраненное
3) изменение указателя стека в обработчике - грубая ощибка. Стек устанавливается один раз при инициализации, и трогать его не надо.

[festoon]

Да, вот по поводу ADC без прерывания идея неплохая, надо попробовать. Всё же без прерывания будет очень частая проверка на замыкание датчиков, а там стоят оптические, могут быть ложные частые срабатывания, а таймер ограничивает период проверок временем 0.3 сек. u это просто описание, там и без u включение усарта сбивает работу.
А что за TMP такой?
Почему указатель стека трогать нельзя? Ведь, если датчики не сработали выход из прерывания происходит по reti, а если сработали, то выполнение программы происходит "как бы" заново и стек загружается снова.

[ra9mig]

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

Так у Вас ничего не делается пока датчики не проверились. Ну поставь задержку как в остальных случаях.

А что за TMP такой?

Это, я так понимаю, условное название любых регистров Tempx (x - n-ное кол-во), которые используются только в прерывании. Но можно и просто рабочие регистры сохранять в стеке, а по окончании обработчика востанавливать из стека (push и pop).

Почему указатель стека трогать нельзя?

Можно, но обычно так ни кто не делает. Он нужен для сохраненния адресса при вызове процедуры, сохранения данных и др.случаях. По этой причине, как правило, он выставляется один раз в начале программы и, как правило, на конец памяти (что бы было больше "места").
Но из всего есть исключения.
P.S. Так где же должен быть вызов обработки данных от UART.
Он жестко управляет приводами. Если "телега" делает "маневр объезда", то может и не "доехать".

[festoon]

Обработка от уарт помещалась в основной цикл, тот, который с меткой f, но так как были сбои, дальше я не развивал обработку от уарт.
Дело в том, что датчики проверяются в любой момент с интервалом 0.3 с, то есть если даже в процедуре left идёт поворот руля и отслеживание положения резистора и происходит срабатывание датчика, то программа начинает выполнение сначала, то есть центрирует руль, отъезжает надаз и тд. А если делать проверку датчиков без таймера, то проверяться они будут очень часто и без задержки. Хотя в принципе, надо попробовать, может прокатит.
От уарт хочу сделать радиоуправление, чтоб можно было прервать автоматическое управление и рулить с пульта.
То есть в обработчике прерывания надо: в начале sreg-›, r16-›, а в конце перед reti: -›r16, -›sreg ?

[ra9mig]

То есть в обработчике прерывания надо: в начале sreg-›, r16-›, а в конце перед reti: -›r16, -›sreg ?

Ну где-то так, если в обработчике используется только r16. Если еще и другие регистры, то их тоже нужно "пропустить" через стек. Важно сохранять последовательность занесения/возврата!
Можно сохранять и в рабочих регистрах (назвать их, к примеру: Tmp1, Tmp2 и т.д.) и выполнять

.def TmpSREG = r13
.def Tmp1 = r14
.def Tmp2 = r15
---------------
Any_Int:
in  TmpSREG, SREG
mov Tmp1, r16
mov Tmp2, r17
(или вообще movw Tmp1, r16)
.....
тут какие-то действия, сравнеия...
.....
out SREG, TmpSREG
mov r16, Tmp1
mov r17, Tmp2
reti

это только пример! (без стека )

С UART в целом ясно...

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

P.S. Может вообще алгоритм пересмотреть, так сказать - "проработать"...

[ra9mig]

Дело в том, что датчики проверяются в любой момент с интервалом 0.3 с, то есть если даже в процедуре left идёт поворот руля и отслеживание положения резистора и происходит срабатывание датчика, то программа начинает выполнение сначала, то есть центрирует руль, отъезжает надаз и тд.

Выходит что ее легко загнать в угол - она все время будет ехать назад. А надо что-бы вперед на "врага" - натаран. И ни какие прерывания не страшны!!!

[festoon]

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

[ra9mig]

Кстати говоря, в ваше случае можно сделать вообще все наоборот, то-есть полностью на прерываниях. Подумайте над этим.
P.S. По поводу алгоритма - на roboforume масса всяких тележек.

[festoon]

Вроде обработка АЦП по ADSC помогла, но вот какое дело: запрограммировал, проверил, вроде всё ок (усарт включён, но обработчика нет). Потом кое-что исправлял, но в итоге привёл к прежнему виду и как-то нестабильно работает, пауза иногда не выдерживается нужное время. Такое ощущение, что или в контроллере косяк или в алгоритм билдере. Возможна ли косячная компиляцияпрограммирование? Никто не замечал подобного?