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

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

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

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

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





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

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

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


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

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

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


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

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






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

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

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

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

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

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

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

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