Alan,
I think u can enclose your timing-dependent protocol code within CLI
and STI.
Ex: While opening the device you would want to do some hand saking with
the hardware device, then in your open driver call function you have the
CLI at the beginning and STI at the end.
mydriverOpen(…) {
CLI;
/* you handshake code */
STI;
}
But this is will have side-effects on your system time.
Cheers
Kiran
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@3Dlabs.com
Sent: Friday, June 11, 2004 3:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] how to program I/O
Alan,
What are you trying to achieve and exactly what sort of timing
requirements do you have?
Obviously, what Walter writes in the book is true, but to a certain
extent, you can actually get fairly good timing within Windows, as long
as you can live with the fact that it’s never going to be extremely
precise.
As someone else mentioned, if you have STRICT real-time requirements,
the hardware isn’t going to work well in a Windows environment (or any
other environment where task scheduling isn’t based on strict priorities
where tasks/processes/threads of the same priority are allowed to be
scheduled in, so Linux, Unix, OS/2, OS X, VMS etc, are also out of the
question).
The really best solutin to this is to have a dedicated processor work on
the side of your Windows processor (such as a small microcontroller
fitted to the hardware you’re trying to control). Or, of course, build
more “intelligence” into the hardware itself, so that it’s more
autonomous and can handle the fact that it’s not being told exactly what
to do at every single moment in time, but can “behave itself if left
ignored”.
One of the things that Paul didn’t mention is SMI (System management
interrupt). This is an interrupt that has higher priority than NMI, and
goes completely outside the existing interrupt system in as much as it
hasn’t got a vector in the normal sense, and it’s very
“self-controlled”. It also has the “feature” that it goes into a special
mode of the processor, after saving everything all registers in memory.
All of this makes SMI almost impossible to predict. Also, there is not a
common place for SMI to be turned off, because it’s part of the chipset
features, and each chipset manufacturer will have their own
implementation of SMI handling. Also, it may not be a good idea to turn
of SMI anyways, because it’s often used to cover over chipset bugs or
“strange hardware quirks”. For instance, SMI is often used to reroute a
particular I/O port to a different address, so that something that is
non-standard hardware can appear to be standard.
SMI’s can take several microseconds (or in some cases MANY
microseconds). Aside from that, you also have to contend with chipset
features that block PCI access for a few hundred microseconds, and this
can happen without your control either, such as for instance a DMA
access from a hard disk may cause the chipset to “block PCI access” for
a significant period (this is of course not how things SHOULD be
designed, but it does happen that chipsets have these type of
“misfeatures”).
So if you expect this to work in any reasonable PC, you’re probably
going to have to think about how to fix the hardware.
Oh, and your question about “How does this affect the performance?” is a
bit like “How long is a piece of string?”. It probably can be answered
by the answer about “What are you trying to achieve … ?”, but of
course, you’re going to affect the performance of the system if you’re
spending several milliseconds looping around and creating “precise
timing” for some I/O device.
–
Mats
-----Original Message-----
From: Alan Kung [mailto:xxxxx@xgitech.com]
Sent: Friday, June 11, 2004 3:10 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] how to program I/O
Hi every 1:
I am a novice in NT driver writing, I am studying the programming
windows driver model.
In the book of Walter Oney:
Chapter 4 Synchronization
He say
The operating system can preempt any subroutine at any moment for an
arbitrarily long period of time, …
if so, when the H/W programming is not interrupt driven, and it must
follow some H/W communication protocol,
How to do the I/O programming
that can follow H/W handshake timing protocol ? (If the I/O routine is
doing H/W I/O handshake ,and O.S. preempty the I/O routine for a time)
Best Regards,
Alan
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
