Horrible risetime on PC parallel port

Hi all,

I'm debugging some intermittent problems reported by test-users of the
circuits in my upcoming book, and it turns out they only have these
problems when using my "short-form" connection method. The short-form
method just connects parallel port lines direct to GPIOs on a
microcontroller (this is for a SPI-style interface). The "long-form"
method uses a more complicated circuit with buffers, and nobody has
problems with that circuit. But it's irksome to build by hand, so I
think most people will prefer to use the short-form method.

Please have a look at <http://www.larwe.com/trace.jpg>. CH2 is the SPI
clock line, which is driven by pin 16 of the parallel port. CH1 is the
MOSI line, driven by pin 17 of the port. Are these waveforms normal,
or am I being raped yet again by oddities of the particular SBC to
which I'm wedded? Looks like there might be caps on the lines to
inhibit fast rise (EMI stuff?).

The total cable length from SBC to hardware is only ~10cm, and my
scope probes are grounded right next to where those signals hit my
PCB, so I don't know what else I could be doing wrong that would make
these signals seem so nasty. When I test the same circuit on my
laptop, I see almost perfect square edges.

"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message
news:608b6569.0404260851.5d276411@posting.google.com...
> Hi all,
>
> I'm debugging some intermittent problems reported by test-users of the
> circuits in my upcoming book, and it turns out they only have these
> problems when using my "short-form" connection method. The short-form
> method just connects parallel port lines direct to GPIOs on a
> microcontroller (this is for a SPI-style interface). The "long-form"
> method uses a more complicated circuit with buffers, and nobody has
> problems with that circuit. But it's irksome to build by hand, so I
> think most people will prefer to use the short-form method.
>
> Please have a look at <http://www.larwe.com/trace.jpg>. CH2 is the SPI
> clock line, which is driven by pin 16 of the parallel port. CH1 is the
> MOSI line, driven by pin 17 of the port. Are these waveforms normal,
> or am I being raped yet again by oddities of the particular SBC to
> which I'm wedded? Looks like there might be caps on the lines to
> inhibit fast rise (EMI stuff?).
>
> The total cable length from SBC to hardware is only ~10cm, and my
> scope probes are grounded right next to where those signals hit my
> PCB, so I don't know what else I could be doing wrong that would make
> these signals seem so nasty. When I test the same circuit on my
> laptop, I see almost perfect square edges.

I would suggest you add some pull-ups (say 1k) ...Those LPT ports come in
various flavours...

- Dejan

Hi!

> Please have a look at <http://www.larwe.com/trace.jpg>. CH2 is the SPI
> clock line, which is driven by pin 16 of the parallel port. CH1 is the
> MOSI line, driven by pin 17 of the port. Are these waveforms normal,
> or am I being raped yet again by oddities of the particular SBC to
> which I'm wedded?

Same experience here. Or, more precisely, there's a *wide* variation in
rise-time between the parallel ports I've seen. I was only able to reach
reasonably stable performance with schmidt-triggered buffers. You could also
try a relatively small pull-up resistor on the line to improve rise-time.
You might also try to switch the printer port from bi-directional to SPP
mode. I seem to recall that in bi-directional (not EPP or ECP) mode the
output lines are not actively driven to high.

--
Regards,
Andras Tantos
<http://andrast.tantos.homedns.org>

"Dejan Durdenic" <no_spam@nospam.com> wrote in message
news:c6jet8$ha4$1@ls219.htnet.hr...
>
> I would suggest you add some pull-ups (say 1k) ...Those LPT ports come in
> various flavours...

Agreed. Those look close to open-collector/drain.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com

> Please have a look at <http://www.larwe.com/trace.jpg>. CH2 is the SPI
> clock line, which is driven by pin 16 of the parallel port. CH1 is the
> MOSI line, driven by pin 17 of the port. Are these waveforms normal,
> or am I being raped yet again by oddities of the particular SBC to
> which I'm wedded? Looks like there might be caps on the lines to
> inhibit fast rise (EMI stuff?).
>
Lewin,
    My irreplaceable original XT Technical manual (pink book) shows lines 16
& 17 as being open collector (7405) with a pullup of 4k7 and a 2.2nF cap to
ground (for a 10 us time constant) on the schematic of the printer adapter.
As this is the granddaddy of all the printer ports, I'd treat it as a
baseline.  The data lines have push/pull (74LS374) outputs with the same
capacitors and should be significantly faster.  Looks like your outputs have
a faster time constant than the 10us of the originals.

Cheers,
Alf
alfkatz@remove.the.obvious.ieee.org




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.667 / Virus Database: 429 - Release Date: 23/04/2004

Hi Andras,

> > Please have a look at <http://www.larwe.com/trace.jpg>. CH2 is the SPI
> > clock line, which is driven by pin 16 of the parallel port. CH1 is the
> 
> Same experience here. Or, more precisely, there's a *wide* variation in
> rise-time between the parallel ports I've seen. I was only able to reach
> reasonably stable performance with schmidt-triggered buffers. You could also
> try a relatively small pull-up resistor on the line to improve rise-time.
> You might also try to switch the printer port from bi-directional to SPP
> mode. I seem to recall that in bi-directional (not EPP or ECP) mode the
> output lines are not actively driven to high.

Well, Alf Katz emailed me to say that the particular lines I chose are
implemented as OC outputs with 4.7 to +5 and 2n2 to gnd in the
"original" XT, so I think I have to work out some way of adding
further pullups (over and above the "20~100K" pullups inside the
microcontroller). This problem is very difficult, approaching
intractability - the whole purpose of the "short-form" cable is to
require no additional components for a single-device configuration.
But if I put the pullups on the peripheral PCB, then it will overload
the bus when more than one peripheral is connected.

I am using the port in SPP mode already, but TTBOMK that only affects
the data lines, not the control lines I'm using here. I use the data
lines as selects for up to eight peripherals, so they're already
taken.

Hmm. I can slow the software down easily enough, but the SPI pin
sampling is done in hardware and I think the shark-fins are confusing
the USI. Grrrr.

Lewin A.R.W. Edwards wrote:

> Hi Andras,
> 
> 
>>>Please have a look at <http://www.larwe.com/trace.jpg>. CH2 is the SPI
>>>clock line, which is driven by pin 16 of the parallel port. CH1 is the
>>
>>Same experience here. Or, more precisely, there's a *wide* variation in
>>rise-time between the parallel ports I've seen. I was only able to reach
>>reasonably stable performance with schmidt-triggered buffers. You could also
>>try a relatively small pull-up resistor on the line to improve rise-time.
>>You might also try to switch the printer port from bi-directional to SPP
>>mode. I seem to recall that in bi-directional (not EPP or ECP) mode the
>>output lines are not actively driven to high.
> 
> 
> Well, Alf Katz emailed me to say that the particular lines I chose are
> implemented as OC outputs with 4.7 to +5 and 2n2 to gnd in the
> "original" XT, so I think I have to work out some way of adding
> further pullups (over and above the "20~100K" pullups inside the
> microcontroller). This problem is very difficult, approaching
> intractability - the whole purpose of the "short-form" cable is to
> require no additional components for a single-device configuration.
> But if I put the pullups on the peripheral PCB, then it will overload
> the bus when more than one peripheral is connected.
> 
> I am using the port in SPP mode already, but TTBOMK that only affects
> the data lines, not the control lines I'm using here. I use the data
> lines as selects for up to eight peripherals, so they're already
> taken.
> 
> Hmm. I can slow the software down easily enough, but the SPI pin
> sampling is done in hardware and I think the shark-fins are confusing
> the USI. Grrrr.

  Which uC are you using ?
Most small uC have schmitt buffers already, so I'd rig a simple non 
inverting Schmitt buffer on the offending lines, and check if your uC
is then happy - that'll let you decide if it's a timing slew issue,
or the slow edges themselves messing things up.

  With luck, a simple SW delay will fix things :)

  Try and choose a buffer similar to your uC, so for a Tiny26 that
would be two HCT14 gates in series.
  You can use an unused uC pin as a 'best match' pull up load.

  Some uC also have MIN widths to allow internal state machines to keep 
up, so check if the narrowing of the pulse caused by the slow rise is
not hitting that sort of limit.

  You can also write to a PC port multiple times, as a simple 
predictable delay.

-jg

On 26 Apr 2004 09:51:29 -0700, larwe@larwe.com (Lewin A.R.W. Edwards)
wrote:

>I'm debugging some intermittent problems reported by test-users of the
>circuits in my upcoming book, and it turns out they only have these
>problems when using my "short-form" connection method. The short-form
>method just connects parallel port lines direct to GPIOs on a
>microcontroller (this is for a SPI-style interface).
When we did parallel port interfaces to Atmel AVRs and 89S8252
for programming them we found a wide variety of voltage levels
and noise on PC LPT ports. On some we found sub-10ns pulses
which were sufficient to upset external hardware SPI interfaces,
but did not affect bit-banged SPI.

Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

> I am using the port in SPP mode already, but TTBOMK that only affects
> the data lines, not the control lines I'm using here. I use the data
> lines as selects for up to eight peripherals, so they're already
> taken.
>
As the selects don't normally need to be as fast, you might consider
swapping some selects for the data & clock lines to improve the speed.

Cheers,
Alf

alfkatz@remove.the.obvious.ieee.org
www.micromagic.net.au



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.667 / Virus Database: 429 - Release Date: 23/04/2004

Hi Jim,

> > Hmm. I can slow the software down easily enough, but the SPI pin
> > sampling is done in hardware and I think the shark-fins are confusing
> 
>   Which uC are you using ?

ATtiny26L, Vcc=5V.

> Most small uC have schmitt buffers already, so I'd rig a simple non 
> inverting Schmitt buffer on the offending lines, and check if your uC
> is then happy - that'll let you decide if it's a timing slew issue,
> or the slow edges themselves messing things up.

I can rig up such a beast, but I don't think I need to - when these
same signals come through an HC244, the pulses are narrower than they
ought to be, but the circuit works 100% of the time.

I wonder if maybe there is a fundamental bug in my code, which is only
exposed by this peculiar way of driving it. What I do is as follows:

* Normally, USI interrupts are disabled and the MISO pin is tristated
to keep the device off-bus.

* When SSEL goes low, I clear the USI clock counter and overflow flag,
set the DDR bit to enable output on MISO, and enable USI interrupts. I
also set an internal state-machine register to indicate "Now waiting
for command byte".

* The USI ISR gets the contents of USIDR and inspects it. Depending on
the command, either the system status is modified directly, or further
parameter/status bytes are received/sent. For instance, for a command
"$AB" that takes 4 bytes of parameters and returns one status byte,
the state machine goes through these states:
     - wait for command
(irq - received $AB) - command $AB receive param byte #1
(irq - received $ww) - command $AB receive param byte #2
(irq - received $xx) - command $AB receive param byte #3
(irq - received $yy) - command $AB receive param byte #4
(irq - received $zz) - [update overall system status with wwxxyyzz] -
load
                       response into USIDR
(irq)                - end transaction, disable USI interrupts

Transmission (master->slave) seems to be entirely reliable. It's
slave->master that causes problems. Depending on how I tinker with the
timing code on the master end, I either get bits shifted left or -
stranger still - bits that are supposed to be '1's are received by the
host as '0's. Strong pullup on MISO doesn't make any difference, and
scoping it shows that the AVR does indeed seem to be pulling the line
low.