[NCLUG] Software Defined Radio Application

[John L. Bass]

jbass at dmsd.com (John L. Bass) writes:
> How the parallel port appears on the hardware bus of your system greatly
> impacts the performance ... if it's effectively an ISA parallel port, then
> the ISA bus speed for each IO instruction to access the parallel port
> will be 3-4 cycles at 8MZ ... for a maximum sampling rate (including
> bandwidth for polling the interface) of between 2-2.3 MByes/sec at the
> IO interface with 100% cpu saturation and discarding the data. Depending
> on the hardware protocol between the radio and the PC parallel port this
> could be a show stopper.

I took a couple leaps that people not used to this stuff might have missed.

The ISA bus typically runs at 8Mhz on a lot of PC machines. On older PC's
this can be either 6Mhz, 4.77Mhz or something a multiple of the processor
bus clock around this speed. The minimum bus cycles is 3 bus clocks read
or write, many devices require 4. So at 8Mhz, we have a clock cycle time
(period) of 125ns.  An x86 INB/OUTB instruction to these devices will take
an ISA bus cycle time of 3*125ns=375ns or 4*125ns=500ns. This is true for
any PC architecture machine from 8Mhz to the fastest GHz machine built.

Original PC parallel ports are output only, and have a hardware handshake
for output built into the hardware to write to printers. Input on these
ports is a bit at a time on one of the status lines.

Newer PC parallel ports that are bi-directional allow the 8bit data path
to be read or written, and some allow for DMA data transfers for outbound
(write) data. Data being read from the printer port generally is polled
(aka programmed I/O or PIO). The handshake protocol is generally done in
software, which for a 16bit data stream would have a sequence like using
a level based READY/ACK push (from the radio perspective) protocol:

	short getsample() {
		short data;

		while(inb(STATUS) != READY);
		data = inb(DATA);
		outb(STATUS, ACK);
		while(inb(STATUS) == READY);
		data |= inb(DATA) << 8;
		outb(STATUS, ~ACK);
		return(data);
	}

Where inb(port) and outb(port, data) an short machine languge subroutines
which wrapper the x86 INB and OUTB instructions.

Minimum execution time to complete a single getsample to an ISA speed
parallel port is slightly longer than the time for the 4 INB and 2 OUTB
instructions  ... or between 6*375ns=2,250ns to 6*500ns=3,000ns, or
2.25us to 3.0us. This gives us a best case maximum sample rate (in
samples per second, sps) of between 1/.00000225=444,444sps and
1/.000003=333,333sps. In real life, the device at the other end probably
has some additional setup time between samples, or there will be a small
timing skew which results in more than one pass in the while(inb(STATUS))
loops, which will lower the best case sample rate further ... probably
to around 250Ksps at 100% processor saturation.

The cable waveform would be:


	data:   ----<LowByte>-----<HighByte>------

		       _____________
	READY:  ______/             \_____________

		          ______________
	ACK:	_________/              \__________


Another variation, is to reverse the READY/ACK sources for a pull (from
the radio's perspective) protocol. 

Either way there are no additional setup/handshake between samples, and
the device at the other end can use the current state of ACK to control
the high/low data bus multiplexor.

Slightly better performance can be obtained with some non-ISA interfaced
parallel ports, if the radio device is connected directly to the port with a
very short ideal cable. With a processor that has fast enough memory
and CPU's, it might even be possbile to implement this under linux with
a reasonable machine ... possibly dual processor.

John Bass