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

А Вы уверены, что аппаратный обработчик Вас спасет?

TMS320F28 посмотрите. Думаю что найдете много интересного.

Кусок асма для обработки энкодера. Скан по времени


30 тактов, если я не ошибся, жрет регистровую пару SAVEZ и регистровый кэш для позиции.
При совпадении фронтов, т.е. когда у Вас все заведено на один pin-change вектор - это возможно, но если разделить и сделать самые быстрые прерывания - проблемы от контроллера не будет. Какая там частота в 4-х режиме?

Спасибо, может удасться оживить и старое изделие. Частота максимальная по одному каналу 86 кгц, по второму -24 кгц. Кроме этого в системе крутиться ПИД управление мостом сервы, контроль параметров сервы (токи, напряжения, температура), коммуникация с компьютером (лог), индикация и опрос органов управления.
Вы советутете разделить прерывания для двух енкодеров. Мы так делали, но при совпадении прерываний от двух енкодеров пока обрабатывалось первое, во втором уже изменялось состояние входов. А такие события происходили достаточно часто (несколько раз в минуту).
Может быть найдуться примеры по реализации обработки двух енкодеров в одном прерывании? Может у нас "глаз замылился" при оптимизации кода и мы чегото-неучитываем. События потери позиции очень редкие, но для нас критичны.

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

На CPLD можно сделать. Про цену, не знаю.

Запрограммировать качественно с нуля.
Вопрос про "аппаратный энкодер спасет", очевидно, был с подвохом.
Если вам не удалось написать программу для AVR - наверняка не получится и для TMS.

PS Очевидно, Вы здесь наступили на стандартные грабли, недооценив стоимость программной реализации функции в сравнении с аппаратной и переоценив свои возможности в программировании.

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

Второе - действительно, на всю обработку надо тактов 30. Например, вариант Павла можно еще сократить, отняв у IAR'а немного регистров. Так что при тактовой частоте проца в 16МГц запасу еще огого.

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

Четвертое - а точно не влетает какая гадость на входа, ну от помех например? Хотя, конечно, помеха по одной линии не приведет к ошибке (ну скакнет на единицу в плюс, потом в минус), а вот по двум - запросто.

Пятое - крайний случай - CPLD самая мелкая стоит $1-1.5. В 32 макроячейки два (а то и больше) декодеров лягут аж бегом.

PS Выкладывайте свой код обработчиков энкодеров, посмотрим.



Если Вы про мой вопрос, то никакого подвоха. Я больше про помеховую обстановку.



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

Я думаю, что железо изначально выбрано не очень правильно. Тот же TMS как раз под приводные задачи заточен. Люди просто решили что решить все программно на универсальной однокристалке будет просто.

Тем не менее, судя по тому, что глюки относительно редкие, дело не в нехватке производительсности, а в неправильно написанной программе.

PS В CPLD все конечно ляжет, но с потенциально новыми глюками.

Мы-то всех подробностей не знаем. Может там каждый цент надо выжать.



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

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



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

Господа, действительно, под привод есть специально заточенные ДСК от TI, которые обладают значительно большей вычислительной мощностью и специализированными аппаратными ресурсами в сравнении с атмегами и пр. Атмеги замечательные микроконтроллеры, которые позволяют быстро решать несложные задачи, но на сегодняшний день теряется смысл использовать их в задачах связанных с электроприводом. Спектр предложений TI позволяет выбрать проц на порядок быстрей, который стоит только вдвое дороже. Разумеется, если планируется выпускать изделие партиями от 10000 шт цена проца играет первую скрипку. Однако при небольших партиях издержки на разработку как правило перевешивают.
Да, хорошие средства разработки относительно дороги, но существуют и дешевые "отладчики" от Olimex.

Кроме того, у TI есть очень хорошая штука free samples.

А может, подумать в сторону устройства, которое будет выдавать только рассогласование энкодеров. Тогда вообще никаких прерываний не нужно, кажется мне... Если я правильно условие понимаю..., что один задатчик, а второй крутится по Вашей воле.

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

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

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


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

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

В таком случае и аппаратный узел не спасет.

Вообщем, рефакторинг - это наше все