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

[khach]

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

[Огурцов]

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

На меге > 86кгц*2 получить не реально, если только не ставить отдельную мегу на энкодеры. Кстати, в вашем случае я бы так и сделал для минимальных переделок. Прерывание при этом должно быть _одно_ либо опрос вообще без прерываний. Как вариант - поставить иксмегу с аппаратными счетчиками квадратурных энкодеров.
Остальные варианты, как вы понимаете, потребуют гораздо больших переделок.

[_Pasha]

На меге > 86кгц*2 получить не реально,

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

Я именно про квадратуру. Итого 20 тактов на 10тибитный счетчик со всеми входами/выходами. Отнять надо пару регистров для счетчика и регистр для сохранения SREG.
Потом, конечно, надо немного поколдовать над конвертированием.

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

[Rst7]

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

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

Код

#define    SREG_SAVE R13
#define ENC_POS R14
#define STATE R15

#define PIN_ENCODERS PINC
#define BIT_A 1
#define BIT_B 4

ENC_HANDLE:
    SBRC    STATE,BIT_A
    RJMP    ENC_HANDLE_EXIT
    BST    STATE,BIT_B
    IN    STATE,PIN_ENCODERS
    SBRC    STATE,BIT_A
    RETI
    BRTS    ENC_HANDLE_DEC
    IN    SREG_SAVE,SREG
    SBRC    STATE,BIT_B
    INC    ENC_POS
    OUT    SREG,SREG_SAVE
    RETI
ENC_HANDLE_DEC:
    IN    SREG_SAVE,SREG
    SBRS    STATE,BIT_B
    DEC    ENC_POS
    OUT    SREG,SREG_SAVE
    RETI
ENC_HANDLE_EXIT:
    IN    STATE,PIN_ENCODERS
    RETI

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

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

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

[_Pasha]

Общее время ...+16(худший случай).

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

Если будет на поллинг по таймеру потрачено 50% времени - уже замечательно.

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