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

[khach]

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

[Rst7]

Частота максимальная по одному каналу 86 кгц, по второму -24 кгц.

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

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

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

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

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

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

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

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

недооценив стоимость программной реализации функции в сравнении с аппаратной

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

[Oldring]

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

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

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

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