[khach 33]

Добрый день.

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

Прошу совета по выбору типа микроконтроллера с аппаратными счетчиками енкодеров (два канала как минимум). Пока вроде понравился STM32. Но терзают смутные сомнения по поводу помехоустойчивости ядра- слишком уж оно низковольтное. А нам надо контролировать ток в приводе с помощью АЦП контроллера, поэтому полная гальваническая развязка нежелательна.

[Rst7 5]

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

[Methane 0]

Прошу совета по выбору типа микроконтроллера с аппаратными счетчиками енкодеров (два канала как минимум).

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

[_Pasha 0]

происходят потери прерываний или совпадения фронтов от двух енкодеров.

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

 

; PORTB bits
#define  QEA 4
#define QEB 5
ISR_QENC_SCAN:
    in ZL,SREG_SFR
    push ZL
    movw SAVEZ,ZL
    in ZL,PINB
    lds ZH,PREV_B
    sts PREV_B,ZL
    eor ZH,ZL
    and ZH,ZL
    bst ZL,QEA
    ror ZL
    bld ZL,QEB
    and ZL,ZH
    sbrc ZL,QEA
    inc pos_REG
    sbrc ZH,QEB
    dec pos_REG
    movw ZL,SAVEZ
    pop ZL
    out SREG_SFR,ZL
            reti

30 тактов, если я не ошибся, жрет регистровую пару SAVEZ и регистровый кэш для позиции.

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

[khach 33]

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

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

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

Вы советутете разделить прерывания для двух енкодеров. Мы так делали, но при совпадении прерываний от двух енкодеров пока обрабатывалось первое, во втором уже изменялось состояние входов. А такие события происходили достаточно часто (несколько раз в минуту).

Может быть найдуться примеры по реализации обработки двух енкодеров в одном прерывании? Может у нас "глаз замылился" при оптимизации кода и мы чегото-неучитываем. События потери позиции очень редкие, но для нас критичны.

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

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

[Methane 0]

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

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

[Oldring 0]

А что тогда делать?

 

Запрограммировать качественно с нуля.

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

Если вам не удалось написать программу для AVR - наверняка не получится и для TMS.

 

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

[Rst7 5]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[Oldring 0]

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

 

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

 

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

 

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

[Rst7 5]

Я думаю, что железо изначально выбрано не очень правильно.

 

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

 

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

 

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

[Oldring 0]

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

 

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

 

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

 

Из стандартных глюков - асинхронно работающие счетчики и шина их чтения процессором. Для примера.

Так что если уж переделывать железо - то, действительно, переходить на TMS320F28xx. Правда, инструментарий не из дешевых.

[PhX 0]

Так что если уж переделывать железо - то, действительно, переходить на TMS320F28xx. Правда, инструментарий не из дешевых.

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

Да, хорошие средства разработки относительно дороги, но существуют и дешевые "отладчики" от Olimex.

 

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

[Tanya 4]

По ТЗ требовалось обрабатывать сигналы с двух квадратурных энкодеров, один был ведущий, второй - датчик в петле ОС по положению и скорости.

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

[_Sam_ 0]

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

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

 

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

 

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

 

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

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

 

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

[Rst7 5]

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

 

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

 

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