Здравствуйте! Имеется три фотоимпулсьных датчика (оптопара, которая перекрывается вращаемой крыльчаткой), частота импульсов с каждого в пределе достигает 300 Гц. Их нужно опрашивать в реальном времени, в момент начала вращения двигателя, следя за кол-вом импульсов и т.о. измерять пройденное расстояние. По моим прикидкам, раз за 1 сек. датчик дает примерно 300 импульсов, а часть робота движется от одной крайней точки к другой около 10 сек, соответсвено за это время мы насчиатаем 3000 импульсов, и для хранения этого числа нужно не менее 12 бит (округилим до 16). ATmega16(32), которую планируем использовать для управления, имеет один такой таймер, да и тот занят под PWM. В принципе можно и задействоать 8 битный таймер, дополнив его программным счетчиком, но дачтика 3. Что можете посоветовать в этой ситуации?
Пока мои идеи:
1. найти соотв. МК (например ATmega1281), у которого 4 16-битных таймера, но это дорого...
2. использовать внешние мсх таймеров, с которых можно считывать значение по шине I2C или подобной. Есть ли такие в природе?
3. Парсить все три датчика программно, но это займет много времени МК, учитывая, что на нем еще крутиться ОС scmRTOS.
Прошу прощения за немного сумбурный стиль изложения.

ябы использовал INTы.... настало прерывание - +1 в соответствующую переменную... и таймер настроилбы на секунду.
Канешна не очень то, что программа постоянно должна будет летать по прерываниям... ну принципе если инкриментируемые переменные будут в аккумуляторах, т.е при заходе в эти прерывания не надо будет обращаться к озу, то програмка совсем не много времени там будет проводить - вообщем ничего страшного...
Кста - по теме... обязательно нужны будут какиенить тригеры шмита или на худой конец кондёры на этих входах, помница была подобная задачка - подключил напрямую, так за один челчок насчитывало до 1000 переключений....

Можно использовать 8-ми битный таймер. Настроить прерывание по переполнению. В прерывании инкрементировать старший байт двухбайтного счетчика. Младший будет в TCNT0(2).

Об это я уже написал в первом посте. Но датчика три!


Маловероятно что этот способ подойдет, у меня ведь еще ОС используется, и обработчик прерывания уже легким не сделать(

Видимо все таки логичнее поставить более солидную мегу, у которой на борту есть необходимое количество таймеров. А то разводить на плате кучу кристаллов это как-то несовременно)))
Хотя, ради интереса, может кто-нить знает, существуют ли в природе 12 или более битные тамймеры, которыми можно управлять по удобной шине и у которых есть режим сравнения. Т.е. записал в него число X, он ожидает на тактовом входе клоки и когда их будет ровно X, выдаст сигнал, заведенный на INT МК?

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

Я делал нечто подобное на ПЛИС. Записывал число Х по SPI-интерфейсу.

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

Прерывания приходят 300 раз в секунду.

Три обработчика.

100 * 300 * 3 = 90 000 - тактов в секунду на выполнение этой задачи.

Если контроллер работает на частоте 10 МГц то этой задачей он будет занят примерно 1% времени.


А много это или мало я не знаю.

Анатолий.

Видимо действительно придется ставить жирный МК.. С плис не умею работать( Осваивать некогда... времени в обрез... На крайний случай думаю поставить дешевые at90s2313 на управление каждым движком. В роботе, который модернизирую, 3 "сложных звена", состоящих из: двигателя, двух концевиков, фотоимпульсника и электромагнитного тормоза. Так вот, бросить на каждый такой набор по одному МК... и свзать их с главным МК по I2C. Главному МК еще останеться управлять двигателем поворота робота (там только два крайних положения), схватами + разруливать работу трех первых МК, держать свзять с ПК и пультом ручного управления. Хотя не очень-то мне этот вариант и нравиться, уж чего чего , а МК не нужно плодить в системе (ИМХО).Смотрю в сторону ATmega1281 или ATmega2561, но хватит ли производительности одного кристалла? К сожалению, не знаю как расчитать... Осваивать более мощный МК опять же время не позволяет...

Хватит и ещё запас останется... на самом деле задачкато так се и огород с несколькими МК городить точно не сотоит... и всвязи с этимже непонятно - а зачем ОС там?

Многозадачность так или иначе понадобиться: задач несколько (управление двигателями, опрос датчиков, связь с ПК, связь с пультом ручн. управления). scmRTOS надежно себя показала в управлении другого робота! Огромнейшее спасибо уважаемому dxp за сей продукт!

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

Согласен с superbizzon, используйте 3 ИНТх . В обработчике прерываний плюньте на ОС (конечно же те регистры которые будут использоваться при обработке запихнете в стек), напишите на асм чтобы только суммировал. Если нужно прерывание по определенному числу , там же в прерывании и сравнивайте . Затем по scmrtos ipc запустите обработку по концу (в этом случае придется принять правила написания прерываний, но только на момент сравнения).

Программа для всех прерываний почти что будет одинаковая

(написано для случая использования ОС)

А все три датчика одновременно работают?

А планируется ли дребезг?

А что если под задачи управления двигателями и, соответственно, опрос датчиков выделить отдельный мелконогий МК, скажем, какую-нибудь тайни 8-ми ногую. Тогда операционка полностью разгрузится от деталей управления, только глобальные команды, типа "ноге 2 продвинуться на 10 см".

(Валяется у меня дома один робот с УЗ обзором, руки так и чешутся его запустить...жалко времени не хватает.)

Не нужно никакого крутого контроллера,плисины или оси ,все эти задачи я года полтора решил на тини2313 ,правда пришлось буквально трамбовать в нее код ,у меня только обслуживание протокола сьел 70% памяти программы ,думаю мега48 или 88 в самый раз.
Если потребуется более детальное описание алгоритма регулировки оборотов двигателей ,пишите на личку.Протокол я думаю для вас - это уже дело техники

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


Эта ситуация не исключена.


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


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


Говорилось о жирном МК У которого не менее трех 16 битных таймеров и куча ног.

Для моего случая это не подходит. У меня робот двигается в трехмерной системе координат. Для обслуживания каждой координаты требуется:
1. Линия для включения двигателя.
2. Линия для управления направленим движения.
3. Линия для PWM модуляции.
4. Две линии для двух концевиков крайних положений + еще одна для фотоимпульсника.
5. Одна линия для управления тормозом.
Итого 7 линий. При трех координатах имеет 21 линию. А еще есть другие датчики и один двигатель на поворот базы робота, где не требудется управление скоростью.
Значит тини уже не подходит. Потому-то речь и шла о жирном МК.

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

Спасибо, но с PWM модуляцией мы вроде разобрались

300 Гц - это необходим опрос с частотой > 600Гц. Запускается ядро с циклом 0.5 мС и спокойненько опрашиваются датчики, при этом даже можно отфильтровать дискреты. В этом цикле счетчики. За 0.5 мС. Мега, запущенная на частоте 16Мгц может успеть очень много чего сделать. Хотя, конечно если необходимо при этом что-то пересчитывать трехмерное, привязанное реально к этому самому циклу и еще держать связь то, во избежании риска стоит заложить какой нить Силикон или PIC24.

Бывают датчики, которые ещё и реагируют на, например, включение пускателя иголками Я в свое время когда с похожей проблемой разбирался, пока не сделал обработку дребезга по входам, ничего не получалось. Делал на ПЛИС и имхо именно на ПЛИС надо делать. А если у вас промышленный объект, то и датчики должны быть с двумя сдвинутыми каналами для определения направления?

Тут интересно конечно у GM спросить как это реализованно в 28-й серии Там вроде по входам можно включать регулируемый антидребезг...

Для каждого пина можно выставить количество выборок, 1/3/6 (для периферии ещё можно сделать асинхронно), по которым принимается решение об изменении сигнала на входе. Период между выборками можно выставить от 1 системного клока до 510. Выставляется, к сожалению, группами по 8 пинов. Подробнее смотрите input qualification в описании spru712a, с.76

1 Сделано
2 Сделано
3 Сделано
4 Концевиков нет ,считается по фотоимпульсам
5 Сделано

Все это для двух двигателей и поворотной платформы. + по 485 клонируем до 128 таких модулей

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

Я не про ШИМ ,а про стабилизацию оборотов хотя бы на 10 разных скоростях ,ну да ладно

В моем случае они нужны. Один, как минимум, для определения нулевого положения звена.

Простите, просто не понял Вас. Думаю, что стабилизация скорости вращения не очень сложный вопрос. Хотя как знать...

Я недавно решал подобные задачи: на ATMega128 и XCR3384 (по разным сторонам платы друг под другом).
Задачи uC: RS485 - выносной пульт, RS485 - сеть с аналогичными контроллерами, замыкание СС, связь с ПЛИС. Никаких RTOSей, загрузкf uC процентов 10, не более.
Задачи ПЛИС: SPI c AD7888 (8 ADC), 2 частотомера, жесткая логика (типа ШИМ с конечниками, перекодирование галетников конфигурации и т.д.).
Когда ШИМ зашимил, пошли такие помехи,что пришлось ввести цифровую фильтрацию (на ПЛИС),а где бы я был с реализацией на uC.
Более оптимальный вариант - использование FPSLIC (AT94), но это такие заморочки...

Как я уже говорил выше, с ПЛИС не знаком... Времени на освоение нет. Буду пытаться все сделать на МК.

Лет 20 с небольшим я решал обработку ФИД на микросхемах TTL. Как я себе представляю рещение на uC?
ФИД дает 2 последовательности сигналов, назовем их SIN и COS. После приведения их TTL уровню, на основе предыдущей комбинации и текущей получаем +1 или -1 для реверсивного счетчика или для двух нереверсивных с последующим вычислением разности. При этом получается учетверение входной частоты, т.е. при Fmax=300 Гц получаем уже 1200 Гц. Частота обработки (по Котельникрву - Шеннону) для отсутствия пропуска импульсов д.б. > 2400 Гц. Если 3 канала, то количество счетчиков соответственно масштабируется. Т.к. частоты не такие большие возможно программная обработка.
Примерно так.
class TDat
{
unsigned char DZ;// предыдущее значение бит 0 - SIN, бит 1 - COS
int FID; // значение счетчика - собственно самого датчика
public:
TDat(void) {...}; // инициализация портов для SIN COS, первое чтение их, занесение в DZ, FID=0
void Mes(void) { // функция расчета FID
unsigned char temp=... // снятие сигналов SIN COS
if (temp!=DZ) { // надо корректировать FID и DZ
..... // SWITCH c окончаниями FID++; или FID--;
DZ=temp;
}
};
int Read_FID(void) {return FID;};
};
Вначале
TDAT DAT1, DAT2, DAT3;
Далее в прерывание по таймеру c частотой >2400 Гц включаете DAT1.MES()..., а где используете функцию DAT1.Read_FID()....
Обратите внимание различную реализацию инициализаций для разных FID, и снятие сигналов SIN COS.
Желаю успехов

К чему прикручен энкодер, к валу двигателя или к валу редуктора?
Если смотреть по частоте то к редуктору.
Тогда посчитайте погрешность позиционирования манипулятора, есть сомнение что он попадет заготовкой в патрон.
Или обслуживание это что-то другое?

Может быть как вариант поставить еще одну тини, не запускать на ней ОС, а просто подсчитывать импульсы и передавать данные меге.

Это хорошая мысль.

может 8253 подойдёт..как раз три(16) таймера..по скорости вроде протащит...правда один корпус ышо добавиться...

с уважением
(круглый)

To alexander55:
Большое спасибо за приведенный пример и некоторую теорию! Но один не реверсивный датчик. Т.е. одна открытая оптопара + крыльчатка. Реверс придется учитывать программно.



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


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


Интересная микросхема. Посмотрю ее. Спасибо!

Вот нашел ,где лежат мои художества

http://technovision.ru/support/ml/bodja.html

Думаю будет познавательно.

Почитал. Действительно познавательно! Жаль, что пример программы под МК на ассемблере