20X2 and Mixing SPI and I2C

Marcwolf

Senior Member
Hi Folks

And interesting question.. I have 2 devices. One chats via I2C and the other via SPI.

Now I doubt that I will be chatting with both devices at the same time but..... It is possible to swap between Hi2C and HSPI and back again without causing too much difficulties.

I have a AXEerr.. 21 servo controller (I know it better as a SD21), and I am looking at a max7456 video overlay.

Some time back I experimented with sterioscopic video with 2 mall camera's and z ipod video glasses merged together. It worked really well once one had the camera's aligned (before that was definately nausea time) however by using the max7456 could mean I can get feedback on a lot of different functions

Any idea's

Dave
 

westaust55

Moderator
Here is what BCJKiwi had to say on that subject back in Nov 2007:
Hi2c and HSPI
Also have found that working with hi2c and hSPI on the same bus system does have some issues.
Have a DS1307 Clock utilising hi2c and the VDrive2 utilising hspi.
It appears that each time you switch from the i2c device to the spi device then the hspisetup initialisation commands need to be reissued before the VDrive2 can be accessed. I do not know if this behaviour is specific to the VDrive2 as it is the only SPI device I have tested.

So I have 2 options for data logging on this project
Find another removable storage device, or, find a practical way to use two separate serial devices via hserial off the same 28X1 while both are active.
Though there was a relatively recent thread covering some of the issues that may arise but not readily found.
 

hippy

Technical Support
Staff member
Using I2C and SPI on the same bus is possible but it comes with a lot of potential difficulties and probably amounts to more effort than it's worth. The best solution is to kep I2C using the hardware interface, bit-bang a software interface for the SPI.
 

Marcwolf

Senior Member
Hi WestAust and Hippy

Many thanks for the advice. I might look at the SPI further down the track or drop in a dedicated processor just for that and chat via picAxe to pixAce communications.

Still - if all I am using the SPI for is to send data re a OSD then there is not too much issue re doing a reset of the SPI side of things each time I need to send something.

My critical timeslice is 250ms and that is a LONG time in PicAxe code


Again thanks for the input

Dave
 

BCJKiwi

Senior Member
It is possible but not simple.

The 28X's share one of the pins for both protocols. Code needs to be carefully checked to ensure there is no conflict.

Provided they protocols are not used at the same time it will work as i2c uses chip addressing through the protocol where SPI uses a separate chip select line (one for each chip connected).
 
Last edited:

westaust55

Moderator
Since it is an X2 parts you can use the SHIFTIN and SHIFTOUT commands.

These commands, although a form of bit-bang on X1 and X2 parts to normal IO pin, use less memory space than a complete bit-bang approach as is given at the bottom of the pages for the two mentioned commands in PICAXE BASIC and are a also (from my past testing) faster.
 

hippy

Technical Support
Staff member
Good suggestion by westaust55.

The problem isn't so much that I2C and SPI cannot share a bus but that interactions on the bus intended for one can affect the other. That's not so bad for SPI when the device can be disabled using chip select so it simply ignores anything happening on SDA/SCL.

I2C however will see all bus activity and if there is any which makes it think it's seeing I2C for itself it may interfere with the bus and confuse the SPI device. Also SPI is driven hard, high and low, whereas I2C is open collector. If an I2C device tries to talk back while SPI is active it pulls the SDA line low ( possibly SCL as well ) and that's shorting a PICAXE high output direct to 0V which is not a good idea. Run the bus too fast and the I2C may misinterpret what it sees and think it's activated when it isn't.

It can be done, and will work as long as there are no glitches or cross-interference. Guaranteeing and proving that's the case is the hard part.
 

Marcwolf

Senior Member
Again thanks for the information.

Fortunately the SPI will only be going OUT, rather than reading IN.

The I2C will both way, athough the times when I will be reading back in will be very infrequent and under control. i.e. Reading the battery voltage

Take Care

Dave
 
Top