I2C or SPI

[BeanieBots]

I've been searching for some peripheral chips and have found many are available as either SPI or I2C comms.
The majority appear to offer faster comms when SPI is used.
However, what is the situation with PICAXE?

Which would be faster?
Any problems likely to be encountered by having a mix?

 

[Technical]

i2c can only be carried out via the on-board hardware module (hi2cin/out)

spi can be bit-busted (spiin/out) or use on-board hardware module (hspiin/out)

Hardware module is much faster than bit busted, but the difference between hardware spi and i2c is not really that significant, as the actual in/out in both cases is done by the hardware module (in the background to the PICAXE program). As the same on-board hardware module is used for both i2c and spi then it is certainly not a good idea to mix the technologies.

However you can bit-bust spi and hardware i2c without problems.

 

[BeanieBots]

Ok, thanks for the quick response.
So, in brief, if a device datasheets states:-
"up to 400kHz I2C or 15Mhz SPI"
then I'd not see much difference either way? (uFPU V3)

My application requires RTC, EEPROM, uFPU and some as yet undefined sensor interface devices.
I already have I2C RTC & EEPROM, the uFPU can work as either so looks like the choice for the other devices has to be I2C.

 

[Technical]

Basically the defining factor is the PICAXE speed of command processing - as long as the background hardware module can spit out the data quicker than the next PICAXE command is retrieved then there is no real difference in speed when using the PICAXE system - you will not reach the maximum spi/i2c speeds if the PICAXE cannot go that fast anyway!

 

[kranenborg]

The big difference between I2C and SPI is that SPI is faster but generally requires an explicit CS (Chip Select) signal for each device in order to address it, which may lead to complicated hardware in case a large number of devices are involved. The I2C software protocol includes the device address, making the hardware much simpler.

/Jurjen

 

[BeanieBots]

as long as the background hardware module can spit out the data quicker than the next PICAXE command is retrieved

I think that is probably the core of my (not directly asked) question, which you have now answered.

@kranenborg,
Good point. I'm not short of pins so could easily dedicate one to each device. I'd guess that a "high device2, low device1" would be on a par with a new hI2Csetup command but that's fairly insignificant compared to the large amount of data that would need to be sent between the PICAXE and the uFPU.

Guess it's time to build and find out!

 

[BCJKiwi]

If there are any devices that are only available in one format - use that for all. This often means i2c.
i2c is simpler (in my view) to use and requires fewer pins on the PICAXE but may require more pins on the device/PCB (address setup).

Ran some tests on cycle time with i2c slow and i2c fast in a (28x1 @ setfreq em16) program with seven i2c devices in circuit.
Cycle time was virtually identical with both fast and slow (couldn't really measure the difference over many cycles). While the bus was running quicker, all the other stuff in the code and the response time of the devices totally swamp the speed gains potentially available from the external bus speed.

Small code changes had significantly greater effect on cycle time!

This might be different if the code was very short and the i2c reads were in a tight loop with a fast responding i2c device.