At Bluefruit, we would classify ourselves as I2C and SPI programming experts.

We have implemented dozens of projects using these technologies and are aware of the pitfalls and strengths of these design routes.

When making a choice between the buses, the first consideration must be about the availability of a hardware synchronous serial port. If one is available, does it support SPI or I2C (or both)?

I2C programming can be tricky even if in the presence of a hardware port. A few common questions or concerns are:

●    Is the hardware port fully I2C compliant?
●    What speeds does the port support?
●    Does the port support multi-master?
●    Do you need multi-master support?
●    Does the port support clock-stretching?
●    Do you need clock-stretching?

Another area of I2C that can be troublesome is slow rates.

It can very difficult to get your pull-up resistor values correct. That’s why Bluefruit always allocate ample time for testing, particularly if the I2C bus connects between a number of boards.

SPI programming has its own set of pitfalls, with the single biggest SPI programming problem being the lack of official specification.

For example, if you have two SPI devices provided by different manufacturers, then the chances are that you will not be able to hang them off the same bus.

There are many variables in SPI programming including:

●    Clock polarity,
●    Clocking on rising or falling edges
●    Timing of Slave Select lines, number of bits
●    Time between bytes

Incompatibility, flexibility and data speeds can all be regular concerns for any developer working with SPI devices, and we have experience identifying, implementing and testing a whole host of potential pitfalls and delivering solutions.