LPT port

[Invisible]

hi,

I would like to start a project using LPT port instread of Com,
I had think about 16f87x pic but:

-I am no so clear about conect pic to lpt, I think it can be done directly pin to pin
-No good idea how to ´sniff´ what is happening in that port, there is something like serial monitor?, I had seen a couple of ms-dos based programs looking realy bad

Thanks for any help!

best regards
Invisible
___________________________
This message was ported from CCS's old forum
Original Post ID: 11074

[Shane Rowell]

To get up and running fast, I would use Qbasic first. It is dos based and allows direct access to the parallel port. I know that it works under win98, but an not sure how it works on other operating systems.
If you go to the device manager in windows, or look at the screen dos screen right after you turn on your pc, you can get the address to the port. The address is usually in the range 0378-037F. I believe that 0378 will allow you the access that you need.

You will be able to read/write the state of the pins by using the follofing commands in QBasic.



int 8 = inp(888) //read
out(address,value) //write value to address

I recommend that you use the pins as 1-directionl. With this method you will use the pins in the configuration that they are normally used.

As with all pc, dont load the pins and be carefull about esd.

I hope this gets you started.

Shane






:=hi,
:=
:=I would like to start a project using LPT port instread of Com,
:=I had think about 16f87x pic but:
:=
:=-I am no so clear about conect pic to lpt, I think it can be done directly pin to pin
:=-No good idea how to ´sniff´ what is happening in that port, there is something like serial monitor?, I had seen a couple of ms-dos based programs looking realy bad
:=
:=Thanks for any help!
:=
:=best regards
:=Invisible
___________________________
This message was ported from CCS's old forum
Original Post ID: 11185

[Guest]

[Ttelmah]

What OS are you intending to run on the PC?.
Now the problem here is that MSDOS, and W9x, alow programs to directly access resources like the parallel port, while latter OS's (NT, W2K, WXP), will all prevent 'user mode' programs from talking directly to the port. There are ways to bypass this protection, but they involve either writing your own 'ring0' driver for the port, or bodging the OS, and turning off the protection for some ports. The former is hard work, and the latter raises the possibility of making the OS more fragile (this is why the protection was introduced to prevent programs accessing things they should not...). Remember also, that the parallel port is obsolete, and not provided on many modern computers, so if this project is more than a 'bit of fun', you should consider another approach...
Personally, I'd consider one of the FTDI USB serial modules (remember these can transfer data at 1Mbps, and the FIFO version, can go to 3Mbps). For either the FIFO version mentioned above, or the parallel port, the approach would be basically the same. Data is 8bits wide, presented on 8 lines, with added 'acknowledge', and 'strobe' lines. When a character is output, the sending device generates a 'strobe' signal, and then waits to see the 'ack' from the receiver. These handshakes are neeed to synchronise the transfer. So just to send data to the PIC using this interface, is 8 bits are transferred at a time, requires 10 pins on the PIC. If you want to go bi-directional, you need to add a direction control as well, and a lot more complexity in the code.
Generally, a PIC is straining to do much constructive with data at the highest serial rates, and the wiring is a lot easier than for a parallel interface, so I'd perhaps 'reconsider', and look at the USB serial modules instead.

Best Wishes

[neil]

I like the sound of those FTDI devices. They appear very simple to use! I might see if I can find an excuse to put one on my next design to try them out! They are especially good now that most laptops no longer have serial or parallel ports (mine included). I am thinking on the lines of using one to flash a PIC in situ, using a laptop. Do you know of any pitfalls with them?

Neil.

[Ttelmah]

Yes. The 'modules', can in some circumstances have a noise problem. This is normally fixable by adding a capacitor between the shield on the USB connector, and the local 0v. In some very noisy enviroments a couple of tiny decoupling capacitors on the incoming USB signals can also help. However in normal fairly 'friendly' enviroments, they work well now, and the current code is reliable. If building completely using the chip, a bit of care in ground plane design, makes them really reliable. they are a pretty good solution.

Best Wishes

[neil]

Ha! If they will work where we are, they will work anywhere! We have electrical switching noise, loads of controlled rectification around, and some very high power RF! We even have ionising radiation, though not near the electronics for obvious reasons

You say 'tiny' decoupling caps on the USB lines. They must be really tiny not to slug the signal at (what) 3Mbps? The sort of RF we have around here is slap bang on that frequency. We usually survive with good PCB design and putting the sensitive circuitry in a grounded can.

I think I'll stick a few chips on order and have a play anyway.
Cheers, Neil.

Sorry to be using someone elses thread here. A bit off topic, but still of interest!

[treitmey]

I have the FTDI chips in 4 products now.
Get samples of each chip. There great.
Also pick up some of the I2C FRAM chips. Another great chip.

You see when you get all that data from the PC and its flowing fast and free, you'l need to store it someplace.

[Ttelmah]

Not as small as you may think. The recommended values were 47pF, from D+ to GND, and 47pF from D- to GND. Then a 470nF from the shield to GND. This was back in USB1.1 days (12Mbps max on the bus). The reactance of these, is still over 280R at the full frequency on such a bus.

Best Wishes

[neil]

Is USB differential? I guess it is from the names "D+" and "D-", so the caps are in common mode and will shunt common mode noise away, leaving the differential mode signal relatively untouched.

I guess it would pay for me to look up the USB spec. somewhere!

Neil.

[newguy]

USB isn't really differential. There are lots of different coded messages/responses, each with a different signalling format. Sometimes the signalling can be single-ended (i.e. one line being driven while the other is grounded), and sometimes it can be differential. Sometimes the D- line is the "positive" line, while the D+ becomes the "negative" one. It's all very complex.

If you want to learn everything there is to know about the USB spec, then "USB Complete" by Jan Axelson is a decent book. It's not great, but it's not bad, either.