Обработка энкодера все же должна быть аппаратной (это уже много раз проверено). Раньше делал на рассыпухе, сейчас делаю ПЛМ типа EPM3064 (Altera). В нее у меня
влазит учетверитель (детектор направления) , 24 разрядный реверсивный счетчик с 3z буффером и выборка.С меньшим разрядом можно 2 обработчика вместить.
Стоимость EPM3064 ~60р.

Да и у микрочипа есть однокристалки с аппаратными интерфейсами квадратурных энкодеров.

Тем не менее, это все не означает, что эту задачу нельзя решить на уже разработанном железе с AVR программно. Просто программное решение такой задачи - не очень стандартная вещь. И код будет несколько извращенным и неподдерживаемым.

Нормальный код будет. Только придется написать документацию, где расписать что и сколько тактов исполняется, почему что-то сделано так а не иначе.

Что будет проще - заново все сделать, или просто переписать прогу для AVR, вопрос сложный. С одной стороны, тем кто только начал разбираться, я бы не стал советовать начинать с DSP. Но с другой стороны, если начинать с чем-то разбираться, то DSP не самый плохой.
Но у avr есть avr студио, где, насколько я помню, можно было неплохо прогнать программу, посчитав все такты.

Вот эти "просчеты всех тактов" и есть главное извращение.
Два квадратурных энкодера. 86 килогерц - это полный период, то есть частота опроса должна быть минимум в 4 раза больше? А то и в 8, если учесть точность перекрытия четвертей?
Плюс обработка UART.
Плюс рассчет контура обратной связи.
Неизвестно еще нужно ли менять параметры регулятора и писать в EEPROM.
Опять же, на фоне 400 кГц или 800 кГц опроса энкодеров.
800 кГц опрос - можно и не успеть, если не очень сильно извращаться.

Нужно смотреть на сколько тактов нужно на вхождение в прерывание итд. 68, это 235 тактов. Если поделить на два, то 117. Сложно. Но можно ужаться. Вопрос только зачем.


Это уже можно терять байты. Да и какая скорость?


Это совсем низкий приоритет.


ЕЕПРОМ, это вообще очень низкий приоритет.


Я не понял немного. с какой частотой приходят прерывания от енкодеров?

Этого я тоже до конца не понял.
Чтобы понять - нужен даташит на энкодер и максимальная скорость вращения в ТЗ.
Надеюсь, что 86 кГц - это частота четвертей. Реально должно быть выше, так как нужно учитывать точность перекрытия квадратур.

Никаких прерываний по фронтам энкодеров быть не должно. Прерывать нужно по таймеру, организовав поллинг энкодеров. Если будет на поллинг по таймеру потрачено 50% времени - уже замечательно.

Обмен по UART нужно обрабатывать по прерываниям, но в начале прерывания UART нужно запрещать его прерывания и разрешать глобальные прерывания, в конце - наоборот. Тем самым организовав приоритеты прерываний.

Со всем остальным прийдется немного извратиться. Возможно, организовав еще один уровень софтверных прерываний, запускаемых после каждого N-го прерывания поллинга энкодеров. С меньшим приоритетом, чем поллинг и обмен с UART.

Такие вещи нужно делать аппаратно и ни как иначе. Квадратурный преобразователь, накопительные реверсивные счетчики и буфера в виде регистров защелок. И все,
считываешь счетчики допустим каждые 1мсек и голова не болит , что где-то затерялся импулс или еще что-то.

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


Плюспицот!  Вот въедливое выражение подарили... Пащитаем: ввели SaveSREG и предыдущее состояние порта Port_Prev итого -6 clocks если бы второй энкодер на том же порту сидел, то накладные расходы по его декодированию практически скомпенсировались бы. И еще не забываем, что в некоторых камнях еще есть GP регистры в пространстве SFR. Можно предыдущие состояния порта хранить там






Типа спор выходит:

- главный изврат - это создать боле-мене вещь и угробить ее криво написанной софтой.

- Частоту khach дал для 4х

- UART обрабатывается (должен, имхо) в неблокирующем прерывании с кольцевым буфером

- В EEPROM шить на лету - это значит иметь активную копию содержимого, применяемого в работе. Кто отдаст столько памяти под это безобразие? Я бы на попытки записать в процессе движения просто ругался бы. Возможно, нецензурно типа BUSY - и все.

Кстати, вспомнилось. Все ж понимают, что предыдущее состояние энкодера суть два дополнительных бита разрешения в коде Грея?

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

Я именно про квадратуру. Итого 20 тактов на 10тибитный счетчик со всеми входами/выходами. Отнять надо пару регистров для счетчика и регистр для сохранения SREG.

Атомарное считывание положения осуществляется командой MOVW. Потом, конечно, надо немного поколдовать над конвертированием. Но это уже O(1).

10 бит это 1024 такта.


Боюсь, я не понял вашу мысль. Сколько бит, столько и должно быть регистров. Как минимум.


На внешнюю шину лепить, оно, конечно быстро будет. Но а она в ней есть? И лап на это хватит?

ИМХО, чем лепить CPLD, лучше тот DSP от Ti поставить. Там все уже есть, с примерами, итд.

Я про програмную реализацию на AVR.

На меге > 86кгц*2 получить не реально, если только не ставить отдельную мегу на энкодеры. Кстати, в вашем случае я бы так и сделал для минимальных переделок. Прерывание при этом должно быть _одно_ либо опрос вообще без прерываний. Как вариант - поставить иксмегу с аппаратными счетчиками квадратурных энкодеров.
Остальные варианты, как вы понимаете, потребуют гораздо больших переделок.

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