embedded-hal
embedded-hal copied to clipboard
[Proposal] I2S traits - take 2
(This was all done and discussed in #204 but this crate continued its evolution before the merge. Here I just adapted the traits to how we do things now: 1 blocking trait with all methods, no nb
variant as that will be deprecated eventually.
The proof implementations need to be adapted (sorry!) but this should be pretty easy)
I added some I2S traits to kick off the discussion started in #203. The traits accept two words for left and right and are otherwise similar to SPI as of the 0.2.x version.
An interleaved version can be found in the i2s-interleaved
branch. There the data should be passed interleaved. e.g. [left0,right0,left1,right1,...]
A version of these traits for the embedded-hal 0.2.x version can be found in the i2s-v0.2.x
branch.
There is another MCU implementation in stm32f4xx-hal
TODO:
- [ ] Demo microcontroller HAL implementation:
- [ ] stm32h7xx-hal - discussion issue
- [ ] [WIP] stm32f4xx-hal
- [ ] Bit-banging HAL implementation supporting 16-bit and 32-bit packets
- [ ] Working example of saw wave
- Uses driver: https://github.com/maxekman/cs43l22
- [ ] Full-duplex trait implementation
- [X] Changelog entry.
- [ ] Add documentation about what happens if the buffer sizes differ.
Thoughts? cc. @maxekman @samcrow @YruamaLairba
r? @therealprof
(rust-highfive has picked a reviewer for you, use r? to override)
Hello, is the API still open for change ? I think an API based on [(W,W)]
instead of left:[W], right:[W]
or interleaved:[W]
will prevent some stupid situation, for example :
- an user may want only left channel and use
left: [W;128]
andright: [W;0]
, does implementation expect that ? - a left or right sample is corrupted. Naive implementation may just drop It, causing synchronization issue between channel.
- a malicious user use an interleaved with odd number of elements, how methods should behave ?
Changes are still possible here. The reason I chose separate buffers for left and right instead of [(W,W)]
is because they are much easier to deal with than an array of tuples and from my experience, both channels are probably being handled with separate buffers in the rest of the application already.
Of course this leads to situations like the ones you listed and I would expect any implementation to either deal with them in some way or impose additional restrictions like requiring that both buffers have the same length.
I will add some more documentation to the trait about this.
I published this trait in a separate embedded-i2s
crate.
I would encourage anybody to continue the discussion over there.
A discussion about integration into embedded-hal
would come much later.