At 01:15 PM 3/9/2005, R. Kevin Stover wrote:
>Jim Lux wrote:
>
>>The real problem with using the printer port these days is that
>>a) You're pretty well insulated from the hardware using Windows, so you
>>have to do all sorts of workarounds to talk to the bits. You can set up
>>a plain printer, and talk to it as if it were a dumb printer, but you
>>don't have any control over strobing, timing, or the ability to readback
>>the port. Yes, there are a raft of programs and windows drivers that get
>>around this, but since they violate a fundamental part of the design of
>>Windows (i.e. insulate user programs from the hardware), they tend to be
>>"picky" in their functioning.
>
>Agreed. Alas, MS decided a long time ago that their operating systems
>should be designed with "Mom and Pop" in mind rather than power users and
>developers.
I have many gripes about Microsoft's philosophies, but the idea of keeping
userspace tasks away from the hardware is a good one, and has been a part
of operating system design since the late 60's, early 70's at least.
(basically, as soon as you implement any sort of memory management, it gets
to be a good idea).
Power users and developers can use the MS DDK, which even includes sample
code for the drivers. And, at least drivers can be dynamically loaded
without a reboot. Philosophically, that's what multi-tasking operating
systems "should do"... make it impossible for task 1 to interfere with task
2 or with the OS.
What MS did (and didn't do anyone any favors by doing so) was to take a
glorified BIOS with a command line interpreter (DOS) and graft a windowing
front end on it, without actually putting in a real multi-tasking, memory
managed OS kernel underneath it. This let everyone who wrote low level
stuff in DOS keep using the same code, while having all sorts of odd
compatibility issues as they tried to keep supporting it. I was SO glad
when NT and Win95 came out that forced software writers to actually use
decent practice and use the provided APIs. It also resulted in software
developers demanding that MS put reasonable hooks into the APIs to let them
do what they wanted. [especially game programmers, who needed fast BitBlt
type operations, which the Windows GDI didn't support, even if the hardware
did] Some were well implemented, others less so. And, it demanded a
higher level of programming skill and knowledge to use the techniques (not
to mention having to buy the DDK).
MS has abandoned the low-buck hardware hacker market, and good riddance to
them.
Fortunately, there are many, many alternatives, at lower cost, for that
market, which is probably a good thing. It's much more appropriate to
devote a Rabbit, or a Stamp, or a PIC, or even an Allen-Bradley PLC (like
the picocontrollers or micrologix), to things that are being done with low
level coding. That will give you deterministic timing and other things
that are nice (if not essential) for control applications.
And, for the situation where you want to run on a PC, and do "control"
kinds of things, there's a huge number of companies supplying interfaces
with Windows drivers (some good, some bad) and API support into high level
languages.
Yes, there's a $100 buy in cost to get one of the interface widgets (or a
rabbit or stamp or...), as opposed to just wiring up a few resistors to a
parallel printer port, but, once you've paid the $100, you're a lot, lot
better off. (IMNSHO)
Jim...
_______________________________________________
See: http://www.mscomputer.com for "Self Supporting Towers", "Wireless Weather
Stations", and lot's more. Call Toll Free, 1-800-333-9041 with any questions
and ask for Sherman, W2FLA.
_______________________________________________
TowerTalk mailing list
TowerTalk@contesting.com
http://lists.contesting.com/mailman/listinfo/towertalk
|