Микроконтроллер для сервопривода подскажите, Два аппаратных енкодера нужно. Опции

[khach]

Добрый день.
Прошу помощи у опытных в конструировании привода коллег. Уперлись в грабли при отладке сервопривода на базе Атмеги. По ТЗ требовалось обрабатывать сигналы с двух квадратурных энкодеров, один был ведущий, второй - датчик в петле ОС по положению и скорости. Сделали серву на базе атмеги, энкодеры обрабатывали по прерываниям. Но оказалось что за время в несколько часов в сервоприводе набегают ошибки позиционирования, происходят потери прерываний или совпадения фронтов от двух енкодеров. Лазить по граблям и вылизывать кривую программу надоело. Решили менять процессор на аппаратно заточенный под обработку енкодеров.
Прошу совета по выбору типа микроконтроллера с аппаратными счетчиками енкодеров (два канала как минимум). Пока вроде понравился STM32. Но терзают смутные сомнения по поводу помехоустойчивости ядра- слишком уж оно низковольтное. А нам надо контролировать ток в приводе с помощью АЦП контроллера, поэтому полная гальваническая развязка нежелательна.

[_Sam_]

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

Насколько я представляю у вас обычные инкрементные датчики, т.е. у каждого по три вывода A,B,REF. Для двух датчиков получается 6 линий. Самый простой и дешёвый интерфейс для абсолютных датчиков - SSI, на два датчика это 3 линии. 1 параллельный клок и две линии данных.

По поводу скорости опроса. Допустим датчик под 30 разрядов(многооборотный, что вряд ли) можете сами посчитать сколько займёт опрос при частоте клока скажем 1мгц.

По цене. Если говорить о магнитных, то отличаются они не сильно, если вообще отличаются, оптические возможно подороже может процентов на 20, 30, хотя может у меня инфа устаревшая. Многооборотные будут действительно подороже.

Я думаю, до необходимости менять железо там еще как до Луны. Рефакторинг кода в сторону повышения перфоманса - сюда копать надо.

Может и так, а может и нет. Обычно квадратурные датчики по rs422 работают и если это действительно помеха, то исправления кода не помогут.

А контроллеры от TI действительно вещь, но если у вас штучное изделие, то заморачиваться думаю смысла нет, проще действительно CPLD поставить.

[Iptash]

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

[Oldring]

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

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

[Methane]

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

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

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

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

[Oldring]

Но у avr есть avr студио, где, насколько я помню, можно было неплохо прогнать программу, посчитав все такты.

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

[Methane]

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

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

Плюс обработка UART.

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

Плюс рассчет контура обратной связи.

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

Неизвестно еще нужно ли менять параметры регулятора и писать в EEPROM.

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

Опять же, на фоне 400 кГц или 800 кГц опроса энкодеров.
800 кГц опрос - можно и не успеть, если не очень сильно извращаться.

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

[Oldring]

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

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

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

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

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