Re: Explain this about threads


"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:13fbn0q62evsq9e@xxxxxxxxxxxxxxxxxxxxx
Jon Slaughter wrote:
Because it uses a specific protocol AFAIK so you cannot use any deviced
attached to the port(only those deviced designed to communicate on it).

Have you tried? The basic parallel port driver should be protocol
agnostic, AFAIK. You open it with CreateFile(), and it's just a
read/write stream.

The driver should take care of all the data integrity stuff, while your
application can worry about the application protocol.

I don't know how to do this using managed code, but I think that using
p/invoke to get at the unmanaged API would be a lot easier than the hoops
you're trying to jump through now.



Maybe it does, I haven't tried. I just used the kernel driver because thats
what everyone else doing what I'm doing uses.

In fact the dll that wraps the kernel uses create file to do this... so
essentially it is emulating what your speaking of. I suppose its for
performance reasons why its done that way.

I'm not aware of any non-spin-wait mechanism that will allow you to time
the interval between individual calls to out. The best you can do with
the mechanisms available is to ensure an _average_ data rate and even
there, without some kind of buffering support, you still have the
problem of having to not send data too fast.

huh? How can you ensure an average data rate but not ensure it will not
be to fast? Its very easy to ensure a maximum speed... its impossible to
ensure a mimimum speed.

Ensuring an average data rate is easy. You send some fixed amount of
data, and then you wait an appropriate amount of time. The amount of time
you wait and/or measure may be long, but there will always be an amount of
time you can select that provides an accurate-enough average data rate
even using the standard Windows timing mechanisms.


yes, but then how? Waiting an appropriate amount of time is much more
difficult if that time is very short.

Whether this is practical in your case, I can't say. It really depends on
why the timing is so critical to you. But generally speaking, it's just
not a problem. Average is just that: average. If you average over a long
enough time period, it's trivial to achieve any arbitrary average. You
just need to be able to select a long enough time period.


The timing isn't critical except that I don't want it to take 5 years to
send 9 bits. Faster is better because it increases productivity and
decreases frustration.

[...] What I'm trying to achieve is a way to send data at an average rate
so this can be quantitatively adjusted by the user. So if the user wants
20khz he will get about 20khz and not 50khz or 5khz(on average).

Well, over what time period is it necessary that this average data rate be
achieved? Will the user care if the data transmission is in short, rapid
bursts that over a second or more still average out to the rate they've
selected?


No, it doesn't matter as its an average and suppose to be on such a small
time scale that the user can't comprehend it anyways(so they will jsut see
the average)
Or is the requirement more sensitive than that?

[...]
Sure... but if you can come up with a better way then I'm all ears. This
is the method used by all the programs that I am aware that are doing
similar stuff to what I need.

For example? What Windows programs are you talking about that use this
library to access the CPU's i/o port directly, rather than going through
CreateFile to access the parallel port? How have you verified that they
use this technique? And if they use this technique, how to _they_ deal
with the data throttling issues?


Yes I have. Look up WinPic, InpOut32, PortTalk, GiveIO, etc... Anything to
do with embedded system communication using hte parallel port almost surely
uses the moethod I'm doing.

They just bit bang and hope for the best and it works... They don't care
about blocking other threads or long delays or anything because it usually
works... and if it doesn't they you insert a larger delay.

A simple example can be found

http://www.codeproject.com/csharp/csppleds.asp

I'll be working with pic's instead of led's(which are easy and require no
protocol) and lcd's.

Knowing answers to those questions would go a long way to better
understanding your specific situation.

Although I have no idea how SPP mode works with clocked data for, say, a
printer. I'm not sure if they just bit-banged or what. Obviously the
newer modes get around this by having the hardware deal with it but they
then introduce there own protocols that do not work for me cause the
devices I'm attaching do not understand them.

As far as I know, a parallel printer driver does not implement its own
parallel port i/o. It uses the built-in Windows parallel port driver, and
relies on that driver to deal with the low-level issues. This is true
even for the older parallel port modes (often selectable in BIOS, so
Windows has to support them).

If it were me, I would use unmanaged code based on CreateFile using the
parallel port as my first attempt. Only if that didn't allow me to
achieve what I wanted would I mess around with this lower-level stuff.


Well, it might work. I don't see it being any different than using the
kernel mode driver I'm using since I think for all practical purposes it
does the same except probably more efficient(since its built for this).

The problem I do see though is that in general the parallel port uses some
handshaking methods that I would end up having to emulate to get it to work.
This is completely unnecessary for what I'm doing and causes more problems
than its worth.


Thanks,
Jon


.

Relevant Pages

  • Re: Explain this about threads
    ... Writing your own driver won't help you any further as long as you ... SPP doesn't use those lines at the hardware level. ... For programming a PIC MCUthat protocol ... Please tell me what kind of parallel port driver do you use here? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Explain this about threads
    ... SPP uses the status lines (Ack, Busy ... ... Writing your own driver won't help you any further as long as you don't ... For programming a PIC MCUthat protocol is ... Please tell me what kind of parallel port driver do you use here? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Explain this about threads
    ... 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. ... For programming a PIC MCUthat protocol is not needed but there is a similar protocol that can be implemented for the parallel port. ... the "busy" signal is the handshake line used to indicate that the device is ready to accept data from the parallel port host. ...
    (microsoft.public.dotnet.languages.csharp)
  • Strange shutdown problem - HELP, PLEASE! and what is glogodrv.sys?
    ... it seems to be related to the parallel port. ... type: 1 Kernel Driver ... I made a restore point after reintstalling the graphics driver, ... Gigaraid onboard raid set up for backup- four WD40 harddrives running in raid ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Explain this about threads
    ... How can you ensure an average data rate but not ensure it will not be to fast? ... If you average over a long enough time period, it's trivial to achieve any arbitrary average. ... What Windows programs are you talking about that use this library to access the CPU's i/o port directly, rather than going through CreateFile to access the parallel port? ... It uses the built-in Windows parallel port driver, and relies on that driver to deal with the low-level issues. ...
    (microsoft.public.dotnet.languages.csharp)
Loading