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

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

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

Обработка энкодера все же должна быть аппаратной (это уже много раз проверено). Раньше делал на рассыпухе, сейчас делаю ПЛМ типа 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 получить не реально, если только не ставить отдельную мегу на энкодеры. Кстати, в вашем случае я бы так и сделал для минимальных переделок. Прерывание при этом должно быть _одно_ либо опрос вообще без прерываний. Как вариант - поставить иксмегу с аппаратными счетчиками квадратурных энкодеров.
Остальные варианты, как вы понимаете, потребуют гораздо больших переделок.

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

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

Извините, но это аццкий отжых. Иначе, отчего у меня Энкодер(правда, 1) + STEP разгоняются до 100кГц пока без напрягов для основной задачи? Приведенным выше макаком, ессно. На 18.432 МГц


Огласите весь список, пжалста! Не пойму, как мы без ловли фронтов отловим событие, по которому изменится регистр положения

С одним энкодером проблем на атмеге нет. Обрабатываем его по INT0 (самый высокий приоритет) и все. А вот когда 2 энкодера выдают килогерцы... рука тянется за бубном.

ЗЫ: вот кстати - история про то, что надо фронты обрабатывать:




Дык зря. Надо скан, уже ведь говорили где-то в темах по AVR

Мне кажется дело вкуса. У меня по INT0 замечательно работает.

Про фронты +1. Этими граблями сам получил.

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


Пардон, прошлый раз считал в уме, немного ошибся. Общее время 4(вход в прерывание)+2(RJMP с вектора)+16(худший случай)=22 такта.

Соответственно, ENC_POS - старшие 8 бит положения, STATE.A и STATE.B - младшие 2 бита положения в коде Грея. Оба регистра атомарно эксгумируются при помощи MOVW (поэтому и лежат рядом).

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

Похоже, что лучше будет некуда. Именно благодаря наличию худших/лучших случаев проц особо не надуется.





Скока-скока?

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

Дык это на всю схему распространяется, помехо(не)устойчивость может натворить и при идеальном энкодере. И при поллинге у нас автоматом неплохой антидребезг получается, и во вторых имеется детерминированное время обработки любого количества энкодеров. 

Да не в том дело. Если энкодер вменяем и не может залить сигнал флудом, то прилет такой помехи, которая клином поставит проц, надо рассматривать как аварийный режим. Работать такая помеха явно не даст - уже неизвестно, сколько левых импульсов насчитано/пропущено. Конечно, при такой аварии надо предусмотреть такую последовательность действий, которая безопасно остановит процесс.

Просто опрос по pin-change сам балансирует нагрузку на проц. И не отнимает мипсы при отсутствии перемещения.

Как промежуточный вариант можно сделать так - простробировать на D-триггерах сигналы энкодера, a в качестве строба подать сигнал от таймера с максимально возможной для обработки частотой. Обработчик оставить на pin-change. Можно, например, взять 74HC74, если сигналов всего два.

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

Сэр, у Вас КОСЯГ:


Природа отобрала 1 такт Плакать не будем.

Народ, в который раз меня вдохновила подобная беседа!!!
И вот я тоже прихожу к выводу, что поллить энкодеры несколько лучше в плане устойчивого считывания информации. Особенно, если энкодеры не промышленные, а самопал - типа из мышки...( Как это не печально, но бюджет не позволяет купить что-нить готовое. Даже импульсов 200 на оборот... Ничего дешевле 1500 р не находил, а нужно три энкодера. В универе денег нет((( Но что еще печальнее, энкодер из мышки не дает по двум каналам двига на pi/2 между фазами. Далее, не удается получить скважность сигнала на каждом канале равную 2... Если на одном получается, то на другом уже перекос... Понятно, что это уже не совсем квадратурный энкодер..., а что-то другое. И аппаратный декодер загибается на этом деле. Тут, похоже нужно программно... верно ли я мыслю?

Согласен.



Не согласен.


Худший случай не изменился. Немного ухудшилась одна ветка.



Согласен.

Там и программный загнется А что это будет по частоте?

Не, нормальный отжыг. 16000000 / (80000*2) = 100 тактов. Коротка кольчужка. Даже для одного энкодера получится не прога, а аццкие танцы с бубном. Т.е. только для обработки энкодера прокатит, но если потребуется что-то еще, то нуегона.

Да, Вы правы.. не подумал... Будем, значит, доводить до ума мышинные датчики.

Не более 4 КГц.

Дык Вы в процентах загрузки проца считайте - уже не так страшно. Это раз. Во-вторых, кварц на 16 ставить оцень-не-хоцца, лучше 18,432. Чуть больше тактов все ж.

В третьих - а кто будет еще что-то лепить туда? Разве что конкурентам насоветовать так тоже ж не дураки, знают где пределы у авров.





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

Это какой декодер загибается? Вот декодер учетверитель. Все время делал по этой схеме и никогда не загибался(имеется ввиду декодер). Там синхронизация, частота, чем выше тем большую входную частоту можно обработать все зависит от быстродействия
логики. Выхода подаешь на реверсивный счетчик типа ИЕ7 и т.п.. Такие устройства нужно делать засинхронизированными, а не
по фронтам.

Процентов триста..пятьсот.


Так "для сервопривода" - ПИДы какие-нибудь потребуются, ШИМом крутить, УАРТ, концевики, разная другая хрень.

Впрочем, приведите ваш вариант - что на входе, что на выходе, сколько тактов, на чем написан...