Addressing 4 SPI slaves
Board Type
RPi 3 Model B
Operating System
Ubuntu Mate 16.04
Swift Version
Swift 4.1.3, canned.
Description
Attempting to address four SPI slaves using a LS7366R break-out board. I'm unclear from the SwiftyGPIO SPI documentation how to do slave select. Do I separately set the CS or GPIO pins low/high in order to select a slave, i.e. slave select is separate from the SPI library implementation itself?
Thanks in advance!
You could use up to 3 devices if you manage to enable the auxiliary SPI1 the has 3 CS pins (see this thread for example), I've never tried though. The nomenclature here is actually a bit off...:
// RaspberryPis SPIs
static let SPIRPI: [Int:SPIInterface] = [
0: SysFSSPI(spiId:"0.0"),
1: SysFSSPI(spiId:"0.1")
]
These are not the two SPIs of the RaspberryPi, these are the devices that model SPI0 with CS0 or CS1 enabled, so, using /dev/spidev0.0 you'll enable CS0 (setting it to 0 since it should have negative logic), while if you send data through /dev/spidev0.1 the driver will enable CS1 before actually sending it. The driver guarantees that the data will be always be sent a few clocks after the corresponding CS has been enabled.
But, after all CS pins behave just like a normal GPIO, so you could choose 4 free ones (that don't overlap with other alternative functions you need, e.g. I2C) and connect them to the CE/CS of the 4 devices you have (the MISOs/MOSsI will be connected to the same bus). This implementation will not be as fast as leaving the CS management to the spi driver but could be ok in most cases.
Note on the LS7366R: Now that I'm looking at the schematics for one of these boards, are you using the 4 motor drivers version? If you plan to use them for something like a model car (wheels, not tank tracks) the delay introduced by using multiple gpios shouldn't be an issue, but it could be if you are building a quadcopter.
I'll try following some of the steps in the thread you reference and see if I can get SP1 working and if not just use some GPIOs. In using the GPIO, I just set the particular slave GPIO to LOW in order to address it, correct?
Just as a matter of curiosity, so you think the software-based implementation of SPI would be sufficiently performant for my use case? I'm betting I can get hardware working regardless.
Yes, I'm using the quad (4 motor) version. My vehicle is fixed four wheels, fortunately. I don't trust myself to build anything that flies. :)
Thanks!
I just set the particular slave GPIO to LOW in order to address it, correct?
Yeah, if it doesn't work try setting it high, but other than this the value should stay the same for the duration of the transmission.
so you think the software-based implementation of SPI would be sufficiently performant for my use case?
If the board just needs some configuration and once that's done the motors keep running regardless and if a few ms of delay are tolerable, it could be enough. Everything depends on how the algorithm that will control the wheels will work (I'm guessing that with 4 independent but fixed wheels you'll need to play with the rotation speed and/or direction to move the car, the latter could be more complex since it requires coordination to turn left/right... just a small step below the quadcopter :D ).
I've managed to get two of the four encoders working. Where I'm using regular GPIO pins for slave select I'm getting what looks like good data, while the ones I'm using CE0 and CE1 are returning zeroes. I'm treating the pins the same way, using your GPIO library to set the pin to 0 when selected and 1 when done with transmission.
It's pretty straightforward to switch to using GPIO pins for all but thought I would check in and see if you have any ideas!
while the ones I'm using CE0 and CE1 are returning zeroes.
Oh. I've never actually verified if the sysfs CEs were working on the raspi, we could have some issues there.
but thought I would check in and see if you have any ideas!
That's ok in most situations, basically if you don't need to switch on/off SPI clients in the -ms/us range.
I got it working using generic GPIOs instead of CEs, so no problem. Thanks.