I²C register-enabled slave

15 September 2018
This article details the use of register addresses and address/data holds on a PIC16F1828 microcontroller programmed as a stripped-down I²C slave. It was originally part of a work-in-progress firmware for graphical LCD display, but felt that the firmware code for the I²C transactions themselves warranted a stand-alone write-up, especially considering apparent pit-falls when using address holding within I²C reads. Past articles such as the 17-segment LCD display that made use of I²C slave functionality were based around the PIC16F88, which I have decided to retire in favour of microcontrollers within the PIC16F182x chipset family, the latter of which includes the PIC12F1822 used for the I²C-RS232 master. With this in mind I decided to also make the write-up self-contained, by covering setup issues as well.

Overview

For an I²C write transaction — a reception from the perspective of the I²C slave — any I²C register values are simply the first bytes within the transaction. However for an I²C read an initial 1 or 2 byte write needs to be performed, and then the transaction turned into a read using an I²C Restart. The firmware will also make use of three I²C features: Clock steteching, address hold, and data hold, which are detailed below:

Clock stretching: Clock stretching is w when an I²C slave holds SCL (the I²C clock line) low, which causes the I²C master to suspend clocking. This allows the I²C slave to defer the transaction until it is ready to service it.
Address hold: Address holding allows the firmware to decide whether a device address match should be acknowledged, or a NACK sent. If address holding is disabled, the MSSP hardware will automatically acknowledge the incoming address byte.
Data hold: When receiving data, the MSSP hardware automatically acknowledges the received byte before it is passed to the firmware. Data hold allows the firmware itself to decide whether the byte should be acknowledged or not.

The complete firmware is available in Bitbucket, so the code snippets shown below will have simplifications and minor omissions for clarity. The firmware will be updated if the issues highlighted have future work-arounds.

I²C Setup

On Microchip PIC microcontrollers the pins used for I²C communications need to be tristated (i.e. configured as inputs) and set to binary mode. On the PIC16F1828 the I²C pins are RB4 and RB6, so the corresponding bits of TRISB need to be set high, and the corresponding bits of ANSELB cleared.

void pinSetup(void) { TRISB = 0b01010000; ANSELB=0; }

The next stage is to setup I²C itself, which in this case will be I²C slave mode with 7-bit addresses. Clock stretching and data-hold are both enabled, whereas interrupts on I²C Start & I²C Stop are not required. Address-hold is within conditional compilation because it is broken for read transactions.

void i2cSetupSlave(void) { SSP1CON1 = 0b00100110; // I2C slave, 7-bit address, no S/P interrupts SSP1CON2 = 0b1; // Enable clock stretching SSP1CON3 = 0b1; // Enable data-hold SSP1ADD = 0x02; // Slave address #ifdef I2C_ADDR_HOLD SSP1CON3 |= 0b10; // Enable address-hold #endif }

Processing loop

Although it is possible to service I²C transactions from within an interrupt handler, my preferred approach is to instead poll the PIR1 register for pending I²C transactions. If any are pending then bit 0x08 will be set — if this is the case the I²C handling code is executed:

void main(void) { pinSetup(); i2cSetupSlave(); while(1) { if( PIR1 & 0x08 ) { /* I2C interrupt */ i2cOverflow(); if( SSP1STAT & 0x04 ) { i2cSend(); continue; } while( SSP1STAT & 0b1 ) { /* Busy flag set */ i2cRecv(); } } } /* Non-I2C logic here */ }

The first thing to do is to handle any receive overflows. Afterwards if the transaction is a read the slave-to-master handling is called, otherwise the master-to-slave handling runs until there is no more pending data. All these handling routines are detailed in the following sections.

Receive overflow

If the SSPOV (receive overflow) bit of SSPxCON is set, it means that reception of a byte completed before the previous byte had been read by firmware. From what I have read if this happens the buffer needs to be drained and the SSPOV bit explicitly cleared. I suspect that in practice proper use of clock stretching should avoid the SSPOV bit ever getting set, so am not entirely sure whether the recovery procedure below is correct, let alone strictly necessary.

void i2cOverflow(void) { if(SSP1CON & 0x40) { i2cByte = SSP1BUF; SSP1CON1 &= ~0x40; PIR1 &= ~0x08; SSP1CON1 |= 0b10000; return; } }

I²C reads (transmission to master)

It is assumed that an I2C write has already been performed so that the register values have been put into i2cAddr[], but for robustness flags could be added which are invalidated when an I2C Stop occurs. If address hold is enabled the address byte received block is entered twice, the first time being the opportunity to decide whether to ack/nack the address byte, and the second being indication that it is time to send the first byte. The loop lap where the acknowledgement sequence is in progress, and when a Nack has been received from the master, are the two situation when no data is transmitted by the slave.

void i2cSend(void) { PIR1 &= ~0x08; if(! (SSP1STAT & 0x20)) { /* Address byte received */ i2cByte = SSP1BUF; #ifdef I2C_ADDR_HOLD if( SSP1CON3 & 0x80 ) { /* Acknowledge sequence */ SSP1CON2 &= ~0x20; SSP1CON1 |= 0x10; return; } #endif } else if( (SSP1CON & 0x40) ) { /* NACK from Master. Don't send any more data. */ SSP1CON1 |= 0x10; return; } i2cSlaveWrite(i2cAddr[0] + i2cAddr[1]); SSP1CON1 |= 0x10; // End clock stretch }

The final setting of the CKP bit of SSPxCON1 register following the write of the data byte releases the clock line, and hence ends clock stretching, so that the master is able to clock out the next byte. If clock stretching was absent, it is possible that the firmware might not read and handle a received byte before the reception of a subsequent byte has completed. The actual write, which for demonstration purposes uses the sum of the two register address bytes, is done by i2cSlaveWrite() below:

void i2cSlaveWrite(unsigned char bite) { SSP1CON &= ~0x80; SSP1BUF = bite; while(SSP1CON & 0x80) { SSP1CON &= ~0x80; SSP1BUF = bite; } }

The WCOL bit of SSP1CON indicates that a write to the I²C buffer was performed when the I²C hardware was not idle, which due to the logic should only happen if a previous transmission back to master is still in progress. In this scenario the bit is cleared and the write attempted again.

I²C writes (reception from master)

Writes are a bit more complex because they handle the register values, even if the ultimate intention is to read data from the I2C slave — the latter is handled by doing a write that is then flipped into a read using a I2C Restart. The read/write bit of SSP1STAT is used to reset a counter that is used to keep track of the received bytes, so that received bytes are all routed to the right place.

void i2cRecv(void) { PIR1 &= ~0x08; i2cByte = SSP1BUF; if(! (SSP1STAT & 0x20)) { /* Address byte received */ i2cAddrCnt = 0; // This should have no effect with AHEN disabled, // but it is required to recover when DHEN is used // to NACK incoming data. SSP1CON2 &= ~0x20; } else if(i2cAddrCnt < 2) { /* Data bytes that are really register addresses */ i2cAddr[i2cAddrCnt++] = i2cByte; if(i2cByte == 1) SSP1CON2 |= 0x20; else SSP1CON2 &= ~0x20; } else { /* Actual data bytes */ SSP1CON2 &= ~0x20; } SSP1CON1 |= 0x10; }

In the case of a read the Actual data bytes will never be reached as the I²C master should have turned the transaction into a read.

Broken address hold support

If address hold is enabled, the first byte clocked out to the master is the slave address bite-shifted one place (i.e. multiplied by two), rather than the first byte the firmware presents for transmission. This makes the feature functionally useless, because if it is enabled the I²C master has to contend with output that is not expected according to the I²C specifications. Much investigation has not revealed any mistake that would result in such non-standard output, so I can only conclude this is the result of a hardware bug — a drastic conclusion, but one dictated by circumstances.

In practice I am not interested in I²C transactions the hardware address matching & masking does not already exclude, but in the I²C read pipe-line the ability to Nack the device address is the only opportunity a I²C slave has of rejecting an incoming read transaction. The alternative is to serve garbage values in error conditions, which is far from elegant, and likely results in trouble elsewhere. I expect this to come back to sting me.

I2C register-enabled slave