[VCucumber 0]

Извините, но это аццкий отжых.

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

[haker_fox 60]

Там и программный загнется :(

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

А что это будет по частоте?

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

[_Pasha 0]

Даже для одного энкодера получится не прога, а аццкие танцы с бубном.

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

 

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

 

 

 

 

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

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

[khlenar 5]

... аппаратный декодер загибается на этом деле. Тут, похоже нужно программно... верно ли я мыслю?

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

логики. Выхода подаешь на реверсивный счетчик типа ИЕ7 и т.п.. Такие устройства нужно делать засинхронизированными, а не

по фронтам.

[VCucumber 0]

Дык Вы в процентах загрузки проца считайте - уже не так страшно.

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

 

В третьих - а кто будет еще что-то лепить туда

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

 

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

[haker_fox 60]

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

Хотя в случае такого сигнала мало что поможет:

Ch. A:________|---------|___________________|---------|___________

Ch. B:__________|-----|______________________|-----|____________

Хотя, можно извратиться и создать сервисное ПО для "калибровки". Т.е. для каждого уникального мышинного энкодера это ПО отследит периодически повторяющуюся последовательность сигналов с двух фаз и запомнит. Затем, эта последовательность будет использоваться уже при поллинге по таймеру. Тут, конечно, условие: сдвиг между фазами не должен быть очень малым, иначе различия направления не будет... Идея сильно бредовая?

 

Такие устройства нужно делать засинхронизированными, а не

по фронтам.

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

[_Pasha 0]

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

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

 

 

 

Хотя в случае такого сигнала мало что поможет:

 

 

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

[Rst7 5]

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

 

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

[haker_fox 60]

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

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

[khlenar 5]

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

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

[_Sam_ 0]

для каждого уникального мышинного энкодера

почему мышку не задействовать более эффективно?

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

[dpss 5]

Народ, в который раз меня вдохновила подобная беседа!!!

И вот я тоже прихожу к выводу, что поллить энкодеры несколько лучше в плане устойчивого считывания информации. Особенно, если энкодеры не промышленные, а самопал - типа из мышки...( Как это не печально, но бюджет не позволяет купить что-нить готовое. Даже импульсов 200 на оборот...

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

[VCucumber 0]

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

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

[_Pasha 0]

Пусть загрузка прерывания будет 50%, т.е. 50 тактов на прерывание и 50 тактов на основную программу.

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

 

Для синхронизации сервоцикла используется 1 прерывание, и то с коррекцией стека, послед.порт - там обычно буферизация, АЦП - 1 или 2 или 0 каналов, дело вкуса, компаратор на максимально-токовую защиту (срабатывает как Ф1-один раз). Хотя, конечно, можно программу и неправильно организовать, тогда  :smile3046: оно не подымется никогда.

[VCucumber 0]

Ребят, ну вы смешные. 50% от 100 тактов - это 50 тактов, как ни считай. Ну или объясните тогда, как считать "правильно".

 

Ок, аналогичная задача. Тактовая 16мгц, цикл 50кгц, два уарта на 1мбит, энкодеры плюс кое-что еще. Какие шансы, что такое будет работать ? А без бубна ?

 

А вот, кстати, пример. Пока раскладка такая: всего 320 тактов, скажем, 240 можно отдать на прерывание. 38 - вход, 37 - выход, 17 * 2 * 2 - прием, 23 * 2 * 2 - передача, 150 - энкодеры, т.е. всего (примерно) 385. Упс. Теперь понятно, что и почему не работает. Если осетра немного урезать, до 500кбит, получается 305 тактов и оно хреново, но живет. Так что, брать в руки бубен ? Или осетра резать ?