Re: Explain this about threads


"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
news:OBigqVu$HHA.5424@xxxxxxxxxxxxxxxxxxxxxxx
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> wrote in message
news:4NSJi.619$hI7.63@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
news:enEOBWq$HHA.4836@xxxxxxxxxxxxxxxxxxxxxxx
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> wrote in message
news:rQFJi.10536$924.7023@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I can also use the interrupt to get information on a regular basis
but not sure how well this will work.

I was thinking that maybe I could use an interrupt and then an
external clock that will trigger the interrupt very precisely and
that would probably give me a pretty accurate method but it would
probably starve the system because of all the task switching per
clock. I guess I have no choice but to either use something like dos
or some hardware proxy that can deal with the latency issues.




SPP uses the status lines (Ack, Busy ... signals) to control the data
flow between device and controller, the driver has to read the status
of the Ack signal after each byte transferred in order to control the
signaling rate.
Writing your own driver won't help you any further as long as you
don't use the handshaking protocol as defined in 1284 at the device
driver level. Sure you can move the SpinWait loop at the driver level,
but this is no different as doing this at the user level, you are
burning CPU cycles without any more guarantees that you wont loosing
bytes because the device is not ready to accept any more data. I would
keep these things in user space anyway, it's simply a matter of trying
to find the optimal value for the spin counter.


SPP doesn't use those lines at the hardware level(AFAIK). They are
software. For programming a PIC MCU(or even other MCU's) that protocol
is not needed but there is a similar protocol that can be implemented
for the parallel port. Essentially you enable one pin, disable another,
then send bits out on another pin. Its not complicated at all. Even
the timing isn't complicated except if its to fast then it does no
good. To slow isn't good though and thats really the main issue here.
If I could sleep for microseconds then this thread would have probably
never been started. (assuming the performance hit for all that task
switching is irrelevant)

The reason I want to move most of the lower level stuff to a kernel
mode driver is that it should speed up the communications over all and
this means actually less spin waiting because I can send the
information faster(assuming I don't end up being limited to 10khz or
something liek that). Also all the task switching between the user mode
app and the kernel mode driver at the bit level seems like a waste of
cycles. (Now if I end up having to "consume" those in the spinwait in
the kernel then it doesn't matter)

I'll just have to do some tests and see which works the best. It maybe
turn out that the kernel mode offers no real benefit over doing it in
user mode.

Thanks,
Jon



Please tell me what kind of parallel port driver do you use here? With
driver I mean the bus drive that is the lowest drive in the stack, and
also what OS you are running this on.
If you are running on W2K or higher, by default you are using the System
supplied parallel port *bus driver*, this driver knows several modes
from which the Compatible (Centronix) mode is selected by default, other
modes need to be selected by the upper filter driver. In this simple
mode, the "busy" signal is the handshake line used to indicate that the
device is ready to accept data from the parallel port host.
In it's most simple mode (compatibility) , the protocol works like this:
- the busy signal is checked by the PIC before he sets data on the data
out lines , the bus driver code needs to read the status register in
order to signal time-out whenever the busy condition persist for to
long.
- if the device is not busy, the PIC sets the data on the data lines and
toggles the strobe line (done by the PIC)
- the device signals the acceptation of the data by toggling the Ack
line and eventually the busy line.
Now if the device doesn't toggle the busy line (which I can't believe),
then you are in trouble, as you can never know when the device is ready
to accept any data, and there is nothing you can do about this, delaying
data output is just a hack, you are never certain that the device is
ready. You should definitely look for a better solution, really.


No, I do know because I can define my own protocol for which lines do
which. And for programming in ICSP the device is never busy.. hell, its
not even technically on yet... cause your programming it.

I think you do not understand whats going on and think that the parallel
port has to follow a certain protocol. This is not true in SPP mode. You
are at full control of what lines to do. There is really no such thing as
a busy line. Its just a pin on the port that is an open collector. You
can use it for whatever you want if. If you want to communicate using the
"printer protocol" then you'll need it for busy... else you can use it
for sending information(its not so good for receving because it sorta
requires polling).

The driver I'm using is direct port access... there is no bus and no
other drivers. Its exactly the same as if it was done in dos. Check out
InpOut32 for what I'm talking about. Or even PortTalk(which I don't use).

The parallel port in SPP is essentially 8 data lines that are configured
for output but also can be configured for input. 5 status lines that are
configured for input and 5 control lines that are mainly output but since
they are open collector can also be used for input.

The SPP communications protocol is software implemented deifnes what
those pins functions are.... it is not obligatory to use them. In ECP and
EPP modes it is different because much of the protocol is in hardware.

Now I assume the device toggles that busy line, and I also assume that
your driver is a simple filter driver in top of the system supplied
driver (please correct me if I'm wrong), if this filter driver doesn't
provide a means to read the status register (via the
IOCTL_PARIO_READ_PORT_STATUS IOCT command) from the lower bus driver,
then you are in trouble and you are back at square zero.
Every IOCTL_PARIO_WRITE_PORT_DATA can overflow the output FIFO resulting
in loss of data. However, if, the filter driver provides a means to
read the status byte from the bus driver
(IOCTL_PARIO_READ_PORT_STATUS ), then you need to do it before you can
write any data to the device (IOCTL_PARIO_WRITE_PORT_DATA ). You could
do this at the user level, but this requires almost the same wait hack
as you have now, much better is to implement this in the filter driver.
Implementing this is a simple matter of buffering the data from the
client (user space application) and block when the buffer is (nearly)
full. The filter driver can simply transfer the data to the bus driver
in a coordinated and well synchronized sense.


No, your assuming to much. I think your getting SPP mode confused with
the other two which are in the hardware.

http://www.beyondlogic.org/spp/parallel.htm

"Centronics is an early standard for transferring data from a host to the
printer. The majority of printers use this handshake. This handshake is
normally implemented using a Standard Parallel Port under software
control."

Ok, I do not know what "normally" means but on the pc it is in the
software.

What this means is exactly what I said above in that you are in full
control of the "protocol". So I can use my own.

Also there is no filter drivers or anything. I'm in direct control of the
parallel port since I bypass all other drivers. Maybe there is some
virtualization going on, I do not know... but in the driver I can use
either READ_PORT_UCHAR or even just the "In" instruction(which I know
isn't a good method at all but it does work and for my purposes it can be
used since no other devices will be communicating with the port at the
same time...)

Jon



Please don't teach me how I should write device drivers I have done it for
years for the living at Digital Equipment, Compaq and HP., when I'm
talking about SPP mode I know what I'm talking about, it's not any of the
other modes like nibble, byte, EPP, ECP and other..
The SPP protocol is a PROTOCOL mode, it stands for "Standard Parallel
Protocol", also known as "Compatible" "Centronix" or "Standard" mode", you
don't use the SPP mode because 1) your device is NOT conforming (it
doesn't toggle the busy and what else), it's a raw device, and 2) your
driver (InpOut32 ) is not conforming either, it doesn't check the control
and status registers of the PIC, it's a very simple driver, nothing to be
used in a professional application.
That said, your device is used in raw mode, doesn't use any handshaking,
and as result, you have a problem.
One way to solve this is by inserting a delay between each character you
output, but you should do this at the driver level, not at the user level.
That means you should do something like this:


Ok, I guess one your one of those guys "I've been doing it for 1834 years so
shut the *** up".

I'm not going to talk to discuss it any more. if you can't admitt that your
wrong or that you don't know everything about it then no use. Maybe I miss
used the term but all my research as said SPP = standard parallel port and
not protocol. The protocol is centronix. In any case it doesn't matter
because it doesn't have to be used that way as easily be demonstrated. As I
said, one has full control over the parallel port when in "SPP" mode. All
the *** your talking about is not applicable to my problem because I am not
using centronix communications protocol with any type of handshaking.

http://www.beyondlogic.org/spp/parallel.htm

In any case I have better things to do than argue with you with you about
what you think the pc parallel port is and isn't capable of as I know it can
do what I want because I have done it to some degree and I have seen other
applications do it.



.

Loading