40X2 SPI and I2C in same program/design?

[ad8bc]

Just a quick question as I haven't tried it yet (still waiting for my DS1307 to get here). Since the pinout on a 40X2 uses the same pins for the hspi and hi2c communications, is it possible to use an SPI and an I2C device in the same setup?

In other words, I would like to have a MAX7219 and a DS1307 in the same program (to display time and temperature on a LED display). Will this work?

I understand that the SPI communications use a pulsed load signal after the serial data is sent, and the I2C does not. This would keep the SPI device from responding to I2C data, but I can see the I2C device getting confused from the data going to the SPI device.

If it can't I suppose it's not the end of the world, I could do manual SPI (like you would with the 08M) on another pin... just curious if they play nice on the same bus.

Thanks!

 

[inglewoodpete]

Since the pinout on a 40X2 uses the same pins for the hspi and hi2c communications, is it possible to use an SPI and an I2C device in the same setup?

If it can't I suppose it's not the end of the world, I could do manual SPI (like you would with the 08M) on another pin... just curious if they play nice on the same bus.

Trying to do hspi and hi2c comms on the one 40X2 is likely to cause interference between the slave devices operating on different protocols.

One option would be to use something like a CD4066 as a bus switcher. You would have to disable one protocol and swap busses before enabling the other.

I think a better solution would be to use the hi2c on the designated pins and use spiout/shiftout or spiin/shiftin on other pins. Have a look at the command description/s to see how you can link the the spi commands to a range of pins. While these commands do not use the dedicated serial hardware, the bit-banging is done in firmware and is quite quick and efficient.

I also suggest you breadboard your solutions to ensure you get the result you want.

 

[ad8bc]

Thank you Pete!

I thought I remembered seeing an SPIOUT and SPIIN command but I didn't see them in the index in Part 2 of the manual. As soon as you mentioned shiftout and shiftin it occured to me that those were the same commands... Thanks, this should work.

For development I am using the AXE091 PICAXE development board, which is very nice. I have done plenty of breadboarding in my past and it is nice to have the basics all in one place. I made a few DIP ribbon cable assemblies to interface to my big breadboard when necessary.

 

[hippy]

In theory it's possible to have I2C and SPI on the same bus. SPI is easy to set to 'ignore things' ( set device's CS as appropriate ) and all you have to do is ensure the pattern on the bus never matches I2C Start or invites an I2C device ACK.

Unfortunately PICmicro, and therefore PICAXE, hardware tends to share I2C SDA and SPI SDI pins which can make this difficult.

Most mixed-bus systems I've seen which claim to work use bit-banged I2C and SPI with careful choice of which signal lines are shared to ensure it works.

The simplest solution is to put one on a hardware bus the other on a bit-banged bus. Using hardware I2C and SPIIN/SPIOUT is likely the best option for PICAXE.

 

[BeanieBots]

It should be possible to take a similar approach with many IC2 devices, ie. dissable them. For many EEPROMs, that too would be a CS line.
For a DS1307 RTC, if you have it battery backed, it should be possible to run its Vcc from a PICAXE output. Thus, by effectively removing power, it will ignore I2C bus commands. Never tried it and there is the possibility that it might pull the lines low when not powered but something to maybe test on breadboard.

 

[knight]

What about logic gates?

You could put two AND gates fed off the pin that has the common bus, then run the second pins of each of the AND Gates to enable pins of the picaxe, something like this:

                           ______
     SPI enable |---------|     )____SPI Chip
                |-    |---|and )
            BUS |-----|    ___
                |-    |---|    )____I2C chip
     I2C enable |---------|and)

For those that don't know, an AND gate only goes high on the output when BOTH inputs are high. So therefore as long as only one of the enable pins is high, only one of the chips will see it.

This method could also be used to have more than 8 I2C chips on a single I2C line.

If you ignore the crude drawing do you understand the sort of idea i'm getting at?
(if i have a chance later tonight i'll do it up in a drawing package, see if i can't get a better looking circuit)

 

[knight]

Further my last, if you were going to do that you would also need to put an AND gate on the clock with the inputs tied together, just to ensure the propogation speed is the same on the clock and data busses.

 

[MBrej]

You could just use the SPI version of the DS1307, the DS1306, or a DS3234 which has an integrated crystal if you dont mind surface mount

 

[hippy]

Logic gates could work but you also have to take into account the I2C bus default logic levels ( active low ), the 'open collector' nature of the bus and potential failure modes, and on top of that you need a good analysis to prove that transitions when enabling and disabling the bus don't create I2C signals which can confuse or lock-up an I2C device. Also, when in I2C mode the SCL line to the controller chip is likely 'open collector' though this could just be a matter of adding an appropriate pull-up.

It's not so much that it cannot be done, more a case of proving a design does work in all situations.

There are I2C-to-SPI bridges which allow SPI devices to be controlled from an I2C bus.

I think the most telling thing is that manufacturers who support I2C and SPI don't have examples, application notes and 'tips and tricks' on how to share the bus between both. If it were easy one would expect there to be more examples showing 'how to' than there are, and fewer specialised devices produced to get round the problems. Perhaps it's that there is no 'general case solution' though there may be solutions for specific implementations.

 

[BeanieBots]

I'm not convinced that a logic gate solution is possible but you never know!
I would like to see a possible solution explained that takes into account both the need for open collector drive and cater for the I2C bi-directional requirement. There are of course chips designed for just that function.

 

[ad8bc]

You could just use the SPI version of the DS1307, the DS1306, or a DS3234 which has an integrated crystal if you dont mind surface mount

I like that DS1306! Looks very flexible... I wonder why it isn't as popular as the DS1307, SPI is easy, been playing with it lately... I suppose I2C is easy too, haven't messed with it.

DIP DS1306 is $5.42 at Mouser. I may have to try this.

 

[hippy]

SPI may be less popular than I2C generally as it can get a bit more complicated with SPI devices. "SPI" is pretty much whatever any manufacturer decides it will be whereas I2C is much more rigorously defined.

Each SPI device needs its own chip select, there may be different data clocking schemes for different devices, different bit ordering, weird clocking protocols, may require a three-wire bus or a more complicated two-wire bus, or a three-wire bus converting to two and vice-versa.

For single devices it's not much of a problem, but as you add more there's a greater chance you'll find some potential conflicts and complexity.

 

[knight]

I'm not convinced that a logic gate solution is possible but you never know!
I would like to see a possible solution explained that takes into account both the need for open collector drive and cater for the I2C bi-directional requirement. There are of course chips designed for just that function.

Your right, now that i'm awake and thinking about it more clearly it probably wouldn't work, or would be overly complex to implement. (It may yet work for multiple busses of I2C memory chips but then it would be activating the power rather than the input of the chip)

I had forgotten the bi-directional requirements, which would nessesitate AND gates in the opposite direction. (In my defence I'm not getting much sleep as i'm fighting with an FPGA (Altium nanoboard) to get it to do what i want in VHDL...oh what i would give to be allowed to code in C)