-
Notifications
You must be signed in to change notification settings - Fork 3
cpu/native: Adapt HW SPI for HW GPIO support #4
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
Conversation
Thank you very much - I'll look into it! If this is a limitation of the new gpiochip API I'd have to go back to the old sysfs API - but first I would suspect a bug in my code. |
Maybe I'll also need to investigate that further to see where that segfault comes from. What I observed until now: If you use the SPI and GPIO module in parallel, the only limitation is that you cannot access the hard-wired CE-pins of the SPI interface (and probably also not MISO/MOSI/SCK, I haven't tried that yet) through your GPIO implementation. So if you start your application on a Pi with To me, such a limitation on the Linux side would make perfectly sense. It would only be nice if both modules coordinate their use of the pins somehow. Maybe it's possible to use the gpiochip API (haven't used it before) to see if some lines are already in use. Otherwise, I don't know how to learn from |
I did some more testing. First, the good news:
The bad news:
So while the problem of mapping hardware chip select lines to their representation in the |
Thank you a lot for the patch! |
That'd be great. I'm using your GPIO implementation and this patch cherry-picked onto a |
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Contribution description
This PR extends the introduction of GPIO hardware access on the native board, and adapts the hardware SPI module for the new feature.
This is required to avoid colliding number spaces for the
SPI_HWCS
andGPIO_PIN
macros, which can both be used to create values for thecs
parameters of thespi_...
functions. Furthermore, this PR allows using arbitrary GPIOs as CS lines, which gives more flexibility and support for a greater number of parallel SPI devices.Known issues
When the SPI module is used on a Linux spidev, and one or more of its lines is shared with a Linux gpiochip, then accessing the lines through functions like
gpio_set
will cause a segfault.Example: Use the
tests/periph_spi
application on a Raspberry Pi 3, withTERMFLAGS = -g/dev/gpiochip0 and -p0:0:/dev/spidev0.0
.In this case
GPIO_PIN(0, 8)
andSPI_HWCS(0)
point to the same line, but only usinginit 0 0 0 -1 0
works in the test application,init 0 0 0 0 8
(which will use the gpio module) causes the aforementioned segfault.I think, this is hard to circumvent, but should be documented somewhere. Identifying this situation would require knowledge about the mapping of the physical lines in both, the spidev and gpiochip devices. This may be strongly hardware-specific.
Testing procedure
The easiest way is the loopback test, which can be run like explained in RIOT-OS#11352. However, this doesn't prove the function of the cs lines. This could be achieved, e.g., by connecting them to an oscilloscope.
In the tests/periph_spi application, the bus is initialized by
x y z <cs-port> <cs-pin>
. If cs-port is-1
,HWCS(cs-pin)
will be called, otherwise,GPIO_PIN(cs-port, cs-pin)
is used. This allows quick switching between different cs lines.Issues/PRs references
Extension to RIOT-OS#12451