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