Parallel Port Interface/ADC0820 HELP PLEASE!!!

Hello All, I have a serious problem getting my circuit to work, and maybe someone here can help. I read threads here all the time, and
have gotten some help one or twice (who knows, maybe someday ill be able to give advice).
Anyway, I'm trying to interface a simple circuit to my PC's parallel port such that I can read 8-bits of data from an ADC. I have several ADC0820's (http://cache.national.com/ds/DC/ADC0820.pdf ) lying around so I am going to try to use them. My current circuit is as follows:
Pin 1: Vin Pin 2: Pin 2 of Parallel Port Pin 3: Pin 3 of Parallel Port Pin 4: Pin 4 of Parallel Port Pin 5: Pin 5 of Parallel Port Pin 6: Pin 1 of Parallel Port Pin 7: +5 volts Pin 8: Ground Pin 9: Not Connected Pin 10: Ground Pin 11: Ground Pin 12: +5 volts Pin 13: Ground Pin 14: Pin 6 of Parallel Port Pin 15: Pin 7 of Parallel Port Pin 16: Pin 8 of Parallel Port Pin 17: Pin 9 of Parallel Port Pin 18: Not Connected Pin 19: Not Connected Pin 20: +5 volts
Note that I am not using resistors neither between my ADC and parallel port nor between Vin and my ADC. Also note, Vin does not exceed +5 volts.
I currently have a small program (Visual Studio .NET) to see if my circuit is working. Note that I am using Inpout32.dll (http://www.logix4u.net/inpout32.htm ) to access the parallel port.
What I would is when I touch a wire lead from Vin to +5 volts to see 255 printed to my computer monitor, and when I touch the wire to ground to see 0 on the screen. What I DO see is 189 or 188 printed to the screen when I touch the wire to +5 volts and 3 or 4 when I touch the lead to ground. I am very confused
My (pseudo) Code:
Out(890,32);    //Turn on "Bi-Directional" mode and set pin 1 (pin 6 of ADC0820) high.
while(1) {     Out(890,33);    //Set pin 1 (pin 6 of ADC0820) low while keeping bit 5 high.     Out(890, 32);    // Set pin 1 (pin 6 of ADC0820) high again.     printf("%d\n", In(888) ); }
END OF CODE Note pin 1 of parallel port is inverted so a 1 sets the pin to low.
Parallel Port Reference: http://www.logix4u.net/parallelport1.htm
What ISN'T wrong. My parallel port is ECP mode and DOES support bi-directional functionality, the ACD0820 chip is in working condition, and my parallel port is in working condition. Anyway, I hope someone has some experience with these issues and could give me some advice. I would really really appreciate it. Thanks, Lucas McGill.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@uiuc.edu wrote:

I don't know much about these things but for the fun of it I looked at it to see what I could figure out. For one, I found this note in the pdf:
In order to maintain conversion accuracy, WR has a maximum width spec of 50 &#956;s. When the MS flash ADC’s sampled-data comparators (Section 1.2) are in comparison mode (WR is low), the input capacitors (C, Figure 8 ) must hold their charge. Switch leakage and inverter bias current can cause errors if the comparator is left in this phase for too long.
Have you used a scope to check exactly how long your code is holding pin 1 low? If it's over 50 us it seems you will get some errors in your readings as the holding capacitors leak too much current. Also, what happens to pin 1 when you try to read the data? If chip sees the change as if the pin was going low again, it would start another conversion and the data out pins would become invalid shortly there after. So you would have to make sure the parallel port was reading the data out pins before they went invalid. You might need a a pull-up resistor on that pin so that the chip doesn't see the pin go low when you make the parallel port read the pins.
Also, there's a min hold down of 600 ns on that pin. Any chance your circuit is running too fast and not holding it down long enough?
The other thought I had was that your power lines might have noise on them from the operation of the chip. The application notes all show the use of caps near the chip (47 uf + .1 uf) to eliminate that noise. If you are not doing the same, you might try it to see how it effects your error.
Also, when you connect +5 to Vin, try doing it by using a short jumper directly from Vref+ to Vin instead of something like a line running from your power supply to Vin. If you are getting noise on your power lines then the voltage drop on the wire running to your power supply could be the cause of your errors. A direct connection from Vref+ to Vin should make sure the chip is seeing the same voltage on Vin that it's seeing on Vref+ to give you the 255 output you would expect.
But like I've said, I've never worked with these devices so this is all just ideas off the top of my head you could try.
--
Curt Welch http://CurtWelch.Com /
snipped-for-privacy@kcwc.com http://NewsReader.Com /
  Click to see the full signature.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Curt Welch wrote:

Thanks for your ideas Curt, I will try them and see what happens. Again, Thanks, Lucas.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Are the all the data pins left unconnected? Try pulling them down with 1k resistors, you may be affecting all the pins' states when touching just one pin.
-howy
snipped-for-privacy@uiuc.edu wrote:

Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
howy wrote:

If you are refering to the data register (parallel port pins 2-9) when you say "data pins", then yes they are all conntected to the ADC output pins. When doing my "experiment" i touch touch a wire lead from Vin (of the ADC) to either ground (common between the ADC and the parallel port) or to +5 volts. Does this make sense? Also, i didn't mention earlier, I have tried 1k resistors between my ADC and my parallel port data register pins and that offered no solution.
thanks again for the suggestion, Lucas.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@uiuc.edu wrote:

Why don't you take the ADC out of the picture for a bit and connect up the parallel port data pins (2-9) to do a test. I forget if it's active high or acrtive low, but (or example) all pins grounded should yield 255 on your app, and all to Vcc shold yield 0. You can then try individual bits to see if that is correctly changing the value. Setting pin 2 of the port will affect the LSB, so that should show 0 or 1, etc.
After you have that portion of the circuit prooved out, connect your ADC back up, and put LED's on at least four of the parallel pins (don't forget the dropping resistors). Ideally take the time to put eight LEDs onto the pins. That way you can visually see the status of the pins.
You should not be connecting ground or Vcc to between the output of the ADC and the parallel port pins. Most chips do not like to have their outputs loaded; in fact, it can blow them out (though I doubt that would happen with an ADC). Let the port be driven by a dummy circuit that I've described above, OR the ADC, but not both at the same time.
-- Gordon
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

UPDATE
For those of you who are still willing to help (I know its been awhile) here is where I'm at. Gordon, you suggested some nice troubleshooting ideas that I used.
I removed the ADC from the set-up so I could test my printer port. To do this I simply connected each of the data pins to ground through a 120-Ohm resistor. The code for this part of the project was simply:
Out32(890, 0); Out32(890, 32); While(1) { printf("%d\n", Inp32(888)); }
As I expected the screen showed. I then moved each pin to high (through the 120-Ohm resistor) and the screen showed 128, 64, 32, 16, 8, 4, 2, and 1.
Next, I used LED's to see if the ADC0820 is working properly. To do this I wired green LED's to the output pins on the ADC, again through 120-Ohm resistors. I wired pin 1 of the parallel port to pin 6 of the ADC. The code for this part of the "experiment" was:
Out32(890, 0); Out32(890, 32); Pause(10); // milliseconds Out32(890, 33); //set pin 6 on ADC0820 low Pause(.25); // milliseconds
while(1) { Out32(890, 32); //set pin 6 on ADC0820 high again. }
This produced some strange results. When Vin was high (+5v) all the LED's were on (as expected), but they flickered on and off. When Vin was grounded, LED's 1,2 and 3 (00000111 = 7) were on (still flickering).
I'm so confused...Any ideas guys?
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@uiuc.edu wrote:

The desired hold-down of that pin is 600 ns to 50 micro seconds. .25 millisecons is 250 micro seconds. If you hold it down too long the charge drains off the holding capacitor and you get less accuracy in your readings.
That might explain why two LEDs are on.

I don't really know much about parallel ports but aren't they designed to transmit a value and not designed to simply hold a pin at a constant value? In other words, is it possible the parallel port pins will only show the desired value for a short period, and then return the value of the pins to ground or to an open state? If this is true, you simply might not be able to directly drive your ADC from the parallel port without help of some extra hardware.
However, even if this is true, the parallel port might have a strobe signal that would work to drive the WR line directly for you. Like I said, I don't know the standard parallel port protocol so I don't know what to expect.
The flickering might just be a result of the line constantly bouncing up and down each time you write the 32 value to it. I this is what is happening, you might be able to make it work by tying the pin to +5 (or ground) through a resistor to make sure it stays high (or low) when the parallel port is not driving it. But this all depends on what the parallel port is actually doing.
Do you have access to a scope to look at the signals?
--
Curt Welch http://CurtWelch.Com /
snipped-for-privacy@kcwc.com http://NewsReader.Com /
  Click to see the full signature.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@uiuc.edu wrote:

Another obvious debugging thing you could try is to connect a pot to the Vin signal so you could vary the voltage to see how the leds change. Just connect one side to +Vref and the other to -Vref and the middle to Vin. If you see the LEDs count up and down as you turn it, you know the ADC is basically working and that the problem is all in the interface between the parallel port and the ADC.
--
Curt Welch http://CurtWelch.Com /
snipped-for-privacy@kcwc.com http://NewsReader.Com /
  Click to see the full signature.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Curt Welch wrote:

Ok, I've found a large part of the problem, and I think it is an easy fix for you electronic/robotic gurus out there. Anyway, the seventh bit (01000000 = 64) is acting a little wierd. Let me explain. I did some simple testing, and it takes about 18mA to set the 7th bit pin high, yet it takes about 2mA to set the rest high. This is why I was getting 191 (10111111). Now the ADC0820 doesn't supply enough current to set this pin high so I don't know what to do. The data sheet says this IC meets TTL specs, and I know parallel ports are TTL. I'm wondering if I havn't destroyed something inside the PC. Nonetheless, the pin still works it just takes some extra umph.
SO the question is now, how can I use the ADC0820 to se this pin high? Should I use a small NPN transistor somehow? Is it safe to run 20 mA to the parallel port? I can find info on how much current the port can supply but not how much it can withstand. Anyway, I hope someone can help. Thanks for all the previous help, Lucas.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@uiuc.edu wrote:

It does sound like your parallel port is not working correctly. But I don't know enough about parallel ports to be sure of that.
This page:
http://www.circlemud.org/jelson/software/parapin/docs/node2.html
Says:
Input pins are typically spec'ed to be able to sink up to about 20mA.
So the current is dangerously high but might not do further damage.
The danger here is that the parallel port pins can be inputs or outputs. And you don't want the ADC outputs driven as outputs at the same time the parallel port pins are outputs. If one device is trying to drive the line low while the other is trying to drive it high, you will get a max current condition that could burn out the driver on one of the two sides.
The 120 ohm resistor you were using for testing would allow up to 42 ma to flow if you had +5 connected while the PC was trying to drive the pin in the opposite direction (I=E/R=5/120=0.416= 42 ma). For a device that can only sink around 20 ma that could have burnt something out. Something over 1K would have been a better choice. But, I don't know enough about these to know if they typically burn out if you over drive them, or if the port just isn't able to pull the pin low if you make it sink too much current.
One of the web pages about parallel ports I just saw implied the ports have a few extra control pins that can be switched from inputs and outputs independently of the main data pins you are using. If the software you are using supports it, you might try to use one of those other control pins to drive your WR pin so you can just keep the data pins in input mode. And you might also be able to use one of those to read your pin 7 value so you don't have to use your damaged pin 7.
As far as what circuit you should use to try and force the bad pin 7 to work, I'll let others with more practical electronics experience suggest something. You would be risking doing further damage to your port however if you were to force it to work with a higher current.
--
Curt Welch http://CurtWelch.Com /
snipped-for-privacy@kcwc.com http://NewsReader.Com /
  Click to see the full signature.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.