Здравствуйте!
Уже длительное время мучаюсь вопросом: какой МК выбрать? Старшие ATmega64(128) или LPC2468.
Но для начала расскажу суть дела.
Требуется организовать управление тремя двигателями постоянного тока ДПМ-35-Н2-02. Под управлением подразумевается плавный разгон за короткое время (0.1 - 0.5 с) для исключения ударов в кинематике механизма и резких бросков пускового тока движков. Далее идет стабилизация по скорости через энкодеры. При приближении к заданной координате двигатель плавно сбрасывает скорость и стабилизируется в заданном положении. Для исключения аварийных ситуаций, связанных с потерей счета от энкодеров, предусмотрены оптические концевики, которые видимо надо завести на внешние IRQ МК. Энкодеры также заведены на внешние прерывания. Одновременно МК следит за током потребления каждого двигателя через датчик тока. Если ток достигнет максимального (задается программно) - происходит выключение двигателя и т.д.
Стабилизация по скорости осуществляется через ПИ регулятор.
Стаблизицация по положению пока через нечто самодельное.
Максимальная частота с каждого канала энкодера (всего два канала на один энкодер и три энкодера на три двигателя) около 4 КГц. В качестве энкодеров пока выступают датчики от мыши.
Стенд с одним двигателем собран на базе ATmega16 и работает довольно таки стабильно. Но когда кол-во двжиков, датчиков, возрастет в три раза, я не знаю, справится ли МК с нагрузкой. "Одновременно" МК должен контролировать три двигателя, используя выше описанные датчики, поддерживать связь с компьютером по RS-232, с пультом ручного управления по протоколу RS-232, опрашивать еще около 10 концевиков с реакцией на срабатывание не более 100мс и в ответ управлять несколькими пневмоприводами примерно с такой же быстротой.
С такого масштаба задачами я еще не сталкивался. И незнаю, как выбрать МК...( AVR знаю, ARM на примере LPC2468 осваиваю уже с 1 июня сего года. Вроде поддается))))
Но сделать систему на базе AVR для меня легкче, если он будет единственным МК в системе, я его знаю довольно не плохо, но не знаю, потянет ли он все это, особенно когда на него будут поступать прерывания с частотой 4 КГц (ну пусть в среднем 2КГц) с шести каналов, + крутиться три ПИ регулятора + ... все что описано выше...
С другой стороны ARM должен справиться, но я его пока плохо знаю. Да и "понравятся" ли ему эти же прервывания, не будут ли "прибивать" его быстродействия.
Была идея сделать управление на базе нескольких AVR, но ИМХО это удорожит систему и тогда уж проще поставить один ARM МК.
Простите, если сумбурно изложил мысли, но мне очень непонятно, что делать...
Спасибо!

Тут единственное узкое место - работа с АЦП. Чем-то надо синхронную выборку городить.


Если оно в рамках int16 - то почему бы и нет

PS: Ориентир.
у меня mega640 на 16МГц крутит (зависимо и пока немного упрощенно - навернуть чуть-чуть осталось контур управления) 4 асинхронника с частотой ШИМ до 10кГц + задействовано 16 каналов АЦП(переключаются с частотой 10кГц) + динамическая индикация+клавиатура+релейные входы(5) выходы(4). Специально занял все ноги и ресурсы, чтобы за счет заказчика побенчмаркать. Не могу сказать, что уже все работает, но проблема не в софте и не в МК.
Единственное замечание - пришлось на gnu-as (так и просится вторая буква s) городить два огромнейших прерывания. Нетрудно догадаться, что одно - на ШИМ, второе - на АЦП.

Я бы выбрал LPC.
При сравнимой цене круче на порядок (хотя бы по производительности)
Ну и ещё личная неприязнь к продукции Atmel

10 концевиков не получится завести на внешние прерывания, столько нет, придется опрашивать.
ИМХО все сильно зависит от реализации, попробуйте оценить время цикла, например в конце/начале выкиньте таймер на RS-232. На входа энкодеров можно завести частоту.

А так (ИМХО) должно получится, но если планируются последующие навороты, лучше ARM.

У Freescale есть специализированные микроконтроллеры для управления двигателями с возможностью синхронного взятия отсчетов АЦП по каналам, управление PWM, есть линии контроля для мостов управления двигателями. Это серии MC56F83xx. Софт к ним несколько специфичен.

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

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

??? 4 кГц. Входы на PCINTx. Антидребезговый интервал на лету с таймера 0. Дальше - насколько шустрый код...

Помоему гораздо круче было бы посадить всё на несколько тинек2313(если подойдут переферией) их по RS485 опрашивать такой же тинькой и через мост FIFO<=>USB контактировать с компьютером. Помоему, по цене и надёжности уделает LPC. Хотя дешевить на разовых вещах, тем более в робототехнике не резон, помоему.

Ну и самым лучшим решением, как уже сказали является ПЛИС.
Ethernet прикрутить не проблема. Скажем визнетовскими продуктами.

Посмотрите в сторону Microchip dsPIC30F2020 - все для построения приводов и DC/DC. АЦП + одновременная выборка по нескольким каналам + компараторы каждый с встроенным ЦАП, + шим + + +...

Мне кажется, надо смотреть в сторону 4-ёх ядерного пентиума с кэшем 2Мб на ядро и с частотой не менее 3ГГц и по альтере на каждый двигатель.

Ну а если отдать эту задачу начинающему программисту имеющему начальные познания в программировании и общее представления о понятии ШИМ, то он справится ну скажем на меге8 с частотой 8МГц, при этом она будет спать процентов 60 времени.

Так я, к примеру управляю 6 шаговыми двигателями (по 3 канала ШИМ 8кГц на 8МГц) и читаю 6 каналов АЦП. Дроблю шаг на 16, делаю разгон/тормажение, цифровую фильтрацию. Естественно устраняю нелинейность датчиков.

И хвалиться тут совершенно нечем, так как задача данная - примитивна до безобразия. Скомпилированная программа (Си) ~ 3kb + 3kb таблиц.
Невижу никаких сложностей с энкодерами. Я смогбы управлять таким количеством всей этой ботвы - сколько у меня только ног бы было. То есть на 640 меге думаю двигателей 40 я бы потянул. Во взаимосвязи.

Прикольно Вы сказанули.

Он пользуется ОС, наверное, она и тормозит всё.

А по поводу ПЛИС, то есть достаточно дешёвые + гораздо удобнее развиваться дальше.

Дык то шаговики, а там - коллекторники, с ОС по току. 40 - многовато будет. Еще и гемор с измерением тока.

Очень советую посмотреть в сторону TI 320F28xxx это специализированные контроллеры преднозначенные для управления электроприводами. Такой контроллер поднимет вашу задачу без особых проблемм.

Во-первых, напрасно Вы стебаете альтеры. Для данной задачи хватит чего-нибудь маленького, на 64 макроцела. Здесь главное достичь скорости обсчета датчика - и не мне Вам рассказавать, сколь альтера хороша в этой роли...

Во-вторых, причем тут АЦП - сигнал для управления мы получаем с энкодера. Очен интересно, как Вы сможите управлять десятком вдигателей на одной меге, если с каждого из них будет поступать сигнал с частотой 4кГц (как у автора) - по 400 тактов между прерываниями, маловато будет...

*) по 4000 тактов

Понятно, сморозил я, но решение для энкодеров лучше такое :
1. Запускаем поллинг на >=16кГц. Энкодеры на один порт.
2. Учитывая, что автор возможно-таки присядет на mega64, читать порт и через таблицу переходов на все 256 состояний (ну, отожрет оно памяти, дык не страшно) сделать в асме наилегчайшее прерывание, работа которого уж точно будет незаметна. Только таблицу и состояния сделать сторонней программой. Так уж можно и 4/8/16/...скока нада энкодеров обслужить и без альтеры.

Честноя говоря, не понял, что Вы имеете ввиду? Какой полинг? Чтобы получить скорость двигателя, нам необходимо замерять интервал между импульсами (или частоту импульсов) - как Вы это предлагаете делать на меге?

Подождем автора, пусть скажет, какой у него временнОй шаг по стабилизации.

Тем не менее по 4000 тактов. Какой смысл обрабатывать таким образом.
Необходимо чётко разделять ввод от вывода.
То есть я бы делал груповвой ввод всех энкодеров (полингом как отмечали) с табличным пересчётом и формированием таблицы направлений. Ориентировочно это бы заняло ~ 15% загрузки процессора. Ну пусть 30%. Ну и груповой совтовый ШИМ ещё процентов 10-15.

Причём при таком подходе очень мало загрузка будет зависить от количества каналов. О чём я и имел вам сказать.

Да и ещё. Управление шаговым двигателем с дроблением шага, на мой взгляд сложнее управления двигателем постояннного тока с энкодером.


Применение процессоров с аппаратной поддержкой управления двигателями, конечно приветствуется, но выбор элементной базы включает массу вопросов и соотношение стоимости/объёму выпуска имеет важное значение. Соответственно выбор за вами.

Могут быть грабли. Частота высокая потребоваться , например.


Не обязательно. Смотря как делать тот же синус, например.

Привет, ZLOI))) Давненько не общались)
По теме. Лежат у меня 4 шт ATmega8-8PU. После прочтения всего отвеченного начал склоняться на сторону создания контроллера ДПТ на одной меге. Причем контроллер может быть получится универсальным. Т.е. его можно будет "засобачить" и в другую разработку. По началу (месяца 3 так назад) так и планировалось. LPC подкупил тем, что не придется отлаживать межконтроллерный обмен по шине, придумывать протокол, вся система будет на одном кристалле, что упростит ее.. К слову для свзязи трех отдельных контроллеров ДПТ намеревался использовать I2C.

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



ОС нет) В контроллер ДПТ на AVR ОС (имхо) в моем случае это лишнее... Для центрального МК, который будет управлять всей системой - может быть и понадобиться, но заранее сказать не могу.


К сожалению, освоение нового - это время, которого почти нет + деньги, которые тоже имеют свойство быть в малом количестве Пока есть задача справиться с использованием той элементной базы, которая есть на месте... Но за совет - спасибо! Я обязательно посмотрю в сторону этих контроллеров. Хотя бы на будущее.


Я не имею большого опыта в ПИ регуляторах, но экспериментальными методами удалось установить, что ПИ по скорости замечательно работает, если его запускать каждые 15 - 5 мс.


Здесь я с Вами согласен, потому что понимаю о чем идет речь. Но видимо буду делать систему на отдельных МК, как написал в этом же посте, чуть выше.

Можно чуть более подробнее? Действительно интересно!

Вот именно! И как я выше написал - это время на освоение + деньги. Потом я все таки четко знаю, что на AVR эта задача решаема - следует из моего первого поста. И при этом энкодеры заведены на прерывания, программа написана на Си++. И все работает. Если действительно сделать законченный вариант контроллера ДПТ с возможностью подключения по шине к основному вычислителю + возможность подключения по RS-232, например к компу напрямую, для отладки, настройки, экспериметнов + какие либо навороты, то я думаю, получиться неплохой девайс!

Огромнейшее спасибо ВСЕМ ответившим! Для меня ценны все Ваши рекомендации, советы, замечания!

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