Parallel port direct i/o?

Hi,


is it possible to program the parallel port with system-supplied drivers?
The DDK help says something like "raw access to ports", but it seems it is
only for controlling printers. I need to program the port directly, i.e.
setting and releasing port lines. At the moment, I'm using this "user-mode-
security-hack-driver" and inb/outb calls. Do I have to do these inb/outb
calls in kernel mode to have a reliable communication without scheduler-
interrupts? I'm doing time-critical communication over the port but the
scheduler switches in stages where it mustn't.
Are kernel drivers "safe" from unwanted scheduler switches or would it also
don't work?


Thanks for your help.

Thomas

Maxim
Mon Nov 17 18:09:17 CST 2003

> Are kernel drivers "safe" from unwanted scheduler switches or would it also

If you're on DISPATCH_LEVEL - then yes.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Kirk
Wed Nov 19 02:49:17 CST 2003

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eeZBDwWrDHA.1084@tk2msftngp13.phx.gbl...
> > Are kernel drivers "safe" from unwanted scheduler switches or would it
also
>
> If you're on DISPATCH_LEVEL - then yes.

But not "safe" from other interrupts. Time-critical sounds troublesome.

-Kirk

Thomas
Wed Nov 19 09:50:18 CST 2003

> But not "safe" from other interrupts. Time-critical sounds troublesome.

It works under Linux which is also a multitasking OS. I'm trying to write a
CBM serial bus device driver - the bus protocol is somehow picky about
timing... I managed to write a half-working application with real-time
priority sets, but the scheduler switches from my task where the transfer
should happen - as the protocol has practically no handshaking, data is
lost. So I'm looking into writing a driver which handles byte transfers...


Thomas

Don
Wed Nov 19 10:00:23 CST 2003

Tell us your timing contraints and then we can determine if this is doable.
The Linux scheduler was designed for a totally different model of computing
so do try to compare this to Windows. Also let us know if this is for a
lab, or a commercial product or what? There are tricks that are fine for a
lab environment, that no one should use in a product going to customers.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Thomas Müller" <eous@NOSPAMgmx.net> wrote in message
news:Xns9438AB4B28804eous@207.46.248.16...
> > But not "safe" from other interrupts. Time-critical sounds troublesome.
>
> It works under Linux which is also a multitasking OS. I'm trying to write
a
> CBM serial bus device driver - the bus protocol is somehow picky about
> timing... I managed to write a half-working application with real-time
> priority sets, but the scheduler switches from my task where the transfer
> should happen - as the protocol has practically no handshaking, data is
> lost. So I'm looking into writing a driver which handles byte transfers...
>
>
> Thomas

Thomas
Wed Nov 19 10:30:05 CST 2003

Have a look at
http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/Chap
ter_6/page_364.html and
http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/Chap
ter_6/page_365.html

Most timing is in microseconds so exact timing seems to be necessary.
Another question is if it is possible to use any Windows-supplied interface
for controlling the parport or if I'm on a too low h/w level (atm I'm using
inb/outb with the "security-hack-driver" WinIO). I don't know if Windows
has some kind of interface if it comes to controlling single parport lines.

I think it will be either an open-source project or a closed-source
freeware one. No commercial intentions.


Thomas

Don
Wed Nov 19 10:41:35 CST 2003

I don't see a solution for you Windows has millisecond resolution when it
comes to timing, and you are faced with the problem even then that
interrupts and similar things can push this up alot. One of the first
drivers I worked on had a time that went off every 40 milliseconds, that
actual timing was typically in the range of 42-55 milliseconds.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Thomas Müller" <eous@NOSPAMgmx.net> wrote in message
news:Xns9438B20A9A480eous@207.46.248.16...
> Have a look at
>
http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/Chap
> ter_6/page_364.html and
>
http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/Chap
> ter_6/page_365.html
>
> Most timing is in microseconds so exact timing seems to be necessary.
> Another question is if it is possible to use any Windows-supplied
interface
> for controlling the parport or if I'm on a too low h/w level (atm I'm
using
> inb/outb with the "security-hack-driver" WinIO). I don't know if Windows
> has some kind of interface if it comes to controlling single parport
lines.
>
> I think it will be either an open-source project or a closed-source
> freeware one. No commercial intentions.
>
>
> Thomas

Thomas
Wed Nov 19 11:23:48 CST 2003

Timing is done till now with two QueryPerformanceCounters. It works quite
well, there are some inaccuracies in the 1/10 us... seems to be good
enough. cbm4linux suppresses following interrupts by using cli(), don't
know if this is possible/good on Windows...


Thomas

Maxim
Wed Nov 19 12:36:27 CST 2003

What is the "millisecond timing" you want? The time between the bytes in a
packet? This is OK, the standard serial driver will handle it, just set the
baud rate correctly.

Or must you send an reply or ACK in milliseconds? If yes - this is really a
huge PITA. Frankly speaking, this says about the protocol being poorly
designed.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


"Thomas Müller" <eous@NOSPAMgmx.net> wrote in message
news:Xns9438BB2583189eous@207.46.248.16...
> Timing is done till now with two QueryPerformanceCounters. It works quite
> well, there are some inaccuracies in the 1/10 us... seems to be good
> enough. cbm4linux suppresses following interrupts by using cli(), don't
> know if this is possible/good on Windows...
>
>
> Thomas

Thomas
Thu Nov 20 09:53:41 CST 2003

> What is the "millisecond timing" you want? The time between the
> bytes in a
> packet? This is OK, the standard serial driver will handle it, just
> set the baud rate correctly.

Timing is no problem. My huge problem is that the Windows scheduler
switches away from my task while the transfer is running - the protocol has
no real handshaking so the bytes sent from devices attached to the PC are
lost. I was told I have to write a driver to suppress scheduler switches.
Just setting the app's priority level to REALTIME did not really make it
better.
Don't mix up serial port driver and serial bus. The bus cable is attached
to the parallel port.

> Or must you send an reply or ACK in milliseconds? If yes - this is
> really a
> huge PITA. Frankly speaking, this says about the protocol being poorly
> designed.

Btw, it's MICROsecond-timing, that's 1/1000 of a millisecond...
About the protocol: Yeah, it's sad that Commodore dropped the GPIB in favor
of the slow serial bus... GPIB has real handshaking and 8 bits are sent in
parallel.


Thomas

Thomas
Thu Nov 20 10:27:10 CST 2003

> Btw, it's MICROsecond-timing, that's 1/1000 of a millisecond...

Oops, just 1/10... :)


Thomas