Hi
In the documentation for the board I am trying to control it states that the SPI bus is directly connected to another master device on that board, so my Arduino Mega 2560 needs to keep the SPI lines tri-stated until Irequest permission from the slave boards processor to take over the SPI bus
I know how to request permission using the i2c interface to the slave board, but what I want to know, is tristate the default condition for the SPI interface on the Arduino until I start using it or do i need to select tristate myself?
I'm hoping I don't need to use some sort of tristate buffer between the Arduino and slave SPI bus, but I guesss if I do I could control it using the Slave Select signal?
The MISO line is the tri-state line in the slave device. It is controlled by the slave select line. If the slave select line is LOW, that slave is driving the MISO line. If the slave select is HIGH, that slave MISO line is hi-z.
OK. What the documentation for the slave device actually says is this:
Bus b. The SPI bus is a direct connection to the SPI bus on the HSMI board. There is no isolation from the Host SPI bus that it
is connected to. As such, the Host must not drive this bus unless permission has been given to the Host by the HSMI microcontroller via
alpha messaging using the i2c bus. The Host must tri-state all SPI control signals when not in control of the SPI bus. Host may use this
interface in Master mode only.
My Arduino Mega 2560 is the 'Host' in this instance. That's why I ask if I need to do anything to explicitly tristate the SPI control signals?
The HSMI board documentation lists MOSI, MISO, CS* and SCK as being 'Bus b' so I assume this applies to all four pins.
I also assume this is so that either my Host or the HSMI board own onboard micro can act as a master on the SPI bus (but not at the asme time)
Sounds like you need to add some buffering between the 2560 and your board for the SCK, MOSI, possibly the SS line, so that SPI master on your board can control the lines as well. The buffer could be enabled with the SS line.
Or, you could look at
SPI.end(); and
pinMode(SCKpin, INPUT);
etc for MOSI, and SS to put the 2560 pins into high impedance mode.
Then turn SPI back on when you want to send data again.
Hi Crossroads
Hmmm if setting the SPI pinMode to INPUT tristates them then that may well do the trick but really I need them in Hi Z mode when the mega 2560 powers up. Are they tristated by default on power up until explicitly set to pinMode OUTPUT?
Otherwise I would probably have to use an external buffer, or start my sketch then reset the slave board (it has a reset* pin) once I tristated those SPI pins (as both devices are powered from the same source so will come on simultaneously) as the device may not boot properly if initially i was holding the SPI bus, that assuming any conflict on the bus would not actually damage anything of course....
All was working on my Uno but now I hae ported the project over to the Due things are not working well
In particular according to my scope the SPI pins on the ICSP header don't appear to be tristated before SPI is started, looks like MOSI is high and SCK is low (or vice versa)
In fact I just went one step further - disconnected my device from the ICSP header - the SPI bus is a lot happier now as the device initialises and self tests OK - though of course I can't control it
So for sure I would say the SPI is not tristating properly like the uno. Why is that?
Can I use some other pins for Due SPI that behave themselves properly like they do on the Uno?
TBH I decided to use the Due as it is native 3.3V and the board I am controlling is also 3.3V so it seemed a better option than using the Uno (or Mega) and then add external level shifting buffers on the SPI. The i2c is 5V tolerant on my device so that is not such an issue
It would be rather ironic if I then had to add external Tristate buffers to the SPI instead
In this case, have you considered using a 3.3v ATmega-based board instead? There are a few Arduino options for running 3.3v. Alternatively, you could build your own. Many people consider it perfectly fine to run 3.3v @ 16MHz on an ATmega328P.
Mostly, I figure if you don't need the horsepower of the Due, then using one (where a simpler micro would work) is a waste of good hardware.
I do remember reading about that somewhere along the track....
I have here an Uno and a Mega 2560 (plus the due). If I can run either of them at 3.3V (pref the 2560 as I may be pushing it a bit on the memory available on the Uno) then please point me in the right direction to do that. I guess its somewhere along the lines involving a 3.3V regulator on the 5V rail but are their other considerations?
Regards 'wasting good hardware' all this is a bit irrelevant really as the differnece in price between the uno and the mega or due (compared to the other hardware costs) makes very little difference to the finished product in this instance....
