Переключаться программно между ECP/EPP.

← →
Ш-К (2002-08-23 15:23) [0]

Есть внешнее устройство, которое работает в режиме EPP. На старом компьютере в биосе выставляется режим: ECP/EPP (не ECP, и не EPP, а именно вместе: ECP/EPP). Windows, соответсвенно, в таком случае считает текущий режим как ECP. Устройство работать не может.
Как выставить EPP, чтобы можно было работать с устройством просто через CreateFile?

← →
jonik pegas (2002-08-23 15:52) [1]

Читай спецификацию ECP-там описано. Ищи книжку М.Гук "Интерфейсы ПК"-тоже этот момент рассматривается.
P.SИли жди ответа до понедельника, когда я сам доберусь до книжки и до инета;).
P.P.S А что мешает выставить в биосе только epp(или не позволяет?)
P.P.P.S. EPP бывает двух видов EPP 1.7 и EPP 1.9 совместимых сверху вниз

← →
Ш-К (2002-08-23 16:27) [2]

У меня тоже нет под рукой Гука, но я помню: то, что он предлагает не реализовать под NT. По крайней мере без левых драйверов (к томуже сомнительных).
А я хочу просто, без всяких ухищрений, работать с портом через WriteFile/ReadFile.

Трабл в том, что ЕРР в биосе не выставляется. Например, на машине главного инженера. И он сетует на то, что программа должна учитывать такие заморочки. А это, боюсь, придётся реализовывать от руки.

Да, ещё что. Можно ли считать мамы без чистого ЕРР морально устаревшими. Или это в порядке вещей.

← →
stx (2002-08-23 19:14) [3]

Procedure Set_ECR_PS2; assembler;
// Установка двунаправленного режима PS2
asm
push eax
push edx
mov dx, Lpt1
add dx, 402h
in al, dx
and al, 00011111b
or al, 00100000b
out dx, al
in al, dx
pop edx
pop eax
end;

Procedure Set_ECR_ECP; assembler;
// Установка режима ECP
asm
push eax
push edx
mov dx, Lpt1
add dx, 402h
in al, dx
and al, 00011111b
or al, 01100000b
out dx, al
in al, dx
pop edx
pop eax
end;

недавно обсуждали компоненты которые позволяют работать с портом через драйвер, причем выглядит так же просто WritePortByte(aByte); ReadPortByte(aByte); а компонент TvicHW я хочу сказать совсем не сомнительный, во всяком случае у меня все было как по маслу

← →
Неотеничный Педоморф (2002-08-23 19:15) [4]

Режим ECP или EPP выставляется запросом IOCTL_INTERNAL_PARALLEL_SET_CHIP_MODE к драйверу ПП parport.sys или аналогу.
Читайте Windows DDK

← →
Ш-К (2002-08-23 21:31) [5]

stx (23.08.02 19:14)
А работает это чудо под NT? И чё такое здесь Lpt1?
TvicHW платный. Руководство, может, и не пойдёт на его преобретение. Во всяком случае, мог бы ты сказать с какой скоростью передаются данные в двустороннем режиме через TvicHW.

Неотеничный Педоморф (23.08.02 19:15)
Т.е. обязательно спускаться до уровня драйверов?
Представь, работала себе программа с Lpt через WriteFile/ReadFile. И тут те нате: выясняется, что на некоторых материнках режим ЕРР в чистом виде не выставляется. Так что теперь поддерживать эти мамки, через введения разного рода геморойных конструкций.

И что это за мамки такие? Устаревшие, экзотичные, суперсовременные, каменныйвек, спаянныеподзаказ, занимающие50%рынка... Нигде инфу найти не могу. Посоветуйте хоть форум на котором можно узнать ответ.

А что касается драйверов типа parport.sys, так я пробовал считать через него 1кб.
Что-то типа:

for i:=0 to 1023 do ReadPort()

Так вот, этот драйвер считывал порт быстрее работы внешнего устройства. Все байты были одинаковые. :(

← →
Неотеничный Педоморф (2002-08-23 23:51) [6]

А какая нужна скорость передачи, т.е. средняя и пиковая?

Какие вообще требования к каналу обмена с вашим устройством?

← →
Ш-К (2002-08-24 01:11) [7]

Неотеничный Педоморф (23.08.02 23:51)
Не знаю, что подразумевается под требованием к каналу. Устройство поддерживает ЕРР, в смысле сигналов на ножках (взяли Гука и спояли также). Соответственно и лпт должен быть в ЕРР.
Минимальная требуемая скорость 150кб/с. Хотя, желательно, и 2МБ/с. Врема на переключение чтение/запись может быть любым, в разумных пределах.
Впринципе, из-за больших скоростей и был выбран лпт. (усб и всё альтернативное - в перспективе).

всем. всем. всем.
Подскажите авторитетную инфу, что матери, явно не поддерживающие ЕРР, - отстой. Покажу инженерам.
А то не хочется мучиться все выходные.

← →
Неотеничный Педоморф (2002-08-24 09:40) [8]

>>>Не знаю, что подразумевается под требованием к каналу. >>>Устройство поддерживает ЕРР, в смысле сигналов на ножках
>>>(взяли Гука и спояли также). Соответственно и лпт должен быть в ЕРР.

Это вы поторопились. Хотя, что мешает "допаять" девайс до совместимости с ECP?

>>>Минимальная требуемая скорость 150кб/с. Хотя, желательно, и
>>>2МБ/с. Врема на переключение чтение/запись может быть любым, в разумных пределах.

Эта скорость вполне достижима при управлении портом методом прямого доступа к регистрам. Время чтения/записи в любой регистр порта составляет примерно 800нс и не зависит от типа материнки. Кроме того, при таком способе управления достаточно лишь требования двунаправленности шины данных, а на текущий режим можно наплевать, ибо мы сами будем его устанавливать.

>>>Впринципе, из-за больших скоростей и был выбран лпт. (усб и
>>>всё альтернативное - в перспективе).

No comments. С LPT бы разобраться...

>>>всем. всем. всем.
>>>Подскажите авторитетную инфу, что матери, явно не
>>>поддерживающие ЕРР, - отстой. Покажу инженерам.
>>>А то не хочется мучиться все выходные.

:o) Нетехническое решение технической проблемы.

← →
Ш-К (2002-08-24 17:07) [9]

> Эта скорость вполне достижима при управлении портом методом
> прямого доступа к регистрам. Время чтения/записи в любой
> регистр порта составляет примерно 800нс и не зависит от
> типа материнки. Кроме того, при таком способе управления
> достаточно лишь требования двунаправленности шины данных,
> а на текущий режим можно наплевать, ибо мы сами будем его
> устанавливать.

А как такое делается под NT?
Нигде ничего подобного не нашёл. Только дрова, чтоб раз в секунду байт выставить.

← →
Неотеничный Педоморф (2002-08-24 17:50) [10]

>>>А как такое делается под NT?
>>>Нигде ничего подобного не нашёл. Только дрова, чтоб раз в секунду байт выставить.

На платформах семейства NT обращения к портам осуществляются ф-ями READ_PORT_UCHAR() и WRITE_PORT_UCHAR().
Эти две ф-и предоставляются библиотекой HAL.DLL.
Но использовать эти функции напрямую из приложений в кольце защиты ring 3 не получится, т.к. это противоречит принципам архитектуры Windows NT. (Попробуйте LoadLibrary() на HAL.DLL!)
Поэтому обычно используют некую прослойку - (страшное слово!) драйвер.
Иных путей нет.

Пользовательское приложение передаёт драйверу данные (напр., адрес регистра порта) через ф-ю WinAPI DeviceIOControl(), драйвер выполняет обращение к WRITE_PORT_UCHAR/READ_PORT_UCHAR и возвращает данные (при чтении) приложению.

Вот такой механизм.

Что касается "раз в секунду" - это мне непонятно. Почему обязательно раз в секунду? Используйте циклы!

Таких универсальных драйверов создано великое множество. Они очень просты в использовании.
Максимум дополнительных действий - один раз перезагрузить комп после установки (на платформах Windows 9X).

← →
Ш-К (2002-08-24 22:16) [11]

> Что касается "раз в секунду" - это мне непонятно. Почему
> обязательно раз в секунду? Используйте циклы!

Тогда объясните такую вещь.
Windows 2000. Допустим я взял драйвер (один из тех, что по 1024 раза предлагались на этом форуме для решения идентичной проблемы; и название которого есть во всех факах).
Как через такой драйвер мне передать несколько байт на внешнее устройство? В каких циклах?
Как через такой драйвер я могу узнавать состояния регистров, о том что байт принят - выставите следующий?
Все примеры с чтением регистров я могу реализовать только через большие тормоза. Пример:

for i:= 0 to 1023 do begin WriteToLpt(bufer[i]); {через драйвер пихает байт в порт} {А далее, чтобы продолжить цикл, мне надо узнать, о том что байт внешним устройством принят, т.е. прочитать состояние регистра. Для этого и следующая функция:} SleepWhileNotReply; {Т.е. ждём, пока состояние регистра не изменится на нужное.} end;

Я несколько преувеличивал, когда говорил "раз в секунду". На самом деле 1000 раз/с (получается меньше килобайта в сек.) Это максимум, что я выжал. Вот процедура SleepWhileNotReply:

begin While not ReadRegistrState(PinNunber) do Sleep(1); end;

Если вместо Sleep(1) писать Sleep(0), или x:=x, или ничего не писать, вообще тормоза.

Как реализовать процедуру SleepWhileNotReply, чтоб без тормозов?

P.S. Может я в чём заблуждаюсь, и подход не верный изначально? Очень, очень хочу ошибиться.

← →
Неотеничный Педоморф (2002-08-24 23:37) [12]

Теперь более-менее понятно.

>>>Допустим я взял драйвер... Как через такой драйвер мне передать несколько байт на внешнее устройство?
Нужно реализовать программно специфический протокол передачи данных, на который рассчитано ваше устройство.
Практически это делается так: берётся описание девайса, + описание внешних линий порта,
далее "на бумажке" расписываем, как линии будут менять своё состояние в циклах чтения и записи.
Затем перерисовываем всё это в красивый алгоритм, уже в терминах не линий, а регистров порта.
Потом реализуем в виде процедур на Delphi, естественно, с адаптацией под использованный компонент для доступа к портам.
Вы сами это пишете.
Напр., вы можете забить весь протокол в 2 ф-и: WriteByte(<Номер регистра устройства>,<Данные>) и ReadByte(<Номер регистра

устр-ва>). (При условии, что девайс спроектирован грамотно).

>>>Как через такой драйвер я могу узнавать состояния регистров, о том что байт принят - выставите следующий?
Универсальные драйверы предназначены только для управления регистрами порта LPT, внутри компутера.
Т.е, вы можете, к примеру, управлять портом LPT1 через регистры ПК с адресами $3BC, $3BD и $3BE.
Драйверы не знают, да и не должны знать, что к порту подключён девайс. На то они и универсальные.
Через управление регистрами порта реализуется протокол обмена, см. пред. пункт.
Другое дело, те регистры, что находятся в девайсе -- т.н. вторичные регистры.
Какие-то из них предназначены для назначения режима устр-ва (на запись), какие-то содержат статусную информацию (на чтен

ие). Наверно, надеюсь, такие регистры предусмотрены в вашем устройстве?
Чтобы узнать, готов/не готов, надо их опрашивать и анализировать прочитанное значение.

>>>примеры с чтением регистров я могу реализовать только через большие тормоза... 1000 раз/с... Sleep()...
Это проблема с опросом.
В любом случае, вы не сможете опрашивать устройство чаще, чем 1000 раз в секунду. Ограничение это накладывается самой ОС,

точнее, той аппаратурой, на которой Windows работает. Дело в том, что 1кГц -- это частота прерываний от часов реального

времени. И на эту частоту завязана работа планировщика задач ядра ОС.
Не надо использовать Sleep().
Попробуйте timeSetEvent() с базовым приоритетом процесса REALTIME_PRIORITY_CLASS. Даёт более стабильный результат.

Теперь посчитаем.
Если вам нужна средняя скорость передачи данных, скажем, 200Кб/сек,
и вы можете опрашивать порт не чаще 1000 раз в секунду, то
для достижения треб. скорости вы должны передавать данные
БЛОКАМИ по 200*1024/1000 = 205 байт. Не менее.

И всё время от опроса до опроса девайс должен хранить/накапливать данные во ВНУТРЕННЕМ БУФЕРЕ.

Теперь проверьте, есть ли в вашем устройстве буфер. Наверняка нет!

Вот мы и свели задачу к аппаратной проблеме.
А аппаратная проблема не есть проблема программиста!!! (шутка, извините)

Просто надо уяснить одну вещь -- и девайс, и ПО под него должны разрабатываться в одном цикле.
ВМЕСТЕ -- программист и электронщик.
Иначе разброд, флуд и вообще кранты...

//

← →
Ш-К (2002-08-25 01:18) [13]

Я, конечно, попытаюсь разобраться, что здесь написано. Но я не понимаю более тривиальных вещей:

>И всё время от опроса до опроса девайс должен
>хранить/накапливать данные во ВНУТРЕННЕМ БУФЕРЕ.

Но, чтоб попасть в буфер, данные сначала должны передаваться. И согласно какому-то протоколу. И помещаться в буфер они не смогут медленнее, чем их будет слать компьютер. И компьютер не имеет право слать данные быстрее, чем их может "брать" устройство. Именно о передаче я и веду речь. Без разницы: накапливаются данные или нет.

Устройство принимает данные. Чно оно с ними делает (буферезует, выкидывает) - не важно. Главное, что оно может:
1) считать байт;
2) выставить на ножку (пин, штырёк) состояние (0/1 бит, 5V) о готовности принять следующий, согласно протоколу ЕРР.
3) ждать, когда на другой ножке появится бит - считывайте новый.
Goto 1.
Соответственно, и программа должна делать тоже самое только наоборот.
В программе я делаю такую вещь:
Выставляю байт (WriteByte).
Выставить следующий байт на компьютере я не могу (просто не имею права) выставлять (заменять на новый) пока устройством не считан текущий. Считанным он будет, когда устройство его считает и выполнит пункт 2.
Так вот, чтобы узнать о том, считан ли байт, мне нужно опросить состояние штырька. ... Не чаще 1000 раз/с. :(

Подвожу итог. Я не могу быстро переслать несколько байт без задержек, а вы мне отвечаете приблизительно следующее: "Если нельзя переслать 200 байт, то можно переслать блоком в 200 байт". Для меня это одно и тоже.

Мы говорим о каких-то разных вещах. По крайней мере я понимаю, чтобы байту попасть в устройство (или буфер устройства), он должен быть корректно считан устройством один раз. И компьютер должен его корректно выставить один раз. Но не понимаю, как добиваются скоростей.

← →
Неотеничный Педоморф (2002-08-25 03:43) [14]

>>>Мы говорим о каких-то разных вещах
Да, возможно.

>>>Я не могу быстро переслать несколько байт без задержек
Если вы всё же используете протокол EPP, то в нём определено следующее:
Вывод/ввод байта производится с синхронизацией шины компьютера, т.е. в рамках одного цикла шины.
Устройство само выставляет флаг готовности, после чего цикл завершается. Готовность устройства проверяется аппаратно.
Так же предусмотрен тайм-аут -- ок. 30мкс (надо уточнить).

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

Цикл по элементам массива
begin
Выбрать байт и записать его в регистр данных EPP
end;

Скорость приёма определяется устройством.
Ничего опрашивать на порте LPT не надо.
Если действительно используется EPP.

← →
Ш-К (2002-08-25 04:56) [15]

Я так и предполагал, что недопонимаю каких-то азов. То что ЕРР реализован аппаратно я не знал. Полагал, что этот протокол реализуется программно в среде Windows.

Но я несколько ушёл в сторону. Имеется среда из семейства NT. Матерь не поддерживает ЕРР (в биосе выставляется ЕРР/ЕСР, а фактически становится ЕСР). Как на такой машине релизовать работу устройства по протоколу ЕРР? Я так и не выяснил.

Если можно реализовать через драйвера привелигерованного режима, то только теряя время переключаясь на режим опроса лпт. (Менее 1 кб/сек).
А по другому как?

P.S. И что это за тайм-аут в 30мс? Надеюсь это для внутренностей цикла, а не разница между посылками байта.
P.S.S. Если в простом цикле направить на порт несколько байт, то программа при отсутсвии внешнего устройства должна зависнуть после первого байта; по идее. Ведь байт некому считать. На практике - все посылки "проскальзывают", и цикл нормально выполняется. И тогда какие гарантии, что с
девайсом "проскальзываний" не будет?

← →
Неотеничный Педоморф (2002-08-25 12:36) [16]

Лучше я дам вам ссылочки, где достаточно подробно описана работа порта:

http://chipnews.com.ua/html.cgi/arhiv/00_07/stat_58.htm

http://gogame.narod.ru/misc/centronics/centronics.html
или
http://rtfm.vn.ua/hw/man/ieee_1284/ieee_1284.htm

Теперь о режиме ECP или EPP. Подавляющее большинство чипсетов (Intel,VIA) поддерживает EPP.
Так что если в BIOS есть опция выбора EPP/ECP, то чипсет точно поддерживает EPP.
Изменить опцию BIOS программно невозможно, так что режим EPP придётся устанавливать вручную.
Если эта опция не выбрана, BIOS может блокировать регистры EPP-расширений порта и обмен по протоколу EPP станет невозмож

ен.

Но даже если в BIOS указан EPP, стандартные драйверы всё равно могут работать в режиме ECP, и это нормально, просто прог

раммеры перестраховались (протокол ECP реализуется программно и на SPP совместимом порте, и не для всех плат система зна

ет, что порт умеет обмениваться по EPP).

Так что, если в BIOS указан режим EPP, то необязательно обмен будет вестись по протоколу EPP.

Дальше 2 возможности:
1) Установить драйвер для порта EPP (ECP-драйвер прекрасно себя чувствует и на EPP порте. Но :ненадёжный вариант)
2) Прямое управление портом через его регистры.

По поводу п.2):
Вы можете протестировать материнки след. образом:
--Настройте режим порта в BIOS -- EPP
--Напишите программу которая будет выводить, к примеру, один байт (по таймеру, например) в порт, ну, скажем, ($378+3) -

регистр адреса EPP.
--Посмотрите осциллографом состояние линии #1 (strobe)
Если всё получилось, при запуске программы там должны наблюдаться короткие отрицательные импульсы.

//

Если "мать" глухо не поддерживает EPP, но порт является двунаправленным, то протокол, аналогичный EPP можно сэмулировать

на трёх стандартных регистрах параллельного порта. Программно. Это не проблема.
Опрос готовности (завершения текущего цикла обмена) можно проводить не через Sleep, а в простом цикле, с ограничением по

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

//

Тайм-аут 10мкс (не 30мкс, я ошибся) -- это макс. время, на которое задерживается шина при отработке цикла ввода или выво

да черезрегистр EPP. Если за 10мкс устройство не ответило, цикл завершается автоматически.

Вот, в принципе, поэтому программа-то и не виснет при отсутствии устройства.

//

← →
jonik pegas (2002-08-26 08:08) [17]

Переключение в режим EPP из ECP-установка битов 7:5 регистра управления ECP порта (port+400h) в 100-этот режим не входит в спецификацию Microsoft но трактуется как EPP контроллером SMC FDC37C665/666 и многими другими.
EPP позволяет работать не байтами а словами и двойными словами (16 и 32 бит)-т.е за одну операцию ввода/вывода выводится 4 байта-это к вопросу о скорости.

← →
stx (2002-08-26 18:43) [18]

не знаю как у Вас у меня по опросу получалось 2мб/с, через DMA работал с 2 мбайтами, правда на предельных скоростях пришлось сделать небольшой буфер в устройстве

Переключаться программно между ECP/EPP. Найти похожие ветки