-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addressing 4 SPI slaves #83
Comments
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.
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. 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: |
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! |
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.
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! |
Oh. I've never actually verified if the sysfs CEs were working on the raspi, we could have some issues there.
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. |
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!
The text was updated successfully, but these errors were encountered: