Never done it before,dont know how but its due next week.Im a computer systems student and have been required to built a hardware that will be operated by a programe in G++ through the parallelports.the hardware, thats a piece of cake, the software, now thats were the real problem is.I dont even know were to start.

Someone please help

Note sure what the homework help policy is on the forum but if we're not allowed then please delete my post

I'm assuming you meant "programmed in C++". G++ is the name commonly used for the GCC C++ compiler.

There are many tutorials out there on the internet to get you started. Here's one of them:
http://www.epanorama.net/circuits/pa...nuxprogramming

The easiest way to test this is to hook up spare leds from the data pins on your pport to one of the grounds. This will make it easier to visualize what is happening. The best way to get started is to perhaps program something that will count in binary on the LED's. The reason being the output in the program is easy to do.

You can imagine the 8 datapins as binary counters. When you send for example 0xFF, translate that to an 8 bit binary number: 111111. This is the status of your 8 pins. So say for example I want the output on the port to be like this: 00100100. To achieve this, just translate that into the hex digits you need.

To do your counting program, you can just loop up throughthe hex digits. Just remember to add some pauses so that it doesn't count too fast

Also rememeber to be somewhat careful when you're hooking up circuits to the pport as it's slightly possibly to fry your motherboard with a wrong connection (ie: sending 5v in through the outputs)

In Linux, there are a few different ways to access the parallel port. You will have to choose one, depending on your requirements. It isn't clear whether you are asking about this aspect of the problem, or whether you need information about the actual parallel port hardware-level interface; I'll assume, since this is Linux Questions, that you want to know about the software aspect.

You can write a kernel module device driver to access the hardware. This will give you the greatest level of control, but comes with a hefty degree of complexity. Once you've done that, you can then open()-read()-write()-close() the device from a userspace application. What you write from your userspace application will determine what gets put on the hardware, according the the way you've designed and written the driver.

You can write & read individual IO-space registers (the actual hardware registers) from a userspace application using either the /dev/port general purpose interface method. This model makes the /dev/port virtual device look like a file that you access using filesystem semantics. It requires root privileges to use this method.

You can use the ioperm() + inb()/outb() family of system calls to access IO-space hardware registers. This also requires root privileges. See the outb man page for details. This is comparable in capability and complexity to the /dev/port method mentioned above.

The least flexible method, but possibly not requiring root privileges, would be to use the existing parallel port driver(s). To do this, your external hardware would have to be constructed to have some behavior resembling a printer. The existing drivers are geared toward sending data to & from printers using the Centronics interface standard. Without knowing the details of your project requirements, it may be that you simply want to drive the standard 8-bit data output latch/line driver with various data bytes. If so, this might be the easiest method to perform in software.

There are numerous online descriptions of the standard parallel port hardware, and many are accompanied by project examples with both hardware and software. Not too many are Linux-specific, but the hardware aspects are a constant. Back in the day, the parallel port was widely used by hobbyists, experimenters, and commercial products as a somewhat general purpose interface that was easy to use to interface non-printer devices. I find it sad that this style of interface has become mostly lost.

--- rod.