VCucumber 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Извините, но это аццкий отжых. Не, нормальный отжыг. 16000000 / (80000*2) = 100 тактов. Коротка кольчужка. Даже для одного энкодера получится не прога, а аццкие танцы с бубном. Т.е. только для обработки энкодера прокатит, но если потребуется что-то еще, то нуегона. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Там и программный загнется :( Да, Вы правы.. не подумал... Будем, значит, доводить до ума мышинные датчики. А что это будет по частоте? Не более 4 КГц. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Даже для одного энкодера получится не прога, а аццкие танцы с бубном. Дык Вы в процентах загрузки проца считайте - уже не так страшно. Это раз. Во-вторых, кварц на 16 ставить оцень-не-хоцца, лучше 18,432. Чуть больше тактов все ж. В третьих - а кто будет еще что-то лепить туда? Разве что конкурентам насоветовать :) так тоже ж не дураки, знают где пределы у авров. Не более 4 КГц. Тогда можно усложнять обработку и вытянуть с него правильное направление по фронтам. Лишь бы не дребезжало оно так, что ложные срабатывания появляются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khlenar 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба ... аппаратный декодер загибается на этом деле. Тут, похоже нужно программно... верно ли я мыслю? Это какой декодер загибается? Вот декодер учетверитель. Все время делал по этой схеме и никогда не загибался(имеется ввиду декодер). Там синхронизация, частота, чем выше тем большую входную частоту можно обработать все зависит от быстродействия логики. Выхода подаешь на реверсивный счетчик типа ИЕ7 и т.п.. Такие устройства нужно делать засинхронизированными, а не по фронтам. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Дык Вы в процентах загрузки проца считайте - уже не так страшно. Процентов триста..пятьсот. В третьих - а кто будет еще что-то лепить туда Так "для сервопривода" - ПИДы какие-нибудь потребуются, ШИМом крутить, УАРТ, концевики, разная другая хрень. Впрочем, приведите ваш вариант - что на входе, что на выходе, сколько тактов, на чем написан... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Тогда можно усложнять обработку и вытянуть с него правильное направление по фронтам. Лишь бы не дребезжало оно так, что ложные срабатывания появляются. Хотя в случае такого сигнала мало что поможет: Ch. A:________|---------|___________________|---------|___________ Ch. B:__________|-----|______________________|-----|____________ Хотя, можно извратиться и создать сервисное ПО для "калибровки". Т.е. для каждого уникального мышинного энкодера это ПО отследит периодически повторяющуюся последовательность сигналов с двух фаз и запомнит. Затем, эта последовательность будет использоваться уже при поллинге по таймеру. Тут, конечно, условие: сдвиг между фазами не должен быть очень малым, иначе различия направления не будет... Идея сильно бредовая? Такие устройства нужно делать засинхронизированными, а не по фронтам. Т.е. чтобы исключить ситуации, подобные дребезгу? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Впрочем, приведите ваш вариант - что на входе, что на выходе, сколько тактов, на чем написан...Не дописаль пока что :crying: Но все прерывания на асме, кроме ШИМа. На всякий случай. Тактов на энкодер - см выше. Servo Loop 500 мкс. Хочу 250. Хотя в случае такого сигнала мало что поможет: А в обратном направлении вращения ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Процентов триста..пятьсот. Тысячу, две.... Чукча не читатель, чукча писатель? Нарисовали же на предыдущей страничке 22 такта на энкодер. Ну на два будет тактов где-то 32 навскидку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба А в обратном направлении вращения ? Все понял, что запутавшись окончально, нарисовал ерунду... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khlenar 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба ...Т.е. чтобы исключить ситуации, подобные дребезгу? И не только... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Sam_ 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба для каждого уникального мышинного энкодера почему мышку не задействовать более эффективно? просто опрашивать её по com или ps/2 :rolleyes: И считать там всё само будет плюс ещё появиться 2/3 лишних входа, которые для вашего случая можно будет использовать как конечные ограничители для каждого из манипуляторов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dpss 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Народ, в который раз меня вдохновила подобная беседа!!! И вот я тоже прихожу к выводу, что поллить энкодеры несколько лучше в плане устойчивого считывания информации. Особенно, если энкодеры не промышленные, а самопал - типа из мышки...( Как это не печально, но бюджет не позволяет купить что-нить готовое. Даже импульсов 200 на оборот... Ну если совсем ограничены в средствах , то почему бы не попробовать сделать энкодер самому? По точности он конечно будет "не супер" , но для учебно-отладочных работ сгодится. В качестве носителя рисунка кодового диска и ответного сектора можно использовать фотопленку которая заказывается в конторе типа http://www.reprocom.ru/ Думаю , что в каждом городе, где есть типографии должно быть что-то подобное. Точность вывода у них должна быть не хуже 15- 20 микрон на лист для офсетной печати. На лист А4 уместится с полсотни комплектов . Пленки можно будет наклеить на твердый носитель (стекло или в крайнем случае прозрачный пластик) эмульсией друг к другу. Основная морока будет с наклейкой кодового диска без экцентриситета и юстировка ответного сектора по углу и зазору. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Тысячу, две.... Чукча не читатель, чукча писатель? Нарисовали же на предыдущей страничке 22 такта на энкодер. Ну на два будет тактов где-то 32 навскидку. Блииин. Дано 100 тактов. Пусть загрузка прерывания будет 50%, т.е. 50 тактов на прерывание и 50 тактов на основную программу. 30 * 1.5 == 90% вы уже заняли по первому варианту, и 64% по второму. И это _только_ энкодер. Что тут полезного еще можно добавить в 5..15 тактов ? И о каких чукчах вы говорите ? О тех, которые с бубном ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 18 марта, 2009 Опубликовано 18 марта, 2009 · Жалоба Пусть загрузка прерывания будет 50%, т.е. 50 тактов на прерывание и 50 тактов на основную программу. Хотите посчитать загрузку - делайте это правильно, как сумму отношений числа тактов на прерывание к числу тактов, укладывающихся в период генерации прерывания. Там чтобы 50% загрузки достичь - это не сервак а андроид какой-то буит шибко умный. Для синхронизации сервоцикла используется 1 прерывание, и то с коррекцией стека, послед.порт - там обычно буферизация, АЦП - 1 или 2 или 0 каналов, дело вкуса, компаратор на максимально-токовую защиту (срабатывает как Ф1-один раз). Хотя, конечно, можно программу и неправильно организовать, тогда :smile3046: оно не подымется никогда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 18 марта, 2009 Опубликовано 18 марта, 2009 · Жалоба Ребят, ну вы смешные. 50% от 100 тактов - это 50 тактов, как ни считай. Ну или объясните тогда, как считать "правильно". Ок, аналогичная задача. Тактовая 16мгц, цикл 50кгц, два уарта на 1мбит, энкодеры плюс кое-что еще. Какие шансы, что такое будет работать ? А без бубна ? А вот, кстати, пример. Пока раскладка такая: всего 320 тактов, скажем, 240 можно отдать на прерывание. 38 - вход, 37 - выход, 17 * 2 * 2 - прием, 23 * 2 * 2 - передача, 150 - энкодеры, т.е. всего (примерно) 385. Упс. Теперь понятно, что и почему не работает. Если осетра немного урезать, до 500кбит, получается 305 тактов и оно хреново, но живет. Так что, брать в руки бубен ? Или осетра резать ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться