Skip to content
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

Open
robreuss opened this issue Feb 19, 2019 · 6 comments
Open

Addressing 4 SPI slaves #83

robreuss opened this issue Feb 19, 2019 · 6 comments

Comments

@robreuss
Copy link

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!

@uraimo
Copy link
Owner

uraimo commented Feb 20, 2019

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.

@robreuss
Copy link
Author

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!

@uraimo
Copy link
Owner

uraimo commented Feb 20, 2019

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 ).

@robreuss
Copy link
Author

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!

@uraimo
Copy link
Owner

uraimo commented Feb 27, 2019

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.

@robreuss
Copy link
Author

I got it working using generic GPIOs instead of CEs, so no problem. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants