Parallel port programming

Hallo,

Im in the process of doing some basic stuff with connecting some LEDs and eventually motors to the parallel port on the computer. Right now I have not actually connected it do the computer, but plan to do so later today.

After doing some searching/googeling I found out that controlling the parallel port in XP is not as easy as I first thought. I could not find any good solutions to the problems, as most of the working programs was to linux/win98.

Does anyone know of a good tutorial on how control the parallel port in XP or know where I can find a decent but basic project to look at? Or am I better of formating my old laptop (going to use a old laptop I have in case I blow the motherboard or something stupid like that. Guess Im not the kind of electronic) to win98?

Thank you in advance.

It sounds like what you want is a little driver that allows you to write to the IO-port directly. The first or second hit on Google for that is this:
http://www.beyondlogic.org/porttalk/porttalk.htm

I have no idea if this will do what you want or not, but I would suggest you try doing it according to that principle, rather than using the Win98 route.

Linux is of course another possibility.

--
Mats

That looks like something that would work, but I was hoping there was something a bit more easy to use out there. Something like only a .dll file or like. But if it works it works.

I have never touched linux before, maybe its time to do so?

A .dll will not allow you access to the parallel port - the reason being that the processor is stopping it unless the OS has the right bits set to the right value in the IO permission map (which is being checked by the processor at every access to an IO-port). Windows NT and onwards do not allow any user-mode IO access by default, so you need some sort of kernel-mode code that can "fix that". .dll's are only kernel code when they are loaded by other kernel-mode code, so a .dll that you link to your application can't be the solution (unless your app in itself is a driver - and it's much easier to debug and fix code that is user-mode[1], so I would suggest that if the driver I suggested does what you want, then that's the RIGHT solution).

[1] A crash in user-mode just kills your application. If you do something "stupid" in a driver, it stops the machine (blue-screen), without any possibility to get it back. The only real way to debug a driver is by serial port (or firewire if you have that, but only some firewire cards are recognized by the debug-driver) from another machine - I've done it, and it isn't terribly hard, but at the same time, it's not as smooth as the IDE in for example Visual Studio.

--
Mats

If you where to send input through an output USB/PP prong/channel/whatever, could you actually fry the motherboard from short curciting?

yeah =\

Going to use my old laptop for this. Its so bad anyway.
I was planning to do connect it and try it out last night, but I could not find a parallel cable. And the shops that still had opened did not have one :O

Parallel port is "high impedance" (or at least it SHOULD be), so you really need to feed high voltage/high current onto the pins to make something go wrong. Connecting an output pin to another output pin is very unlikely to harm anything - but if you drive the two outputs in different direction you may find that "one direction wins" (usually the "low", because it's easier to make a transistor drive a "zero" than to drive a "one").

USB ports are also pretty well protected, and of course, if you use something like a USB parallel port, then you are pretty much guaranteed that it's not going to blow up your motherboard by doing someting silly on the ports (perhaps you can blow it up if you connect one of the pins to your power-socket in the wall).

--
Mats