Open lhoward opened 9 months ago
Here's my current approach for async, which at least has the advantage that it's quite minimally intrusive to the HAL.
There's a simple function to get the underlying FD, e.g.:
int swifthal_spi_get_fd(void * _Nonnull spi);
and then there is (e.g.) an AsyncSPI actor which wraps SPI
to do its initialisation but does all the underlying I/O using IORingSwift. So the async wrappers are really extremely straightforward. Once I have them working in my application, I will have some feedback about the suitability of the APIs, etc, and then perhaps down the track we can look at adapting IORingSwift
to also support RTIO.
Same for UART
, I2C
, etc.
Pleased to report I have async SPI working with a RPi4 controller, proprietary peripheral.
Was quite an effort, particularly because Linux's user-space SPI API is blocking (hence IORingSwift, which took a while to iron out all race conditions).
The code uses SwiftIO for initialisation and hands over to AsyncSPI (of course, eventually it would be great to have this integrated into SwiftIO itself).
Another request would be to use Errno from SwiftSystem. Currently I'm converting between the two, obviously it's trivial and doesn't really matter but it would be nice to standardise. Of course, getting SwiftSystem to run on Zephyr might take a little work.
Just using this as a catch-all, can split out into separate issues later
swifthal_counter_read()
returns a negative error code on failure (like the other APIs), but the return type is unsigned intnot if it's for a single request/responseswifthal_spi_transceive()
should just take a single length parametersize_t
/ssize_t
instead ofunsigned int
andint
where applicableswifthal_spi_async_read()
was supposed to work, i.e. whether it's supposed to read asynchronously and write into the supplied buffer, callingr_notify()
when ready: would be better if the buffer was passed to the callback