Does pinMode 'input' state place pin in tri-state mode for SPI multi device connectivity?

Wed 2019.07.10

Is the pin in tri-state mode?

pinMode 'input' - Digital input:

http://www.espruino.com/Reference#l__glo­bal_pinMode

implies 'Yes' as the other two choices 'input_pullup' and 'input_pulldown' specify resistances.

p.31 Sec 3.27 of STM32 datasheet

' as input (floating, with or without pull-up or pull-down) '

http://www.espruino.com/datasheets/STM32­F401xD.pdf

Arduino documentation is specific, e.g. Yes for input mode.

https://www.arduino.cc/en/Tutorial/Digit­alPins

The real question, when connecting multiple devices using SPI, does the device acting as a slave, or a device no longer acting in SPI mode, pins have to be placed in the 'input' mode when at idle?

pinMode 'input' - Digital input: Is the pin in tri-state mode?

Yes - it is just leaving the input floating.

I'm not entirely sure what you're trying to do though? In SPI you have 3 pins:

• CLK - master -> slave
  
• MOSI - master > slave
  
• MISO - slave -> master
  
• And often chip select, which is also master-> slave
  
  

The master never has to change the state of any of its pins, and Espruino can only be an SPI master so I don't think you have a problem.

It's actually not a good idea to leave SPI pins from a master tristate since electrical noise could then potentially send random data to the SPI slave(s).

If it were an SPI slave then yes, as I understand it the device would have to tri-state its MISO pin when the chip select was high (unselected), but I believe that's something that is done in hardware

Thr 2019.07.11

Thank you for the quick reply @Gordon.

'Espruino can only be an SPI master'
'If it were an SPI slave then yes'

Seems contradictory. Is it? I am trying both M>S and S>M

Should I not be able to apply the suggestion to tri-state the MISO pin, then I may have to fall back to using the USART. Just trying different methods to serially talk to different devices, using means other than Tx<>Rx

Just realized that Espruino devices are not meant to be slaves as they don't function in the same capacity as might an EEPROM or GPS unit. Still will try though.

@Robin, just give up... Why: The CLK line... it is unidirectional. Only the Master drives it...

Fri 2019.07.12

Ouch!, . . that's brazen, especially from someone that I know doesn't give up easily. ;-)

Have a circuit where two micros will be sharing the workload, and attempting to signal each other with say a DTR line. Didn't want one to drag down the other, should the former master still have, say have the clock or MISO line tied to one state, while the other takes control as new master. Idea was to place the lines in a tri-state mode to hand off to new master.

@Robin, to understand your context:

• You have multiple SPI slaves all on one bus - like all kind of sensors and control devices / servos / a like.
  
• You think you need multiple processors / worker because of he work load all these slaves cause.
  
  

As a question: what is driving the work?

• Timers - timers that trigger a process

  • to command a slave to do something, where determining what the slave has to do could take a lot of computing resources / time
    
  • to command the slave to respond and that the handling of the response could take a lot of computing resources / time
    
    

• Interrupts from slaves (on separate lines)

  • that ask the master for communication with the slave for doing work similar as listed under Timers ... above.
    
    

All this sounds to me a bit fictitious... to say the least.

Solution could be to setup multiple MCs as masters of which each is controlling its own bus with the type and amount of slaves it can handle, and another MC - if needed - to oversee / coordinate / collect from these individual MCs on a high level.

Back to SPI: since SPI is by definition a Single-Master-Multi-Slave- BUS, trying to put more than one master on the bus is a mis-design - or wrong choice of communication vehicle: SPI is just not applicable for such needs.

If work as listed above has to be done and only one bus has to be used, the solution could be a single master that takes care of only the communication. This Communication MC has to work of a queue for talking to the slaves and then place the responses onto another or multiple other queues. The queues are fed from and served by multiple general or specific Worker MCs. Such setup needs queue arbiters to make sure that things don't get garbled and get done exactly once... (like in a system where processor(s) and DMAs are working all over the same (address and data) bus...).

Another solution is something likeCarrier-sense multiple access with collision detection ( CSMA/CD ) as was used early days of the ethernet (when coax was the shared medium).

Something like CSMA/CD can be implemented using I2C Multi-Master protocol - https://www.i2c-bus.org/multimaster/

May be you need to reveal a bit more concrete details about what your setup is all about.

Sun 2019.07.14

Thanks for the response @allObjects.

Agree:

'Such setup needs queue arbiters to make sure that things don't get garbled and get done exactly once.'

re: 'reveal a bit more concrete details'

Found existing working code for a microcontroller, but takes up ~1 meg compiled. Want to connect an Espruino WiFi to access using web page control.

Looking in to loading some modules from an SD-Card:

https://www.espruino.com/Modules#from-sd­-card

#18 Espruino loading source code from SD card?

http://forum.espruino.com/conversations/­253795/

but, with my previous attempt at loading a Javascript module, the Pico just barely had enough room for the solution. A hybrid using two micros seems to be my best option right now.

@Robin, you can load and throw away... especially when it comes to data you load from SD card, serve by a http server then forget. - There is also a streaming mode that allows to 'ship' things as piece meals.