Здравствуйте!
Уже длительное время мучаюсь вопросом: какой МК выбрать? Старшие 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 МК.
Простите, если сумбурно изложил мысли, но мне очень непонятно, что делать...
Спасибо!

Понятно, сморозил я, но решение для энкодеров лучше такое :
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 сейчас развернулась тема по опросу энкодера. Там обсуждаются многие варианты.