IEEE-1284 problem

Sounds like a transmission line issue to me; poor ground eg using one ground wire instead of a ribbon with ground wires in between each data line. Signal reflections in the cable which will often cause bit pattern dependant errors.

Have you looked at the IEE1284 spec for cables which, if I remember correctly, specifies things like the cable screen being connected all the way round at the connectors, not a pigtail ?

Bob

Just to be clear here, are you running the card in DOS or Win95? Have you checked for shared interrupts?

Are you terminating the signals properly? Is your add-in board terminating the signals properly?

Poorly terminated signals could cause considerable ringing on the strobe pins, which would cause double writes. Termination matters, but things often work when only one side is terminated; it may be that your board isn't terminated, the motherboard is, and your add-in board isn't.

I'd go over the IEEE-1284 spec carefully for the expected termination on the printer side and make sure I was compliant. Then I'd consider terminations anyway, just to make sure.

I should have mentioned that I **DO** use cables that have IEEE-1284 written right on the cable jacket. If I try to use other cables, it is total garbage. I have been building boards in this series since 2001, so I have a fair bit of experience with it. On a couple occasions I have made custom cables out of twisted-pair robbon cable, with one pair for EVERY signal, and these work a lot better than the commercial cables, which I think only have twisted pairs for the strobes and nwait.

I do agree that transmission line effects are responsible for a portion of these problems. But, my old board design works, although the margins are probably small.

Jon

Neither. I use a Win95 system only to set the board to the right mode (SPP, ECP or EPP). After that, it runs under Linux, with the board being driven either by a user-mode diagnostic or a CNC control program that runs under the RTAI real time extension. Interrupts from the board are not being used in either case.

Jon

Careful digging into manufacturer's data sheets for their EPP chips don't detail anything about termination, I rather suspect they don't deal with this. Some boards have no sign of resistors, either, others do. These particular Par Port cards do have what looks like 33 Ohm series resistors on a bunch of the pins.

I threw a 100 Ohm series resistor on the nWAIT line right out of the driver on my board, and it appeared to make things WORSE! Also, the nature of the ringing on that line made it appear there is no receiving termination on the PC plug-in card. It appears to have a small cap to ground and a 33 Ohm R in series going to the chip on the par port card. Assuming that that chip's pin is programmed as an input when the par port card is the master, such a resistor would not help the situation. Well, maybe the fact that adding a series resistor to nWAIT CHANGED things is an important clue, and I just have to find the magic combination that makes this work. Raising the impedance of a line subject to a lot of crosstalk is not the best approach. I've played arond with the FPGA state machine on my board to change the timing relationships, giving the data more setup time, etc, without much help.

I'm hoping to make my board work with commercial, off the shelf PC parallel ports, despite their flaws and cut corners. Of course, I've found a couple that have such serious flaws as to be totally unusable, and that goes for some on the motherboard par ports, too.

Thanks for your comments.

Jon

Oh, I'm not an IEEE member, so my price is $108 for the pdf file. I'm not completely sure that is all I need, as clearly there are off the shelf boards that go their own way on interpreting the standard.

Thanks,

Jon

Well, you work with the same things too long, and you get to thinking you know an awful lot about it! Terminating the data lines was the problem. Probably a case of too many lines changing state at the same time, causing crosstalk on the strobe lines. Anyway, the magic recipe appeared when I terminated only THREE of the 8 data lines to 3.3 V with 390 Ohm resistors. Suddenly it was running several hundred thousand cycles of the diagnostic with no errors.

Of course, I thought that wasn't going to do any good, because it didn't do any good on a different par port card and a different type of peripheral board in the past, with somewhat different timing. I'm guessing the receivers on this PC par port card have different thresholds, making them more sensitive to the noise. (Of course, I will actually terminate all 8 data lines, and if terminating the incoming control strobes is not counterproductive, I'll terminate them, too.)

Well, thanks MUCH for the kick in the pants needed to try some conventional bus integrity measures over again with a fresh view. I'll have to patch the new boards that haven't even arrived from the fabricator yet before I can re-spin the layout. Thanks goodness I only ordered 25 boards!

Jon

That's why engineers are bald in front -- it's from slapping ourselves in the forehead and rubbing off all the hair.

I was thinking about your comment that you have to get it working with what's out there, not just to the spec -- but I didn't want to make you bear another cross unless you already had to.

Hmm, I must not be doing that enough, I still have that hair pretty much.

Well, I've seen some substantial variation in the timings of commercial PCI boards and motherboards. One motherboard put the strobe out first, BEFORE the data and write signal! Another, after much study with a logic analyzer, must have allowed the CPU to continue running about 20% of the time, instead of enforcing the CPU wait state. What I'd see was the data lines changing to the next value DURING the datastrobe. The only explanation I could come up with was a timing race on the motherboard that cause the CPU to fail to honor the wait request. Then there were some that were so pathological I couldn't even begin to guess what the garbling was caused by.

I haven't paid for the IEEE document, and the available net resources are very skimpy on timing details. The best place for free info I could find was the manufacturer's data sheets for the multi-I/O chips that were used in all PC motherboards a few years back. Even those were real skimpy on actual timings, but at least told what the signal sequence was, what time (relatively) the chip clocked incoming data off the bus, etc.

Anyway, the solution was one of those "too simple" ones that stare you in the face. "But, I already TRIED that!"

Jon

Presumably you installed it in parallel, reducing the impedance on the end of the line. A short circuit on the end of a transmission line gives a near perfect reflection. Sometimes reducing the impedance on the end of line is moving things further away from the optimum condition towards total reflection. A sharp edge contains high frequency energy, the input capacitance of the circuit on the end of the line can look quite low impedance to some of the frequency components.

There are cases where series termination is an improvement, though the big problem is of course that you form an RC filter with the input capacitance of your circuit.

bob