API refinements

[lhoward]

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 int
• swifthal_spi_transceive() should just take a single length parameter not if it's for a single request/response
• suggest using size_t / ssize_t instead of unsigned int and int where applicable
• is libdispatch available on your platform? if so, perhaps the async SPI APIs could take a block?
• It wasn't quite clear to me how swifthal_spi_async_read() was supposed to work, i.e. whether it's supposed to read asynchronously and write into the supplied buffer, calling r_notify() when ready: would be better if the buffer was passed to the callback

[lhoward]

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.

[lhoward]

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

[lhoward]

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.

[lhoward]

LMK if you would like me to open a separate issue for this but – would be great to not build posix_memalign() and getentropy() so it only builds on Zephyr and doesn't override the glibc symbols on Linux.

[andy0808]

LMK if you would like me to open a separate issue for this but – would be great to not build posix_memalign() and getentropy() so it only builds on Zephyr and doesn't override the glibc symbols on Linux.

Hi @lhoward , I've moved both the posix_memalign() and getentropy() implementations to Zephyr layer in main branch.

[lhoward]

@andy0808 amazing, thank you again for making my life easier!

[lhoward]

Would you consider tagging a release of main so I can use a versioned dependency?