Конфликт прерываний таймера и АЦП

[ask_e]

Есть генератор прямоугольных импульсов частотой 30 кГц, реализованный на таймере с прерываниями. Импульсы должны генерироваться НЕПРЕРЫВНО ВСЕ ВРЕМЯ, с неизменной частотой.

Также есть АЦП, анализирующий сигнал на пине. Результат АЦП преобразования (104 мкс) считывается и обрабатывается в прерывании АЦП. Затем АЦП снова запускается и делается новое преобразование и т.д.

Проблема:

В VMLAB видно (да и так понятно), что прерывания АЦП изменяют длительность импульсов генератора. Прерывания АЦП конфликтуют с прерываниями таймера.

Что можно сделать, чтобы и генератор работал и АЦП (чтобы и овцы были сыты и волки целы).

Может можно реализовать генератор прямоугольных импульсов по-другому в МК (главное, чтобы именно в МК)?

[_guardianangel]

Ну для начала код в студию. И по пробуйте в прерывании АЦП только считывать результат, а обрабатывать в основном цикле.

[picavr]

обрабатывать в основном цикле.

Нафиг нужно основной цикл если всё моно сделать в прерываниях...

Проблема:

В чём проблема?
в прерываниях АЦП разрешите прерыывания таймера...
ИЛИ
опрашивайте АЦП в прерывании того же таймера.
в начале обработки формируете собственно имульсы а потом АЦП.
время преобразования=104 мкс(что то долго как то)
30 кгц это 33 мксек. 33*4=132 мксек.
Счётчик оргнизовать на 4. За 3 прерывания таймера АЦП будет преобразовывать.
а на 4 раз прочитать... и снова запустить АЦП и загрузить счётчик на 4.

[kison]

Проще всего сделать обработку АЦП в том же самом прерывании от таймера, что и для генерации сигнала используется. Выполнили действия нужные для генерации - проверяйте флаг готовности АЦП. Не готово - выход, готово - обработка обычным порядком и запуск повторного измерения.

[st_1]

Есть генератор прямоугольных импульсов частотой 30 кГц, реализованный на таймере с прерываниями. Импульсы должны генерироваться НЕПРЕРЫВНО ВСЕ ВРЕМЯ, с неизменной частотой.

А почему не задействовать для генерации импульсов хардварный ШИМ ?

[ask_e]

Благодарю всех за советы.

Счётчик оргнизовать на 4. За 3 прерывания таймера АЦП будет преобразовывать.
а на 4 раз прочитать... и снова запустить АЦП и загрузить счётчик на 4.

Попробую. Но у меня еще данные АЦП должны анализироваться. Если получится так, что времени не хватит за одно прерывание таймера это сделать? В этом случае наверное нужно будет делать как _guardianangel написал, обрабатывать в основном цикле.

А почему не задействовать для генерации импульсов хардварный ШИМ ?

Не знаю, не пробовал. Что на него прерывания не действуют?

[st_1]

Если не менять параметры ШИМ на лету, то на него ничего не действует.

[MasterMushi]

Не забывайте что само прерывание очень сильно отбирает процессорное время. Вход и выход кушает драгоценные циклы которых может и не хватить на переход из прерывание в прерывание. Мне как-то подсказали что это порядка 20-40 циклов. Очень помогло вообще отказаться от работы с таймеров при декодинге быстрых сигналов.

Обработку сигналов в прерываниях вообще нельзя делать. Используй прерывания с 1-3 операциями.

Например прерывание Ацп:
Присвоить значение преобразования в переменную и поднять флаг наличия результата. Снять флаг АЦП занят

А в прерывании по таймеру:
Если есть поднятый флаг наличия результата и снят флаг занятости АЦП то остановить таймер, обработать данные, запустить таймер. Иначе, начать преобразование, поднять флаг АЦП занят.

Тоесть, данные будут получаться ТОЛЬКО когда нет входящих необработанных значений.
Соответственно в функции обработки данных нужно предусмотреть предохранительный выход.

Если работа устройства позволяет пропускать такты

[SasaVitebsk]

Не забывайте что само прерывание очень сильно отбирает процессорное время. Вход и выход кушает драгоценные циклы которых может и не хватить на переход из прерывание в прерывание. Мне как-то подсказали что это порядка 20-40 циклов. Очень помогло вообще отказаться от работы с таймеров при декодинге быстрых сигналов.

На самом деле вход в прерывание 3 такта + ‹4 на завершение прерываемой команды + 1 для сохранения SREG + 1 на разрешение вложенного. Итого 9 при обработке вложенного прерывания на ASM. На Си будет чуть больше, но при грамотном написании тоже иногда используется.

Обработку сигналов в прерываниях вообще нельзя делать. Используй прерывания с 1-3 операциями.

Зачем же так категорично. В программировании можно всё. Просто надо чётко знать что именно ты делаешь. Например делаем выборку с частотой 8 кгц и фильтруем сигнал в прерывании. И что плохого? Если я успеваю - то ничего.

Например прерывание Ацп:
Присвоить значение преобразования в переменную и поднять флаг наличия результата. Снять флаг АЦП занят

А в прерывании по таймеру:
Если есть поднятый флаг наличия результата и снят флаг занятости АЦП то остановить таймер, обработать данные, запустить таймер. Иначе, начать преобразование, поднять флаг АЦП занят.

Тоесть, данные будут получаться ТОЛЬКО когда нет входящих необработанных значений.
Соответственно в функции обработки данных нужно предусмотреть предохранительный выход.

Если работа устройства позволяет пропускать такты

Я ни разу не использовал прерывания от АЦП. И абсолютно согласен с теми, кто предлагает обрабатывать АЦП в прерывании от таймера. Причём я готовность бы вообще не проверял. Я бы считывал гарантированный результат. Это имеет дополнительный смысл - чтение АЦП должно быть регулярным.

[nml]

На самом деле вход в прерывание 3 такта + ‹4 на завершение прерываемой команды + 1 для сохранения SREG + 1 на разрешение вложенного. Итого 9

Ну, поскольку тут - судя по всему - речь идет об АВРках, то немного не соглашусь. Во первых, вход в прерывание не 3, а 4 такта. И плюс еще два на JMP из векторов на сам обработчик.

Сохранение одного только SREG да еще за один такт - то есть в РОН - возможно только в совсем уж простенькой программе, в общем же случае - как минимум - push R16 ; in R16, sreg ; push R16. а это уже пять тактов. Да и про восстановление забывать не надо - еще пять. Как раз 20 и будет. Другой вопрос, что при 16-ти тактовой это чуть более микросекунды