Hello William,
On 31/01/2019 05:28, William Busacker wrote:
Hi all,
Told myself that in the new year I'd finally get around to working on
the Raspberry Pi's BSP some more, but before I start I have a couple
questions I'd like to have answered, particularly about SPI. Not sure
if this belongs in the devel list, figured users was a good place to
start.
Its been talked about before how the RPi SPI driver should be
re-written at some point. Between the interrupt mis-handling, file
descriptor bugs, and performance issues, I think there is enough cause
to do a rewrite, but I'm not sure how exactly it should be done.
Section 10 of the BSP and Driver guide blanket statements that the SPI
bus drivers should use the SPI bus framework (dead link, likely lost
in the cpukit move) and specifies that the API needs to be Linux
user-space compatible. I understand the desire to be as linux-y as
possible to make developing in RTEMS much more natural for those not
used to real time systems, but in this case I'm not sure if it is the
best move. Doubly so for the Raspberry Pi. (As I'm interested in the
RPi in particular I'll be referencing that specific BSP forward)
Since the RPi is marketed as an "entry" device for hobby electronics,
it is either a gateway device or is being upgraded to from an Arduino.
Brand new users trying to learn about SPI online (Sparkfun's blog post
being very popular) and people coming from Arduino will be used to the
model of 8/16 bits being traded with cs active end point. Put data in
buffer, send/receive, read back, or do it all at once with a single
function call. Arduino handles this flow quite nicely; configure an
SPISettings object, "begin" transactions, do as many .transfers() as
you want then when you're done "end" transaction. Granted Arduino
purposefully simplifies things, it still is very representative to
what actually occurs in hardware and is easy for a newcomer to grasp.
Linux's SPI user-space driver introduces ioctl which in and of itself
is complex and then makes all interaction through a file descriptor,
limiting the user to either read /or/ write ability, not both at the
same time.
For the RPi, the vast majority of SPI examples are either in Python
(which does use spidev) or in C using either the wiringPi or BCM2835
libraries. Both the C libraries provide functionality more akin to
Arduino's solution than the Linux kernel solution.
There are also issues in operational terms of spidev.
- Full duplex is impossible without digging into ioctl
- Everything must be synchronous (sitting in its own task can help
mimic interrupts but may not be the best solution)
- spidev doesn't offer slave select polarity control
What I was thinking as an alternative is something close to how the
BCM2835
<https://www.airspayce.com/mikem/bcm2835/group__spi.html#ga0127eab1b6c3f8bf127bdac474fdc0f9>
library controls SPI. The library can't be directly put into the RTEMS
project since it relies on Linux for other things, but its general
approach is something I feel is a much better solution than using
spidev. It grants far more insight into what the bus is doing as well
as much tighter control over the device. I realize this means more
documentation (something I also plan on attempting to tackle for RPi
at some point), but I think thats a worthy tradeoff. Especially since
it seems spidev was designed to fit Unix's
I'll-get-around-to-it-when-I-feel-like-it approach to device control,
compared to an rtos's Its my bus and I need it now!
Yes, ioctl() is a horrible interface, but the struct spi_ioc_transfer
transfer mechanism is good from my point of view. It offers full-duplex
transfers, per transfer settings and you can combine multiple transfers
in one request. The driver ensures that the SPI bus is only used for one
request at a time. If you like, then you can hide the ioctl() in a
wrapper function to get a type-safe API. Maybe you can also add another
IO control to accept asynchronous requests with a completion callback.
The APIs using multiple function calls to change settings and do a
transfer have all potential locking issues. Using a request with
multiple transfers has the benefit that you can issue the next transfer
within the interrupt handler. This avoids task switches.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
