Приветствую всех на форуме.
Возникла у меня такая задача - нужно читать с LPT-порта с "дискретом" 10 микросекунд. А таймеры в операционках (Windows, Linux) работают от часов и у них дискрет 1 миллисекунда. Посему, замечательная библиотека input32.dll и ей подобные мне не подходят (по крайней мере, я не вижу способа их использовать в данных условиях).
Но LPT-осциллографы же как-то читают и с меньшим дискретом.
Прошу помочь информацией, как запрограммировать на высокоуровневых языках работу LPT с DMA. Либо каким образом, помимо этого, можно реализовать требуемое.

можно попытаться сделать так: настроить порт в режим ECP или EPP (я что-то подзабыл, какой из них умеет работать в DMA-режиме) и использовать для обращения к LPT системную функцию для блочного чтения файла. в вашем девайсе надо будет предусмотреть подачу строба "данные готовы" (в соответствии с протоколом ECP/EPP) с периодом 10 мкс, тогда все остальное драйвер Windows сделает сам автоматичеси.

другие способы, имхо, не помогут...

Я правильно понял, что в биосе настроить на ECP (вроде ДМА он поддерживает), на строб "данные готовы" повесить "генератор" с периодом 10 мкс и читать LPT как блочный файл 1 раз в миллисекунду блоками по 100 байт? Ну или раз в 2 миллисекунды блоком в 200 байт и т.п.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

P.S. еще, возможно, придется поиграться с настойками прерывания от LPT в свойствах драйвера порта (диспетчер устройств) - я, к сожалению, давно не интересовался, как родной лптшный драйвер у винды устроен - нужны ему прерывания или нет... в старых версиях винды (95, 98) ему было начхать на прерывания...

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Ещё у кого-нибудь варианты есть?

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Эм, винда какбэ многозадачная система, так что вариантов не много!

Ну, какбэ, интересуют варианты заставить LPT с DMA работать. Многозадачность винды при этом не играет роли. Звуковухе ведь это не мешает оцифровывать. Что там сигнал о готовности буфера, что тут должен быть. Только как запрограммировать-то?

Дискрет у компонентов-таймеров для Delphi или Builder C++ вообще-то еще хуже - 22 мс...
Сделайте вот что. В программе заюзайте API-функции QueryPerformanceFrequency, QueryPerformanceCounter. Первая читает частоту суперпупермегасчетчика :0) в ПК (даже в 486 частота была в районе 1 МГц), вторая - текущее значение. Дальше делаете так:

time=0,00001;
QueryPerformanceFrequency(freq);
QueryPerformanceCounter(stcount);
ticks:=round(freq*time)+stcount;
repeat
QueryPerformanceCounter(endcount);
until (endcount>ticks);

Все! Вот нужная Вам задержка. Если этой программе повышать приоритет в Винде до "реального времени", весь ПК зависнет наглухо :0), но прога будет работать.
Режим LPT надо использовать EPP, он проще всего реализуется, при этом из проги можно читать сразу 4 байта подряд (берете и читаете 32-разрядный Integer) для ускорения, можно скидывать все это в файл, но проще - в собственный программный массив огромных размеров (если надо динамический - делайте), а потом - в файл. DMA тут вовсе не при чем. Все вкусно и просто. А еще Вам надо бы прочитать М.Гука "Аппаратные интерфейсы ПК" в части, касающейся LPT, тогда будете совсем "гуру" по этому вопросу.
Пока в качестве "гуру" могу побыть я.

использовать счетчик тиков нет смысла, т.к. с его помощью невозможно обеспечить гарантированную периодичность на уровне 10 микросекунд! это я вам заявляю со всей ответственностью: часть интервалов будет близкой к 10 vrc? но периодически будут промежутки до 20, 50 и даже 100 микросекунд - это 100%!!! возможно на каком-нибудь многоядерном пне будет иначе, но на обычном только так. это проверено не один раз.

упомянутый счетчик делается программно - как вы думаете, на его инкремент надо как-то прервать остальные задачи? а то, что при наивысшем приоритете для потока курсор мышки продолжает шевелиться, USB-порты продолжают опрашиваться, системная шина обсуживаться, интернет не отключается и ядро системы продолжает крутиться с тем же приоритетом - вас не смущает? 10 микросекунд - слишком мало для ПРОГРАММНОЙ реализации задержки...

Тут наверное надо свой драйвер порта писать.
А строб данных наверное надо не отправлять от ЛПТ порта компа,
а принимать компом от подключаемого девайса. Кажется так быстрее будет в ECP режиме.
ECP режим имеет буфер FIFO для приёма\передачи данных и допускает работу в DMA режиме + аппаратное ускорение.
Вот Теория работы порта в разных режимах От туда уже можно плясать по поводу программирования порта и организации обмена данными.

свой драйвер писать смысла нет - это из пушки по воробьям. а что строб посылать должно устройство - я писал в своем первом посте. драйвер винды и так должен блоком считать - а DMA там или что-то иное будет - все равно

Ну в принципе тоже верно, просто виндосовский драйвер больше подточен под принтерные протоколы и возможно, что мозгоёпПки будет немало. Тут скорее надо бы изучить функции WinAPI по этим портам (поискать документацию). А там уже включить логику и соответственно написать программу. Тут просто такая хрень, что простым прямым доступом к порту не подступишься к аппаратным возможностям порта, тем более к режиму ECP и тем более в NT системах. Тут API в помощь. Проще будет.

«не так, всё не так»™
Не так задан вопрос. Надо озвучивать не трудности на вбранном пути, а цель. Тогдамогут другой путь подсказать. Правильно задать так:

Не тот выбран метод. Надо взять FT245 или FT232 с буквами BM или R, включить асинхроный бит-банг, настроив его на нужную частоту (период до 1мкс возможен, но стабильнее будет, если больше 2-3мкс) и только успевать выгребать.
У 245-ых ещё можно в режиме FIFO, как-то так

Да, FT232BM или FT232R несколько дороже, чем ничего, но зато будет работать.

Не верите ARV. поверьте мне — под вытесняющей операционкой при работе с LPT более-менее просто решаются только вещи «не быстрее чем, а медленнее - не страшно».
Да, можно взять режим EPP/ECP, ввести снаружи задержку между стробом и квитированием такую, чтобы вышло 10мкс периода при пакетном вводе, попытаться достучаться сквозь win до DMA или через DLportIO сделать read block (inpout32 имеет только одиночные обращения, а без REP INSB равномерности не будет, да и с ними не факт, что будет всегда).
А с FTDI-кой по крайней мере всё через готовые драйвера будет.

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

Если цель — что-то отлаживать или мерять таким «анализатором», то LPT-шный и FTDI-ный пути по сравнению с «купить всё готовое» приблизительно одинаковы по «нитересности», «себестоимости», но FTDI-ный даст результат лучше и быстрее. Причм «железка» может и для другого пригодиться и «кап. вложения» в освоение как-то более «окупаемы», чем в LPT.

Ну а если «ввести со стабильным темпом 10мкс/байт через LPT» — самоцель, то тогда да, флаг в руки, ветер в спину, решать интересную задачу.

Кхм. Оно не просто несколько дороже, чем ничего. Оно в 2 раза дороже, чем вся задача, от которой ввод в ПК с частотой 10 мкс есть всего лишь восьмая часть. Повесить на тот же LPT внешний микроконтроллер было моей первой мыслью, но было отброшено, так как излишне сложно в рамках задачи. К тому же, это ВОЗМОЖНО реализовать с помощью LPT. Это реализовывается уже с помощью LPT и мне только нужно узнать, как сделать это высокоуровневым методом.

Под LINUX на asme для обычных PC с наивысшим приоритетом по LPT 2-4 мкс плавает - это когда систему поставить на колени - ьи то время плавает . Вообще нормальные приложения быстрее чем 50 KHZ с LPT не работают.

В промышленных материнках другая архитектура - порты ввода вывода - прямое отображение в физическую

память - на асме можно обращаться как к порту так и ячейке памяти - тут уже и с мегагерцами можно работать

Но с синхронизацией времени приходится туговато.

Если не требуется красивый интерфейс, межплатформенная переносимость и многопоточность, то успешно работать с портами можно и из DOS программ, написанных на чём угодно.
У меня, к примеру, очень много АЦП, измерительных приборов и оборудования, которые прекрасно согласуются с LPT и не требуют сложных алгоритмов управления. В этих случаях мне показалось эффективным писать программы на Turbo или на TMT Паскале под DOS. Более того, эти программы прекрасно работают и в Windows 2000/XP в её виртуальной машине NTVDM. Для прямого доступа к портам, которые не эмулируются NTVDM, использую AllowIo.exe с драйвером porttalk.sys.
Вот пример работы моей небольшой паскалевской программы-скоростемера операций ввода-вывода. Запускается она через пакетный файл в котором прописана, как аргумент для AllowIo.exe с указанием адреса тестируемого порта. Для отсчёта временных интервалов используется даже не TSC, а второй канал таймера i8254, который обычно отвечает за спикер. NTVDM прозрачно обрабатывает программирование этого канала, пуск, а также защёлкивание счётчика и регистра статуса. Дискретность отсчёта 0,8 мкс, диапазон 0,11 сек.



Из скриншота можно сделать вывод, что среднее время однобайтного чтения - порядка 1 мкс, а дисперсия блочного обмена невелика. Но даже в однозадачной DOS гарантировать синхронность чтения порта можно лишь с определённой погрешностью, связанной с обработчиками прерываний таймера, клавиатуры, SMI и др.

Именно, что требуется. Только не межплатформенная, а межОСевая.
Ну, у меня, конечно, хватит железа, чтобы на одной машине запустить ДОС с замером, обсчётом и логгированием 8 каналов, а на другой отображение и логгирование остальных датчиков, но как-то это не оптимально выглядит.

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