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

[khach]

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

[Rst7]

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

[Methane]

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

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

[_Pasha]

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

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

Код

; 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]

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

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

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

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

[Methane]

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

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

[Oldring]

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

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

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

[Rst7]

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

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

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

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

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

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

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

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

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

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

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

[Oldring]

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

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

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

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

[Rst7]

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

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

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

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

[Oldring]

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

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

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

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

[PhX]

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

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

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

[Tanya]

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

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

[_Sam_]

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

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

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

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

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

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

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

[Rst7]

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

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

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

[Iptash]

Обработка энкодера все же должна быть аппаратной (это уже много раз проверено). Раньше делал на рассыпухе, сейчас делаю ПЛМ типа EPM3064 (Altera). В нее у меня
влазит учетверитель (детектор направления) , 24 разрядный реверсивный счетчик с 3z буффером и выборка.С меньшим разрядом можно 2 обработчика вместить.
Стоимость EPM3064 ~60р.

[Oldring]

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

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

[Methane]

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

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

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

Что будет проще - заново все сделать, или просто переписать прогу для AVR, вопрос сложный. С одной стороны, тем кто только начал разбираться, я бы не стал советовать начинать с DSP. Но с другой стороны, если начинать с чем-то разбираться, то DSP не самый плохой.
Но у avr есть avr студио, где, насколько я помню, можно было неплохо прогнать программу, посчитав все такты.

[Oldring]

Но у avr есть avr студио, где, насколько я помню, можно было неплохо прогнать программу, посчитав все такты.

Вот эти "просчеты всех тактов" и есть главное извращение.
Два квадратурных энкодера. 86 килогерц - это полный период, то есть частота опроса должна быть минимум в 4 раза больше? А то и в 8, если учесть точность перекрытия четвертей?
Плюс обработка UART.
Плюс рассчет контура обратной связи.
Неизвестно еще нужно ли менять параметры регулятора и писать в EEPROM.
Опять же, на фоне 400 кГц или 800 кГц опроса энкодеров.
800 кГц опрос - можно и не успеть, если не очень сильно извращаться.

[Methane]

Вот эти "просчеты всех тактов" и есть главное извращение.
Два квадратурных энкодера. 86 килогерц - это полный период, то есть частота опроса должна быть минимум в 4 раза больше? А то и в 8, если учесть точность перекрытия четвертей?

Нужно смотреть на сколько тактов нужно на вхождение в прерывание итд. 68, это 235 тактов. Если поделить на два, то 117. Сложно. Но можно ужаться. Вопрос только зачем.

Плюс обработка UART.

Это уже можно терять байты. Да и какая скорость?

Плюс рассчет контура обратной связи.

Это совсем низкий приоритет.

Неизвестно еще нужно ли менять параметры регулятора и писать в EEPROM.

ЕЕПРОМ, это вообще очень низкий приоритет.

Опять же, на фоне 400 кГц или 800 кГц опроса энкодеров.
800 кГц опрос - можно и не успеть, если не очень сильно извращаться.

Я не понял немного. с какой частотой приходят прерывания от енкодеров?

[Oldring]

Я не понял немного. с какой частотой приходят прерывания от енкодеров?

Этого я тоже до конца не понял.
Чтобы понять - нужен даташит на энкодер и максимальная скорость вращения в ТЗ.
Надеюсь, что 86 кГц - это частота четвертей. Реально должно быть выше, так как нужно учитывать точность перекрытия квадратур.

Никаких прерываний по фронтам энкодеров быть не должно. Прерывать нужно по таймеру, организовав поллинг энкодеров. Если будет на поллинг по таймеру потрачено 50% времени - уже замечательно.

Обмен по UART нужно обрабатывать по прерываниям, но в начале прерывания UART нужно запрещать его прерывания и разрешать глобальные прерывания, в конце - наоборот. Тем самым организовав приоритеты прерываний.

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

[Iptash]

Такие вещи нужно делать аппаратно и ни как иначе. Квадратурный преобразователь, накопительные реверсивные счетчики и буфера в виде регистров защелок. И все,
считываешь счетчики допустим каждые 1мсек и голова не болит , что где-то затерялся импулс или еще что-то.

[_Pasha]

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

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

Например, вариант Павла можно еще сократить, отняв у IAR'а немного регистров.

Плюспицот!  Вот въедливое выражение подарили... Пащитаем: ввели SaveSREG и предыдущее состояние порта Port_Prev итого -6 clocks если бы второй энкодер на том же порту сидел, то накладные расходы по его декодированию практически скомпенсировались бы. И еще не забываем, что в некоторых камнях еще есть GP регистры в пространстве SFR. Можно предыдущие состояния порта хранить там

Вот эти "просчеты всех тактов" и есть главное извращение.


частота опроса должна быть минимум в 4 раза больше?

Плюс обработка UART.


Неизвестно еще нужно ли менять параметры регулятора и писать в EEPROM.

Типа спор выходит:

- главный изврат - это создать боле-мене вещь и угробить ее криво написанной софтой.

- Частоту khach дал для 4х

- UART обрабатывается (должен, имхо) в неблокирующем прерывании с кольцевым буфером

- В EEPROM шить на лету - это значит иметь активную копию содержимого, применяемого в работе. Кто отдаст столько памяти под это безобразие? Я бы на попытки записать в процессе движения просто ругался бы. Возможно, нецензурно типа BUSY - и все.

[Rst7]

Кстати, вспомнилось. Все ж понимают, что предыдущее состояние энкодера суть два дополнительных бита разрешения в коде Грея?

[Methane]

Кстати, вспомнилось. Все ж понимают, что предыдущее состояние энкодера суть два дополнительных бита разрешения в коде Грея?

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

[Rst7]

Насколько я знаю, стандарт это просто квадратурный модулятор.

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

Атомарное считывание положения осуществляется командой MOVW. Потом, конечно, надо немного поколдовать над конвертированием. Но это уже O(1).

[Methane]

Я именно про квадратуру. Итого 20 тактов на 10тибитный счетчик со всеми входами/выходами.

10 бит это 1024 такта.

Отнять надо пару регистров для счетчика и регистр для сохранения SREG.

Боюсь, я не понял вашу мысль. Сколько бит, столько и должно быть регистров. Как минимум.

Атомарное считывание положения осуществляется командой MOVW. Потом, конечно, надо немного поколдовать над конвертированием. Но это уже O(1).

На внешнюю шину лепить, оно, конечно быстро будет. Но а она в ней есть? И лап на это хватит?

ИМХО, чем лепить CPLD, лучше тот DSP от Ti поставить. Там все уже есть, с примерами, итд.

[Rst7]

Боюсь, я не понял вашу мысль.

Я про програмную реализацию на AVR.

[Огурцов]

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

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

[dpss]

Обработка энкодера все же должна быть аппаратной (это уже много раз проверено). Раньше делал на рассыпухе, сейчас делаю ПЛМ типа EPM3064 (Altera). В нее у меня
влазит учетверитель (детектор направления) , 24 разрядный реверсивный счетчик с 3z буффером и выборка.С меньшим разрядом можно 2 обработчика вместить.
Стоимость EPM3064 ~60р.

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

[_Sam_]

Чтобы понять - нужен даташит на энкодер и максимальная скорость вращения в ТЗ.

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

[_Pasha]

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

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

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

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

[PhX]

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

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

[_Pasha]

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

и при наличии определённых механических возмущений немного подребезжит.

Обрабатываем его по INT0

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

[PhX]

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

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

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

[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% времени - уже замечательно.

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

[Rst7]

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

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

[_Pasha]

Хотя, конечно, вменяемые энкодеры так делать не должны.

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

[Rst7]

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

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

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

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

[_Pasha]

прилет такой помехи, которая клином поставит проц, надо рассматривать как аварийный режим.

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

[_Pasha]

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

Код

............
ENC_HANDLE:
.....................................
    BST    STATE,BIT_B
; а потом уже SREG сохраняется

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

[haker_fox]

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

[Rst7]

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

Согласен.

Природа отобрала 1 такт

Не согласен.

Код

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

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

Плакать не будем.

Согласен.

[_Pasha]

И аппаратный декодер загибается на этом деле.

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

[Огурцов]

Извините, но это аццкий отжых.

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

[haker_fox]

Там и программный загнется

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

А что это будет по частоте?

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

[_Pasha]

Даже для одного энкодера получится не прога, а аццкие танцы с бубном.

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

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

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

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

[Iptash]

... аппаратный декодер загибается на этом деле. Тут, похоже нужно программно... верно ли я мыслю?

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

Эскизы прикрепленных изображений

 

[Огурцов]

Дык Вы в процентах загрузки проца считайте - уже не так страшно.

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

В третьих - а кто будет еще что-то лепить туда

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

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

[haker_fox]

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

Хотя в случае такого сигнала мало что поможет:
Ch. A:________|---------|___________________|---------|___________
Ch. B:__________|-----|______________________|-----|____________
Хотя, можно извратиться и создать сервисное ПО для "калибровки". Т.е. для каждого уникального мышинного энкодера это ПО отследит периодически повторяющуюся последовательность сигналов с двух фаз и запомнит. Затем, эта последовательность будет использоваться уже при поллинге по таймеру. Тут, конечно, условие: сдвиг между фазами не должен быть очень малым, иначе различия направления не будет... Идея сильно бредовая?

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

Т.е. чтобы исключить ситуации, подобные дребезгу?

[_Pasha]

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

Не дописаль пока что Но все прерывания на асме, кроме ШИМа. На всякий случай. Тактов на энкодер - см выше. Servo Loop 500 мкс. Хочу 250. 

Хотя в случае такого сигнала мало что поможет:

А в обратном направлении вращения ?

[Rst7]

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

Тысячу, две.... Чукча не читатель, чукча писатель? Нарисовали же на предыдущей страничке 22 такта на энкодер. Ну на два будет тактов где-то 32 навскидку.

[haker_fox]

А в обратном направлении вращения ?

Все понял, что запутавшись окончально, нарисовал ерунду...

[Iptash]

...Т.е. чтобы исключить ситуации, подобные дребезгу?

И не только...

[_Sam_]

для каждого уникального мышинного энкодера

почему мышку не задействовать более эффективно?
просто опрашивать её по com или ps/2 И считать там всё само будет плюс ещё появиться 2/3 лишних входа, которые для вашего случая можно будет использовать как конечные ограничители для каждого из манипуляторов.

[dpss]

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

Ну если совсем ограничены в средствах , то почему бы не попробовать сделать энкодер самому? По точности он конечно будет "не супер" , но для учебно-отладочных работ сгодится. В качестве носителя рисунка кодового диска и ответного сектора можно использовать фотопленку которая заказывается в конторе типа http://www.reprocom.ru/ Думаю , что в каждом городе, где есть типографии должно быть что-то подобное. Точность вывода у них должна быть не хуже 15- 20 микрон на лист для офсетной печати. На лист А4 уместится с полсотни комплектов . Пленки можно будет наклеить на твердый носитель (стекло или в крайнем случае прозрачный пластик) эмульсией друг к другу. Основная морока будет с наклейкой кодового диска без экцентриситета и юстировка ответного сектора по углу и зазору.

[Огурцов]

Тысячу, две.... Чукча не читатель, чукча писатель? Нарисовали же на предыдущей страничке 22 такта на энкодер. Ну на два будет тактов где-то 32 навскидку.

Блииин. Дано 100 тактов. Пусть загрузка прерывания будет 50%, т.е. 50 тактов на прерывание и 50 тактов на основную программу. 30 * 1.5 == 90% вы уже заняли по первому варианту, и 64% по второму. И это _только_ энкодер. Что тут полезного еще можно добавить в 5..15 тактов ? И о каких чукчах вы говорите ? О тех, которые с бубном ?

[_Pasha]

Пусть загрузка прерывания будет 50%, т.е. 50 тактов на прерывание и 50 тактов на основную программу.

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

Для синхронизации сервоцикла используется 1 прерывание, и то с коррекцией стека, послед.порт - там обычно буферизация, АЦП - 1 или 2 или 0 каналов, дело вкуса, компаратор на максимально-токовую защиту (срабатывает как Ф1-один раз). Хотя, конечно, можно программу и неправильно организовать, тогда  оно не подымется никогда.

[Огурцов]

Ребят, ну вы смешные. 50% от 100 тактов - это 50 тактов, как ни считай. Ну или объясните тогда, как считать "правильно".

Ок, аналогичная задача. Тактовая 16мгц, цикл 50кгц, два уарта на 1мбит, энкодеры плюс кое-что еще. Какие шансы, что такое будет работать ? А без бубна ?

А вот, кстати, пример. Пока раскладка такая: всего 320 тактов, скажем, 240 можно отдать на прерывание. 38 - вход, 37 - выход, 17 * 2 * 2 - прием, 23 * 2 * 2 - передача, 150 - энкодеры, т.е. всего (примерно) 385. Упс. Теперь понятно, что и почему не работает. Если осетра немного урезать, до 500кбит, получается 305 тактов и оно хреново, но живет. Так что, брать в руки бубен ? Или осетра резать ?

[_Pasha]

Ребят, ну вы смешные.

Не-е это Вы смешные. Вроде бы все правильно пишете, но выходит пугающе. Объясните, какой цикл 50кГц имеется ввиду? Если это цикл обработки событий - то я буду смеяться. Если же это сервоцикл - то тут не осетр, а птеродактиль нужен. Да и 1Мбит поток - тяжеловато для несчастной меги - это уж трудно оспорить.

[Огурцов]

Цикл общий, прерывание одно. ШИМ, УАРТы, концевики, энкодеры. Математики, конечно, в нем нет, только самое необходимое, остальное вынесено в программу.
Прикинул, 75 тактов (от энкодеров) можно ужать за счет таблицы во флеши.

Сообщение отредактировал Огурцов - Mar 18 2009, 09:34

[_Pasha]

Цикл общий, прерывание одно.

А-а-а! Так это место называется по-разному: грабляндия, бубенленд, ж*па. Не надо так делать. Говорил, что буду смеяться. Не буду, лучше посочувствовать. На вполне ожидаемый вопрос: а как, собсно, надо? - отвечу примером, но он еще не готов, а так - букаф много.

[Rst7]

ШИМ, УАРТы, концевики, энкодеры.

Ну показывайте Ваш мегакод процедуры прерывания. Посмотрим.

[Огурцов]

Не надо так делать. Говорил, что буду смеяться.

А как надо ? Может посчитаем, что выгоднее, одно прерывание обрабатывать или четыре ? Я уж не говорю о нестабильности входа в прерывания, если о вообще возможности во время обрабатывать несколько прерываний.

Ну показывайте Ваш мегакод процедуры прерывания. Посмотрим.

Не, я тоже, как _Pasha, постою в сторонке, пока код не готов.

[_Pasha]

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

При такой постановке вопроса, как у Вас, оверхед получается больше за счет большей частоты проверок условий. А несколько прерываний обрабатывать вроде как и не надо. Сканирование линий -блокирующее прерывание, остальные - неблокирующие, и на это обязательно найдется причина: там двойной буфер, там однократное срабатывание, там АЦП - медленно по сравнению со сканом. 

[Огурцов]

Ок, простой вопрос. Сколько у вас тактов занимает обработка "прерываний" уарта (с буферизацией) ?
По поводу оверхеда. 1 мегабит нужно обрабатывать с частотой 100 кгц. При цикле в 50кгц это два чтения и две записи. На два уарта - в два раза больше, Скажите, какой оверхед будет по вызову восьми прерываний ? При поллинге это всего лишь 20 тактов.

[Methane]

Я читаю это все и фигею. Люди эти подсчеты тактов в данном случае вообще имеют смысл ли нет? Привод-то в любом случае будет значительно дороже. Ставте TMS320, и у вам будет не только аппаратные энкодеры, а даже блок работы с плавающей точкой, на котором вы сможете очень легко отладить алгоритм, законы регулирования, коэффициенты, все соптимизировать, перевести на плавающую точку итд.

Или я что-то в жизни не понимаю?

[PhX]

Я читаю это все и фигею. Люди эти подсчеты тактов в данном случае вообще имеют смысл ли нет? Привод-то в любом случае будет значительно дороже. Ставте TMS320, и у вам будет не только аппаратные энкодеры, а даже блок работы с плавающей точкой, на котором вы сможете очень легко отладить алгоритм, законы регулирования, коэффициенты, все соптимизировать, перевести на плавающую точку итд.

Или я что-то в жизни не понимаю?

Ну плавающая точка это пока дороговато. Я думаю 2806 с двумя аппаратными обработчиками энкодеров в самый раз. А асмовые развлечения... это так серыми мускулами поиграть.

[Methane]

Ну плавающая точка это пока дороговато.

Перепутал. Я имел в виду все отладить на плавающей точке, потом соптимизировать в фиксированную и запихать в 2806.

Попутно у вас будет под рукой UARTы нормальные ( FIFO) CAN, нормальный ШИМ и еще много чего, что позволит сделать действительно нормальную систему.

А асмовые развлечения... это так серыми мускулами поиграть.

Это называется мозговой онанизм.

[dpss]

Я имел в виду все отладить на плавающей точке, потом соптимизировать в фиксированную и запихать в 2806.

На настоящей плавучке плохо отлаживаться на 280Х . Слишком долго она выполняется. Добрые дяди из TI уже все сделали за нас http://tiexpressdsp.com/images/2/2e/IQmath.pdf
Я использую в своих приводах в основном формат IQ16 .

[Methane]

На настоящей плавучке плохо отлаживаться на 280Х . Слишком долго она выполняется. Добрые дяди из TI уже все сделали за нас http://tiexpressdsp.com/images/2/2e/IQmath.pdf
Я использую в своих приводах в основном формат IQ16 .

Я что-то подобное имел в виду.
http://focus.ti.com/docs/prod/folders/prin...s320c28346.html

С начала на нем логику/математику, потом портирование на более дешевый, с переходом на фиксированную точку.

[_Pasha]

Это называется мозговой онанизм.

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

[Огурцов]

+1 Мипсы-швипсы. Авр - наше все! Тулзы настроены, прога написана, схема нарисована, плата оттрассирована, отлажена, изготовлена и собрана. Так шта...отступать некуда(с)

[_Pasha]

отступать некуда(с)

Только вот с мегабитным потоком на АВР о 16 МГц - это демагогия ... подъеbка ... слишком смело, короче

[dpss]

+1 Мипсы-швипсы. Авр - наше все! Тулзы настроены, прога написана, схема нарисована, плата оттрассирована, отлажена, изготовлена и собрана. Так шта...отступать некуда(с)

Это похоже на попытку собрать "микрокалькулятор" на вакуумных лампах, с аргументами типа "а у меня есть полный чулан анодных трансформаторов - не пропадать же добру ! "

[Rst7]

Только вот с мегабитным потоком на АВР о 16 МГц - это демагогия...

А я всегда говорю, носить надо минимум данных. Обрабатывать все на месте. Не только на AVR, а везде.

[Огурцов]

Только вот с мегабитным потоком на АВР о 16 МГц - это демагогия ... подъеbка ... слишком смело, короче

Аха, ребято врубились, наконец-то ) В общем, если решать задачу стандартным образом, через прерывания, как тут предлагалось, то вы правы, это оно и есть.
Но вот поллингом выкачать мегабит реально, а если бы только уарты, то и легко. А вообще, таки придется доставать из чулана бубен и шаманить. Покрайней мере, как отшаманить около 70 тактов за счет килобайта флеша вполне понятно. Кроме того можно будет воспользоваться и запрещенным приемом - ассемблером.

[Rst7]

Или я что-то в жизни не понимаю?

Жизнь - штука многогранная, подходы в ней могут быть разные.

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

Первое - удел профессионалов. Второе - наоборот.

Результат, как ни странно, будет одинаковый по времени. Только вот каждый доллар разницы в цене между AVR и TMS мне потом в карман упадет и душу согреет. И для моего конечного заказчика лучше заплатить за контроллер менее 100 баксов, чем от 300 евро.

[Methane]

И для моего конечного заказчика лучше заплатить за контроллер менее 100 баксов, чем от 300 евро.

ГДЕ ВЫ ТАКУЮ РАЗНИЦУ В ЦЕНЕ НАШЛИ?

[Rst7]

ГДЕ ВЫ ТАКУЮ РАЗНИЦУ В ЦЕНЕ НАШЛИ?

Че, маленькая? Огласите, какие цены Вы можете предложить клиентам, представляющим из себя небольшие частные предприятия, которые тоже хотели бы автоматизировать свои технологические процессы?

Или Вы считаете, что такие производства не имеют право на жизнь? Пусть лучше на базарах китайскими шмотками торгуют? Зачем нам отечественный производитель?


Вообще тема малой автоматизации может прокормить весьма приличное количество людей. Я так считаю. Без минетжеров, конечно. И надо сразу иметь в виду, что в эту область с дорогими скороспелыми решениями можно не лезть, не нужны они, нет денег у заказчиков.

А неза..пающихся профессионалов вполне кормит.

[_Pasha]

ГДЕ ВЫ ТАКУЮ РАЗНИЦУ В ЦЕНЕ НАШЛИ?

Пардон за оффтоп. Реальная история. Один заказчик прошлой весной: "надо в бункер для зерна датчик уровня сделать". Ну, что такое датчик уровня сыпучих продуктов - это понятно всем. Списываюсь с "київськими москалями" - в смысле с тупыми зажравшимися конторами, которые надо умолять сказать мне цену на датчег...оставлять, сцуко, свои контакты, зачем-то итд итп. ЦЕНЫ от 300 баксов до 500 евро, только вы заплатИте, и мы вам через полгода его пришлем. В общем, все ясно. День второй: иду на радиорынок покупаю емкостный датчик производства какого-то киевского подразделения УТОС за 40 гривен. Ничего стремного - бумажки есть, название есть. Ставим его. Работает как часы. Зиму пережил. Это как классифицировать???

[Methane]

Че, маленькая? Огласите, какие цены Вы можете предложить клиентам, представляющим из себя небольшие частные предприятия, которые тоже хотели бы автоматизировать свои технологические процессы?

Разница между мегой и TMS максимум баксов в 10.

Или Вы считаете, что такие производства не имеют право на жизнь? Пусть лучше на базарах китайскими шмотками торгуют? Зачем нам отечественный производитель?


Вообще тема малой автоматизации может прокормить весьма приличное количество людей. Я так считаю. Без минетжеров, конечно. И надо сразу иметь в виду, что в эту область с дорогими скороспелыми решениями можно не лезть, не нужны они, нет денег у заказчиков.

А неза..пающихся профессионалов вполне кормит.

$10.

Ставим его. Работает как часы. Зиму пережил. Это как классифицировать???

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

[Огурцов]

тайм ту маркет

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

[Methane]

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

Вы хотя бы примеры к нему смотрели? Откуда вы знаете? У TI на каждый чих по примеру использования есть. А вы наткнулись на такую фигню, что смех пробирает, и топчитесь по граблям торжественно и упорно, считая такты.

AVR в сравнение с ним - дрова, конечно, но дрова привычные, и поэтому особых мучений выбора как бы и нет совсем.

Посмотрите для начала. Не боги горшки обжигают.

[Огурцов]

Откуда вы знаете?

Так я и спрашиваю - оцените. Опыт же у вас есть ? А я экстраполирую avr и тот путь, который был пройден лет за десять н TMS (на что угодно).


Да, еще, раз пошла такая пьянка. Толстый кандидат на замену avr у меня есть. И это не TMS. Поскольку я хочу дешево и малым трудом поиметь в своем девайсе еще и линух. Вот как стартануть - пока не знаю.

зы: а что можете сказать про трассировку под TMS ? 200мгц - это ведь совсем другая пестьтня...

[Methane]

Так я и спрашиваю - оцените. Опыт же у вас есть ? А я экстраполирую avr и тот путь, который был пройден лет за десять н TMS (на что угодно).

Да есть. Могу сказать что до TMS опыта у меня хватало. Тем не менее этот DSP у меня весьма теплые чувства оставил.

Это из

http://focus.ti.com/docs/toolsw/folders/print/sprc179.html

Код

/* ================================================================================
==

File name:       F281XQEP.C

                    

Originator:    Digital Control Systems Group

            Texas Instruments



Description:   This file contains source for the QEP drivers for the F281X



Target: TMS320F281x family

          

================================================================================
=====

History:

-------------------------------------------------------------------------------------

04-15-2005    Version 3.20: Using DSP281x v. 1.00 or higher

----------------------------------------------------------------------------------*/



#include "DSP281x_Device.h"

#include "f281xqep.h"



void  F281X_EV1_QEP_Init(QEP *p)

{



          EvaRegs.CAPCONA.all = QEP_CAP_INIT_STATE;    // Set up capture units

          EvaRegs.T2CON.all = QEP_TIMER_INIT_STATE;    // Set up capture timer

          EvaRegs.T2PR = 4*p->LineEncoder;             // Init Timer 1 period Register

          EvaRegs.EVAIFRC.bit.CAP3INT = 1;     // Clear CAP3 flag

          EvaRegs.EVAIMRC.bit.CAP3INT = 1;     // Enable CAP3 Interrupt



          EALLOW;                       // Enable EALLOW

          GpioMuxRegs.GPAMUX.all |= 0x0700;     // Set up the capture pins to primary functions

          EDIS;                         // Disable EALLOW

}





void F281X_EV1_QEP_Calc(QEP *p)

{



     int32 Tmp;



// Check the rotational direction

     p->DirectionQep = 0x4000&EvaRegs.GPTCONA.all;

     p->DirectionQep = p->DirectionQep>>14;



// Check the timer 2 counter for QEP

     p->RawTheta = EvaRegs.T2CNT + p->CalibratedAngle;



// Compute the mechanical angle in Q15

     Tmp = __qmpy32by16(p->MechScaler,p->RawTheta,31);    // Q15 = Q30*Q0

     p->MechTheta = (int16)(Tmp);                         // Q15 -> Q15

     p->MechTheta &= 0x7FFF;                              // Wrap around 0x07FFF



// Compute the electrical angle in Q15

     p->ElecTheta = p->PolePairs*p->MechTheta;            // Q0*Q15 = Q15

     p->ElecTheta &= 0x7FFF;                              // Wrap around 0x07FFF

}



void F281X_EV1_QEP_Isr(QEP *p)

{



     p->QepCountIndex = EvaRegs.T2CNT;    // Get the timer 2 counter for one mechanical revolution

     EvaRegs.T2CNT = 0;                   // Reset the timer 2 counter

     p->IndexSyncFlag = 0x00F0;           // Set the index flag



}

[Огурцов]

Не страшно...в первом приближении.

[Methane]

Так я и спрашиваю - оцените. Опыт же у вас есть ? А я экстраполирую avr и тот путь, который был пройден лет за десять н TMS (на что угодно).


Да, еще, раз пошла такая пьянка. Толстый кандидат на замену avr у меня есть. И это не TMS. Поскольку я хочу дешево и малым трудом поиметь в своем девайсе еще и линух. Вот как стартануть - пока не знаю.

Ну вы даете. То вы тут такты считали. То вдруг сразу "тяжелая артиллерия".

зы: а что можете сказать про трассировку под TMS ? 200мгц - это ведь совсем другая пестьтня...

Где там 200мгц? Эта пестня за пределы кристалла не вылазит внимательно доки прочитаете и все нормально будет. Обратите внимание на PLL. А внешнее ОЗУ вам не нужно. Так что расслабтесь. Обратите только внимание на ресет, он там был на старых крайне по идиотски сделан. (хотя я знаю почему) ну и учитывайте что греется оно.

[Огурцов]

Ну вы даете. То вы тут такты считали. То вдруг сразу "тяжелая артиллерия".

А иначе переходить на другой камень смысла нет. Проще такты посчитать. Или вычисления распараллелить, как я предлагал выше. AVR - весьма шустрая машинка, и в пределах одной нити можно творить чудеса.

Эта пестня за пределы кристалла не вылазит

Тогда контрольный выстрел. Есть в корпусе TQFP ? Лучше 0.8, хуже - 0.65. 0.5 - вообще тяжеловат.

[Methane]

Не страшно...в первом приближении.

ну так выкачайте все доки и посмотрите. Вы грохнули кучу усилий на действительно полную фигню. Вы собрались забраться на Эверест, но не справились с покупкой палатки у подножья. Может стоит поехать на Эверест на танке? Пусть не спортивно, но зато наверняка, если справитесь с управлением.

А иначе переходить на другой камень смысла нет. Проще такты посчитать. Или вычисления распараллелить, как я предлагал выше. AVR - весьма шустрая машинка, и в пределах одной нити можно творить чудеса.


Тогда контрольный выстрел. Есть в корпусе TQFP ? Лучше 0.8, хуже - 0.65. 0.5 - вообще тяжеловат.

http://www.ti.com/litv/pdf/mtqf013a вот есть.
Если вы плату сами будете процарапывать, то могут быть проблемы. Если в Резоните закажите, то по моему все нормально. 0.2мм даже на 0.5 хватит. 0.3мм ширина будет ок.

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

[Rst7]

Где там 200мгц? Эта пестня за пределы кристалла не вылазит

Да и внутри кристалла тоже не сахар. Четыре слоя платы - уже мимо бюджета. Лапы портов наверняка слабые, это у последних AVR'ов под 100ма ток КЗ, часто затворы можно качать без драйверов или с минималистским решением в 2 биполярника. Наверняка еще надо внешний BOD ставить, почему-то
непопулярная вещь в больших камнях, а это еще полбакса как с куста.

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

Кстати, о Ваших 10ти баксах. Я вообще говорил о стоимости готового контроллера, а не одной из микросхем, входящих в состав контроллера.

[Methane]

Да и внутри кристалла тоже не сахар. Четыре слоя платы - уже мимо бюджета.

Уже больше чем 200 баксов?

Лапы портов наверняка слабые, это у последних AVR'ов под 100ма ток КЗ, часто затворы можно качать без драйверов или с минималистским решением в 2 биполярника. Наверняка еще надо внешний BOD ставить, почему-то
непопулярная вещь в больших камнях, а это еще полбакса как с куста.

RTFM.

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

Сколько? По сравнению с AVR?

Кстати, о Ваших 10ти баксах. Я вообще говорил о стоимости готового контроллера, а не одной из микросхем, входящих в состав контроллера.

Вы хотите найти повод дальше трахаться считая такты и затягивая разработку на многие годы? Вы его найдете и без моей помощи.

[Огурцов]

Может стоит поехать на Эверест на танке? Пусть не спортивно, но зато наверняка, если справитесь с управлением.

На Эверсет лучше на вертолете. Вертолет куплен, осталось "мелочь" - научиться летать.

Если вы плату сами будете процарапывать, то могут быть проблемы. Если в Резоните закажите, то по моему все нормально. 0.2мм даже на 0.5 хватит. 0.3мм ширина будет ок.

Вопрос не про плату, а про пайку. 0.5 - тяжело. 0.8 - гораздо легче.

зы: в общем, пока тут болтали, отшаманил полсотни тактов. Уже хорошо.

[Rst7]

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

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

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

Да и такты надо посчитать обычно в коде, ну, из 50-100 команд. Это - пыль для моряка.

Так что не надо нас тут учить профессии.

[Methane]

На Эверсет лучше на вертолете. Вертолет куплен, осталось "мелочь" - научиться летать.

Лисапед у вас куплен. Детский. Трехколесный.

Вопрос не про плату, а про пайку. 0.5 - тяжело. 0.8 - гораздо легче.

Пробовали паять?

зы: в общем, пока тут болтали, отшаманил полсотни тактов. Уже хорошо.

Хорошо будет когда у вас оно заработает в полном объеме.

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

Вы считаете что будет быстрее объявив программизм дохлого контроллера искусством?

Так что не надо нас тут учить профессии.

Вот именно. Удачи вам. Только непонятно почему только на обсуждение такой фигни три дня потратили.

[Огурцов]

Лисапед у вас куплен. Детский. Трехколесный.

Хех, ну если два гигафлопса - лисапед, таки я уж и не знаю, что сказать.

Пробовали паять?

Аха. Несравнимо.

Хорошо будет когда у вас оно заработает в полном объеме.

Отож, будет хорошо.

Вы считаете что будет быстрее объявив программизм дохлого контроллера искусством?

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

[Rst7]

Только непонятно почему только на обсуждение такой фигни три дня потратили.

Почему бы благородным донам не поточить лясы. Я вот, например, сегодня целый день в квартусе кнопки пропедалил, хочу отвлечься от Verilog'а. А вчера писал прогу в очередном программерском контесте, тоже ниче так. Чистой воды функциональное программирование, никаких микроконтроллеров, тактов и прочей байды. Все в терминах O(log n), всякие красночерные деревья и т.д. Вполне себя нормально чувствую. А вот Ваш кругозор, видимо, на ковбойских камнях и закончился. И думаете, что Вы тут кого-то сможете задеть оскорблениями вида "выбрали трехколесный велосипед". Поверьте, благородные доны, собравшиеся тут выберут оптимальное транспортное средство Начнем с того, что мы тут уговаривали топикстартера не переделывать уже готовое железо. А Вы пришли сюда и начали кричать "нет бога кроме..." (цэ)

[Огурцов]

А я всегда говорю, носить надо минимум данных. Обрабатывать все на месте. Не только на AVR, а везде.

Вот ведь спорный вопрос. По ходу сегодняшней оптимизации понял, как в два раза уменьшить необходимый битрейт... - отказаться от сжатия и тупо гнать поток на/с PC. Другими словами сжатие примерно на порядок уменьшает общее количество данных, но при этом увеличивает пиковое количество данных. Забавно ? Короче, 500 кбит теперь уже достаточно для передачи данных, в то время как со сжатием требовался мегабит. Вуаля.

Сообщение отредактировал Огурцов - Mar 19 2009, 01:10

[Rst7]

Другими словами сжатие примерно на порядок уменьшает общее количество данных, но при этом увеличивает пиковое количество данных.

Фигня у Вас какая-то. Так не бывает.