Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Частота передачи/приема данных на LPT 15.04.04 11:57
Автор: serpent Статус: Незарегистрированный пользователь
|
|
Народ! Вы не подскажете мне с какой частотой я могу передавать и принимать данные с LPT порта и как ее можно регулировать?? У меня схема подключения шагового двигателя на LPT и там есть максимальная частота после которой двигатель будет пропускать шаги (частота приемистости). Вот мне и нужно будет ее держать в установленных пределах.
|
|
В дополнительных режимах (ECP, EPP) не мерил, геморно с DMA... 15.04.04 17:01
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 15.04.04 17:04 Количество правок: 4
|
> Народ! Вы не подскажете мне с какой частотой я могу
> передавать и принимать данные с LPT порта и как ее можно
> регулировать?? У меня схема подключения шагового двигателя
> на LPT и там есть максимальная частота после которой
> двигатель будет пропускать шаги (частота приемистости). Вот
> мне и нужно будет ее держать в установленных пределах.
В дополнительных режимах (ECP, EPP) не мерил, геморно с DMA ковыряться и всем остальным. В режиме SPP максимум около 1.2 Мб/сек видел, на большинстве современных писюков от 700 кб/сек до 900 кб/сек. Поскольку ЛПТ работает побайтово, то кб/сек и есть частота (тыс. раз в сек.). Чтение примерно с такой же частотой происходит. Это максимальные скорости (больше никаких действий не производится). На старых писюках можно было играть частотой шины, делителем PCI/ISA, и таймингами на операции I/O.
Раскрутить шаговый двигатель до 900 тыс. шагов в секунду можно, но не сразу. Следует очередной шаг делать после того, как предыдущий будет отработан (на то он, шаговый, и расчитан). Еще бы сделать поправку на приведенный момент инерции всего механизма. Было бы здорово, если б ШД возвращали ответный сигнал, когда шаг будет сделан.
Предлагаю простое решение: подали сигнал сделать шаг и запомнили время, надо сделать очередной шаг - посмотрели на разницу текущего и запомненного времени, если не достигло нужного значения - ждем. Лучший счетчик точного времени - счетчик тактов процессора (есть у всех пентиумов и их клонах), только сначала откалиброваться по таймеру, чтоб тактовую частоту константой не вбивать. Есть еще прикольные варианты, но они менее привлекательны.
|
| |
мой движок до 900 шагов в секунду не раскрутишь, у него... 16.04.04 07:00
Автор: serpent Статус: Незарегистрированный пользователь
|
мой движок до 900 шагов в секунду не раскрутишь, у него номинальная частота приемистости всего 800 Гц и я глупо сомневался в способноати LPT держать такую частоту. А вообще отсутствие обратной связи считается достоинством ШД т.к. это значительно удешевляет схему управления. У меня еще вопрос - как считать информацию с таймера в ассемблере?? или может средствами WinAPI???
|
| | |
Параллельный порт выдает 900 тысяч I/O в секунду (около... 16.04.04 10:08
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 16.04.04 10:18 Количество правок: 4
|
> мой движок до 900 шагов в секунду не раскрутишь, у него
Параллельный порт выдает 900 тысяч I/O в секунду (около милиона). Это я к тому, что обычные инструкции обрабатываются со скоростью несколько милиардов в секунду на современных процессорах.
А подавляющее большинство ШД можно разогнать до скоростей, которые во много раз превышают заявленные. Просто он будет функционировать в режиме синхронного двигателя.
> номинальная частота приемистости всего 800 Гц и я глупо
> сомневался в способноати LPT держать такую частоту. А
> вообще отсутствие обратной связи считается достоинством ШД
> т.к. это значительно удешевляет схему управления. У меня
Как сказать, многие вещи по-хорошему без ОС не реализовать, вот и приходится навешивать дорогостоящие датчики. Получается дороже, чем интегрировать.
> еще вопрос - как считать информацию с таймера в
> ассемблере?? или может средствами WinAPI???
Чтобы по-хорошему читануть из таймера надо по нему доку почитать, могу кинуть, но это гиблое дело. Предлагаю Сишную функцию "clock()", она наиболее быстрая, но ее дискретность (CLK_TCK) может быть обманчива, и на эти грабли я наступал.
Считать счетчик тактов можно так:
asm db 15, 49
Это код (двухбайтовый), мнемоника может быть разная или отсутствовать. В eax будут младшие 32 разряда счетчика, а в edx старшие.
В случае нормального компилятора:
inline unsigned long long timer( void ){ asm db 15, 49; }
Если не понравится предупреждение из-за отсутствия "return" с параметром, можно прагмами обвесить. В большинстве 32-разрядных компиляторах 64-разрядное целое - это "long long", полагаю за исключением Альфы. Не все компилеры любят ассемблер в инлайн-функциях, скорее всего проигнорируют инлайновость. Некоторые компилеры захотят еще кучу директив.
|
| | | |
:] 16.04.04 11:55
Автор: serpent Статус: Незарегистрированный пользователь
|
> Параллельный порт выдает 900 тысяч I/O в секунду (около
> милиона). Это я к тому, что обычные инструкции
> обрабатываются со скоростью несколько милиардов в секунду
> на современных процессорах.
я там опечатался (900 тысяч шагов). а насчет синхронного движка я даже не догадывался. в любом случае спасибо за инфу.
Кстати я не совсем понял насчет счетчика тактов. Я понял что после прогона 15 и 49 возвращается некое число. Но что оно будет значить? Количество оттикавших тактов? Но за какой период? Чем например будет это количество отличатся на Pentium 1700 Ггц и 2000 Ггц?
|
| | | | |
В этом случае смысл шаговости пропадает. И проблемы с... 16.04.04 12:41
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 16.04.04 12:43 Количество правок: 2
|
> я там опечатался (900 тысяч шагов). а насчет синхронного
> движка я даже не догадывался. в любом случае спасибо за
> инфу.
В этом случае смысл шаговости пропадает. И проблемы с быстрой остановкой будут. Каждый двигатель для своей задачи!
> Кстати я не совсем понял насчет счетчика тактов. Я понял
> что после прогона 15 и 49 возвращается некое число. Но что
Два регистра заполняются счетчиком. Поскольку в подавляющем большинстве компиляторов данные возвращаются именно через эти регистры, то ничего мудрить не надо - процессор заполнит их как надо, дальше возврат из функции.
> оно будет значить? Количество оттикавших тактов? Но за
Количество тактов с момента последнего сброса/ресета/включения. Програмно счетчик изменить пока не предоставляется возможным. Некоторые ОС могут неоднозначно отреагировать на эту микрокоманду.
> какой период? Чем например будет это количество отличатся
> на Pentium 1700 Ггц и 2000 Ггц?
Опять опечатка - раз уж речь идет о тысячах, то это будут мегагерцы.
Этот счетчик именно так и инкрементируется - каждый такт, т.е. сколько мегагерц/гигагерц столько милионов/милиардов раз в секунду он и увеличится на единичку. Во многих процессорах эта микроинструкция выполняется два такта и начинается ее выполнение каждый четный такт, так что не удивляйтесь если значения будут четные. Все равно точность и дискретность бешенная - можно скорость света мерить или скорость распространения электрического сигнала в проводниках (доли наносекунд). Может это и не надо, но кашу маслом не испортишь, а работать с этим счетчиком значительно проще, чем со стандартным таймером. Есть и другие варианты, но они хоть и лучше таймера, но хуже этого счетчика.
|
| | | | | |
Это то понятно. Я к тому, что просто не думал что можно и... 17.04.04 07:14
Автор: serpent Статус: Незарегистрированный пользователь
|
> В этом случае смысл шаговости пропадает. И проблемы с
> быстрой остановкой будут. Каждый двигатель для своей
> задачи!
Это то понятно. Я к тому, что просто не думал что можно и так его использовать.
>
> Количество тактов с момента последнего
> сброса/ресета/включения. Програмно счетчик изменить пока не
> предоставляется возможным. Некоторые ОС могут неоднозначно
> отреагировать на эту микрокоманду.
ясненько. попробуем...
|
| | | | | |
Ну из других вариантов под винду могу предложить... 16.04.04 13:04
Автор: Killer{R} <Dmitry> Статус: Elderman
|
> маслом не испортишь, а работать с этим счетчиком
> значительно проще, чем со стандартным таймером. Есть и
> другие варианты, но они хоть и лучше таймера, но хуже этого
> счетчика.
Ну из других вариантов под винду могу предложить QueryPerformanceFrequency и QueryPerformanceCounter - оно хоть такты не считает - частота порядка мегагерца. Зато не вызовет исключения Privileged Inscruction коей является операция rdtsc.
|
| | | | | | |
Это под Виноус... интересно что за ОС у автора, полагаю это... 16.04.04 14:20
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Ну из других вариантов под винду могу предложить
> QueryPerformanceFrequency и QueryPerformanceCounter - оно
Это под Виноус... интересно что за ОС у автора, полагаю это все под ДОСом должно быть (Реалтайм!).
> хоть такты не считает - частота порядка мегагерца. Зато не
Интересно откуда мегагерцы? Таймер там что-ли подкручен?
> вызовет исключения Privileged Inscruction коей является
> операция rdtsc.
Блин, странно, иногда действительно под Виндами выскакивало.
|
| | | | | | | |
Не знаю точно механизм работы этого таймера в виндах... 16.04.04 17:34
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 16.04.04 17:56 Количество правок: 1
|
|
Но могу предположить что на разных системах могут использоваться разные механизмы. Как минимум обычный перепрограммированный на нужную частоту таймер, тот самый который используется планировщиком задач самой ОС (который на irq0/int8), либо даже сам rdtsc о чем косвенно говорит мсдн в статье про этот таймер.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
