… because, why not?

A few months back, I found myself in a position where I needed to develop a proof of concept for a CAN bus data logging system, but the hardware hadn’t been finalised. At the time, there were talks of using x86-based hardware, which would eventually communicate with the CAN bus via an SPI CAN controller. Unfortunately the dev board was on back-order and I wanted to keep the project moving.

So I went digging through the store-room and found a laptop. This was a good start, but how to interface with the CAN bus? There are lots of USB CAN bus dongles available, but this wouldn’t give me a true representation of the final hardware that was going to communicate directly with CAN controller ICs and I already had a nice MCP2515 breakout board that would serve this purpose. The ‘eureka’ moment was when I remembered something my tutor had said during my MSc. He was talking about x86 systems, and he made a throw-away comment about using the old parallel printer ports for GPIO. Not hardware SPI, but GPIO at least meant I could bit-bang the protocol. More digging in the store-room and I found a docking station for the laptop which had a LPT port.

History lesson

For those too young to remember, in the olden days, before the introduction of USB, printers used to be connected to computers using a parallel port called a Line Print Terminal (LPT) port. Some machines still have them – it’s that big pink Dsub you don’t use on the back of your machine

This huge 25-pin cable was used to send characters to the printer 1 byte at a time by setting 8 data pins.  Various handshake pins were used to control the flow of data. http://retired.beyondlogic.org/spp/parallel.htm (now dead) explained the process in great detail, and helped me out a lot in understanding how to control the port in software. It turns out the printer port is directly accessible at the base address of 0x378 using the stdio outb() and inb() function calls. The individual pins can therefore be set or read by sending the appropriate binary value to the corresponding address. Some pins are read-only and some are write-only, but there were more than enough for an SPI implementation. The following tables, originally taken from the beyondlogic page, show this in more detail:

Table 1. Pin Assignments of the D-Type 25 pin Parallel Port Connector.

Pin No (D-Type 25)	Pin No (Centronics)	SPP Signal	Direction In/out	Register	Hardware Inverted
1	1	nStrobe	In/Out	Control	Yes
2	2	Data 0	Out	Data
3	3	Data 1	Out	Data
4	4	Data 2	Out	Data
5	5	Data 3	Out	Data
6	6	Data 4	Out	Data
7	7	Data 5	Out	Data
8	8	Data 6	Out	Data
9	9	Data 7	Out	Data
10	10	nAck	In	Status
11	11	Busy	In	Status	Yes
12	12	Paper-Out / Paper-End	In	Status
13	13	Select	In	Status
14	14	nAuto-Linefeed	In/Out	Control	Yes
15	32	nError / nFault	In	Status
16	31	nInitialize	In/Out	Control
17	36	nSelect-Printer / nSelect-In	In/Out	Control	Yes
18 – 25	19-30	Ground	Gnd

“The above table uses “n” in front of the signal name to denote that the signal is active low. e.g. nError. If the printer has occurred an error then this line is low. This line normally is high, should the printer be functioning correctly. The “Hardware Inverted” means the signal is inverted by the Parallel card’s hardware. Such an example is the Busy line. If +5v (Logic 1) was applied to this pin and the status register read, it would return back a 0 in Bit 7 of the Status Register.The output of the Parallel Port is normally TTL logic levels. The voltage levels are the easy part. The current you can sink and source varies from port to port. Most Parallel Ports implemented in ASIC, can sink and source around 12mA. However these are just some of the figures taken from Data sheets, Sink/Source 6mA, Source 12mA/Sink 20mA, Sink 16mA/Source 4mA, Sink/Source 12mA. As you can see they vary quite a bit. The best bet is to use a buffer, so the least current is drawn from the Parallel Port.”

Table 4 Data Port

Offset	Name	Read/Write	Bit No.	Properties
Base + 0	Data Port	Write (Note-1)	Bit 7	Data 7
			Bit 6	Data 6
			Bit 5	Data 5
			Bit 4	Data 4
			Bit 3	Data 3
			Bit 2	Data 2
			Bit 1	Data 1
			Bit 0	Data 0

“The base address, usually called the Data Port or Data Register is simply used for outputting data on the Parallel Port’s data lines (Pins 2-9). This register is normally a write only port. If you read from the port, you should get the last byte sent. However if your port is bi-directional, you can receive data on this address.”

Table 5 Status Port

Offset	Name	Read/Write	Bit No.	Properties
Base + 1	Status Port	Read Only	Bit 7	Busy
			Bit 6	Ack
			Bit 5	Paper Out
			Bit 4	Select In
			Bit 3	Error
			Bit 2	IRQ (Not)
			Bit 1	Reserved
			Bit 0	Reserved

“The Status Port (base address + 1) is a read only port. Any data written to this port will be ignored. The Status Port is made up of 5 input lines (Pins 10,11,12,13 & 15), a IRQ status register and two reserved bits. Please note that Bit 7 (Busy) is a active low input. E.g. If bit 7 happens to show a logic 0, this means that there is +5v at pin 11. Likewise with Bit 2. (nIRQ) If this bit shows a ‘1’ then an interrupt has not occurred.”

Table 6 Control Port

Offset	Name	Read/Write	Bit No.	Properties
Base + 2	Control Port	Read/Write	Bit 7	Unused
			Bit 6	Unused
			Bit 5	Enable Bi-Directional Port
			Bit 4	Enable IRQ Via Ack Line
			Bit 3	Select Printer
			Bit 2	Initialize Printer (Reset)
			Bit 1	Auto Linefeed
			Bit 0	Strobe

“The Control Port (base address + 2) was intended as a write only port. When a printer is attached to the Parallel Port, four “controls” are used. These are Strobe, Auto Linefeed, Initialize and Select Printer, all of which are inverted except Initialize.”

Hello World

To test this, I created a quick set-up with an LED connected between pin 9 of the connector (Data 7) and pin 18 (ground) so:

---

[code language=”cpp” light=”true”]
#include <stdio.h>

/* Flashes the LED – the ‘Hello World’ of embedded systems */
void testLed(void){
while(1){
/* Set data 7 high */
outb(0x378,0x80);
sleep(1);
/* Set all data pins low */
outb(0x378,0x00);
sleep(1);
}
}
[/code]

---

will toggle the LED every second.

I tested the ability to read the pins by setting pins and reading back their values:

---

[code language=”cpp” light=”true”]
#include <stdio.h>

#define LPT_PORT_BASE 0x378
#define LPT_PORT_DATA (LPT_PORT_BASE + 0)
#define LPT_PORT_STAT (LPT_PORT_BASE + 1)
#define LPT_PORT_CTRL (LPT_PORT_BASE + 2)

/* Sets the data pins one by one, then clears them
* Outputs the value read from the port */
void lptTestPort(void){
uint8_t in = 0, i = 0, out = 0;

printf(“Testing Output on parallel port data pins\n”);

in = inb(LPT_PORT_DATA);
printf(“S = 0x%02X\n”, in);

for(i = 0; i < 8; i++){
out |= (1<<i);
outb(LPT_PORT_DATA, out);

in = inb(LPT_PORT_DATA);
printf(“%u = 0x%02X\n”, i, in);
}

for(i = 0; i < 8; i++){
out &= ~(1<<i);
outb(LPT_PORT_DATA, out);

in = inb(LPT_PORT_DATA);
printf(“%u = 0x%02X\n”, i, in);
}

in = inb(LPT_PORT_CTRL);
printf(“Ctrl = 0x%02X\n\n”, in);
}[/code]

---

Then I wrote some simple functions to control and read the individual data pins:

---

[code language=”cpp” light=”true”]
/* Sets a specified pin in the data register */
void lptSetDataPin(uint8_t pin){
dataPortShadow |= (1<<pin);
outb(LPT_PORT_DATA, dataPortShadow);
}
[/code]

[code language=”cpp” light=”true”]
/* Clears a specified pin in the data register */
void lptClearDataPin(uint8_t pin){
dataPortShadow &= ~(1<<pin);
outb(LPT_PORT_DATA, dataPortShadow);
}
[/code]

---

dataPortShadow is used so that we don’t have to read back the value of the port each time we change the value of an output to do so would double the time taken to change the state of a pin and drastically impact timing (see “Limitations” below). Since the data port is output-only by default, I used the status port for input pins. It’s meant to be possible, with some machines, to change the data port to bi-directional by setting bit 5 of the control port, but I didn’t have any luck with this (and it wasn’t a pressing issue since I had plenty of spare pins).

Bit-banging SPI

Once I had control over some IO, I needed to talk the SPI protocol. In modern microcontrollers, there is a hardware peripheral built-in that is accessed by writing to or reading from certain registers. The peripheral then controls and reads IO pins according to the SPI protocol. I don’t have the luxury of an SPI peripheral but, luckily, the the protocol is really straightforward.

There are 4 signals in SPI:

• Slave select (SS) – This is used when there are multiple devices on the same SPI bus
• Clock (SCLK)
• Master In, Slave Out (MISO)
• Master Out, Slave In (MOSI)

The master (our software) controls the CS, CLK and MOSI signals and the slave (the CAN controller in this case) controls the MISO signal. In order to send data to the peripheral, we first pull the CS pin low, and then ‘clock out’ the necessary data. Every clock pulse indicates a bit of data, and the state of the MOSI signal represents its value. The CS pin is set high when transmission has finished. For example, the following signals (assuming msb first) will send a 16 bit value of 52045 (0xCB4D):

Receiving data is performed in the same way, except we read the value of the MISO each time we cycle the clock signal.

The protocol can be controlled by manually setting / clearing the appropriate pins and reading the values of other pins that the CAN controller is setting. The process of doing this with GPIO is known as ‘bit-banging’:

---

[code language=”cpp” light=”true”]
/* Simultaneously sends a byte to the SPI slave
* and reads one back (standard SPI implementation) */
uint8_t SPIExchange(uint8_t spiByte){
int i;
uint8_t byteIn = 0x00;

for(i = 7; i >= 0; i–){
lptClearDataPin(IO_SPI_SCK);
byteIn >>= 1; /* I need this comment so WordPress doesn’t break my line endings >>*/
byteIn |= lptReadStatusPin(IO_SPI_MISO);

if((spiByte>>i) & 0x01){
lptSetDataPin(IO_SPI_MOSI);
}
else{
lptClearDataPin(IO_SPI_MOSI);
}
lptSetDataPin(IO_SPI_SCK);
}

return byteIn;
}
[/code]

[code language=”cpp” gutter=”false”]
/* Sends a byte to the SPI slave */
void SPISendByte(uint8_t spiByte){
int i;
for(i = 7; i >= 0; i–){
lptClearDataPin(IO_SPI_SCK);
if((spiByte>>i) & 0x01){
lptSetDataPin(IO_SPI_MOSI);
}
else{
lptClearDataPin(IO_SPI_MOSI);
}
lptSetDataPin(IO_SPI_SCK);
}
return;
}
[/code]

[code language=”cpp” light=”true”]
/* Reads a byte from the SPI slave */
uint8_t SPIReadByte(void){
int i;
uint8_t byteIn = 0x00;

for(i = 7; i >= 0; i–){
lptClearDataPin(IO_SPI_SCK);
byteIn <<= 1;
byteIn |= lptReadStatusPin(IO_SPI_MISO);
lptSetDataPin(IO_SPI_SCK);
}

return byteIn;
}
[/code]

---

Putting it all together

From here, it was a case of using code I already had for the MCP2515 on a PIC32-based system, with a couple of glue functions to complete the interface. I made the following connections:

SCK	Pin 8 (Data 6)
MOSI	Pin 9 (Data 7)
MISO	Pin 10 (Status ACK)
SS	Pin 7  (Data 5)

I powered the CAN breakout from a USB port and added a pull-up resistor to the reset pin (RST) to keep it out of reset mode. A 120 Ω termination resistor was also needed between the CAN H and CAN L terminals.

Limitations

As a proof of concept, this worked great, however the main limitation is the speed of the parallel port. I measured the time taken to toggle access the port at around 1 μs. This gives a maximum SPI clock speed of 333 kHz for SPISendByte() or SPIReadByte() and 250 kHz using SPIExchange().

In my data-logging application, the most used SPI transactions with the MCP2515 are RX STATUS (to check for new messages) and READ RX BUFFER for each message received (the CAN controller can hold 2 messages at a time).

---

[code language=”cpp” light=”true” highlight=”4,5,6,7″]
/* Reads the status of the two MCP2515 Rx buffers */
unsigned char CANReadStatus(unsigned char statReadChannel){
unsigned char Status;
SelectCANChip(statReadChannel); /* Pulls CS pin low */
SPISendByte(CAN_RD_STATUS); /* Command */
Status = SPIReadByte(); /* Response */
DeselectAllCANChips(); /* Sets CS pin high */
return Status;
}
[/code]

---

---

[code language=”cpp” light=”true” highlight=”3,8,9,10,11,12,13,19,24″]
/* Reads a specified Rx buffer from the MCP2515
*
* CS pin pulled low prior to entering this function */
static void RxCANbuffer(unsigned char bufferID, CANdataBuffer_t *buffer){
int i;
unsigned char TmpRxAddress[4];

SPISendByte(bufferID); /* Command */
TmpRxAddress[0] = SPIReadByte(); /* The first 4 bytes are the frame ID */
TmpRxAddress[1] = SPIReadByte();
TmpRxAddress[2] = SPIReadByte();
TmpRxAddress[3] = SPIReadByte();
buffer->CANdlc = SPIReadByte(); /* Data Length Character */

if(buffer->CANdlc > 8){
buffer->CANdlc = 8;
}

for(i = 0; i CANdlc; i++){
/* CAN data */
buffer->CANdataRx[i] = SPIReadByte();
}

buffer->CANid = RegsToCANID(TmpRxAddress);
}
/* CS pin set high after leaving this function */
[/code]

---

I started out using SPIExchange() for all transactions (most standard microcontroller SPI implementations use this method), but I found there were massive overheads that could be saved by using the individual send and read functions. To read a CAN message from a buffer on the MCP2515 takes 16 SPI clocks for RX STATUS plus 112 SPI clocks per CAN message (1 byte for instruction and 13 bytes of received data for an 8 byte frame). Plus the time taken to toggle the CS pin.

Using SPIExchange (4 port accesses per clock), the worst case timing (two 8-byte CAN frames waiting) equates to (16 * 4)  + (112 * 4)  +  (112 * 4)  +  6 =  996 μs.

Using the individual send and receive functions (3 port accesses per clock) this is reduced to (16 * 3)  + (112 * 3)  +  (112 * 3)  +  6 =  726 μs.

Logging data at this rate wasn’t ideal, but it did allow me to integrate my proof of concept with low-level CAN handing code, and work with real data transmitted from a PCAN dongle on another machine without relying on a 3rd party library that wouldn’t make it into the production implementation.