SAI HAL API and Driver

Hi everyone,

I’m interested in the stale branch here: Comparing master...feature-hal-spec-sai · ARMmbed/mbed-os · GitHub

That was implementing a Serial Audio Interface HAL API for Mbed-OS. I recently rebased it (find that here: GitHub - EmbeddedPlanet/mbed-os at feature-hal-spec-sai) and started working on a nRF5x port but deadlines are coming around and the API falls a bit short of my requirements at this point.

I’d like to propose the continuation of the SAI HAL Spec and implementation work.

Something that is missing from the API from my perspective:

Since audio is more of a “streaming” data format, the HAL API should support asynchronous transfers much like I2C and SPI do. A proposed method of implementation could be:

→ User provides buffers for audio RX and TX (should be double buffered)
→ Transfer is started and handled by hardware until half the buffer is consumed
→ User application code receives a callback that can give a pointer to new data or fill out the existing buffer.

Does anyone else have interest in SAI for Mbed? Comments on the proposed asynchronous functionality?

1 Like

I certainly do.

And for a related, but slightly off topic is that there is zero visibility into how the priorities are set. So, work was started on two or three branches that I am interested in seeing progress (this, the SDIO branch, one or two others) and then it just sits for a while. And then, all of the sudden, moves forward.

But back to your comment: I believe it would also be helpful to define the input and output type definitions. I’m not sure the right way to do this, but, for instance, you might want an I2S output (or AC97) into a class D output driver. But you might also want to receive from a PDM stereo microphone pair (for beam forming) which requires only two pins.

In that case, I am not sure what the ideal setup for a HAL written in C would be. I could see some of it (an enum for the type, possibly bit 0 as the clock source) but then how do you handle the pin definitions?

This may be a case where my knowledge of data structures and best practices falls far short. It may already be Not That Hard and I just don’t know (yet) the most straightforward way to handle it.

1 Like

@peapod
Priorities for features are now most likely customer driven.

The new working groups may help here but for now its on the community and partners to finish this out.

There is a specific process outlined for adding new features in the doc folder of the mbed-os repository

I am also very interested in using microphones in Mbed, till now used samples on F746 but need to port interface for other microcontrollers such as F446 and nRF52. I found there is no official support for ST SAI or nRF I2S till now, so how should we add it manualy?

Me too. I was very surprised that mbed-os does not support any audio interface in version 5. Trying to port from ST’s I2S driver for mbed 2 makes me sad.

Thanks for your work, @aglass0fmilk!

Yes, I am also interested in the SAI driver. Interfacing with a the AD7768-4 precision ADC can be done using SAI. Right now I am trying to see I can use the feature-hal-spec-sai branch to receive data from the chip.