Moteino and SPI

[sketchy]

I have been testing JeeLab's RFM12B board wired to an Arduino Uno and an Adafruit cc3000 board.  There is a conflict between the two over the SPI bus (can't get data when both have been initialized then sends/receives data to a node).

I would like to try the Moteino in replacement of the RFM12B board.  However,  I am concerned there will still be SPI conflicts.

What advice do you have about using the Moteino with Adafruit's cc3000 board?

Thank you.

[Felix]

What are the SPI requirements of the cc3000?

[sketchy]

What requirements do you mean?  I can set the SS/CS to any pin... I can give you more specifics - I apologize.  I just don't know which requirements.  (sorry!)

[Felix]

As long as CS is different than D10 you should be all set.
D2 is used by the RFM interrupt.
D8 is also used by FLASH MEM if you get that option.
Otherwise there should not be any issue, you can use any other pin for your CC3000 SPI CS line.

The CC3000 might draw lots of power so you might want to watch that.

[sketchy]

Thanks for the response.  My concern is I am finding a conflict between cc3000 and rfm12b - isn't the rfm12b very similar?  So if I'm having a conflict with the rfm12b - wouldn't i see the same thing?

[Felix]

What kind of conflict?

[priority]

Are you using the Adafruit CC3000 breakout or the shield?  I will hazard a guess that you are using the breakout and have run into a "feature" of the CC3000 that I find extremely annoying.  Seems that TI's engineers forgot to test what happens with more than 1 device on a SPI bus and the CC3000 does not tri-state MISO (data out) from the CC3000 when its CS is low.  The second schematic on http://learn.adafruit.com/adafruit-cc3000-wifi/downloads shows a work-around to deal with this "feature" using a 74AHC1G125 (which I must admit is a rather cute little chip in its own right).

[Felix]

Oh .... could that be it? I've seen that happen on cheap chinese crap SPI LCDs. Not on expensive brand devices. I would just use large value resistors to pull down MISO.

[sketchy]

Yes. the challenge is after a call to cc3000.begin(), the cc3000 leaves MISO high instead of floating. (using breakout) I found a software workaround (I am better at software then electronics).  Just ordered a level shifter to see if I put that in the RFM12B can pull down the line.

I document this challenge on this post:  http://bitknitting.wordpress.com/2013/12/02/debugging-the-spi-bus-when-components-wont-share/

Isn't this something TI should fix?

FELIX: regarding using large value resistors (I am new to electronics).  I thought using a 74LVC245 might be a better choice?  I thought this because I read somewhere that using resistors would cause too much fluctuation? What are the tradeoffs?  ( a big goal of my efforts is to learn as much as I can about electronics).

I want to use the RFM69.  This might fine at the nodes with the Moteino.  It is at the base system - the one that reads in the sensor data then sends the data to a cloud service.  On the base system I need more than 2K of SRAM...the

[Felix]

I was referring to pullups, not level shifting. I solved such SPI conflicts with pullups or pulldowns depending on situation. Some SPI devices leave MISO floating and cause conflicts when other SPI devices are trying to communicate with the master. So the pulldown/up resistors (10k or more is fine) would make sure that line won't float and garble SPI communications from other devices. 10K resistor pull resistors are enough to keep that from floating, but weaker than a normal SPI device that will pull the data line up/down for the communication.

[sketchy]

But isn't correct behavior for an SPI device to put CS to high and MISO to floating when not using?
e.g.:
SS taken high to indicate end of the sequence of data. At this stage the slave should release the MISO line (configure it as an input, or "high impedance"). Also the slave should ignore any clock pulses now (they may be for a different peripheral).

From: http://www.gammon.com.au/forum/?id=10892

(Just trying to make sure I understand.  I don't feel confident in my knowledge of electronics.)

[Felix]

I would just say that a SPI device should not interfere or garble MISO when another device is talking (ie when the CS line is not asserted).

[scott216]

Does the RFM69 module in the Moteino tri-state the MISO line?  I'm using a moteino with an Ethernet module, so I've got two devices on the SPI buffer: the radio in the Moteino and the RFM69 module.  I came across this article that suggests adding a buffer chip to make sure MISO is tri-stated.

[Felix]

I am not sure. It will work with other SPI devices as long as separate CS pins are used, and the SPI comm doesn't step on each other.

[scott216]

I'm using my Moteno with a Wiznet 5100 Ethernet module and the Ethernet module SS is on pin D9, so It's separate from the RFM69 SS pin which is pin D10.  It does work ok, but it will hang every now and then.