More granular circular DMA

[rudihorn]

Currently circular DMA is implemented in a way where the circular buffer has two buffer halves, and then once one buffer half has been filled the buffer half can be read while the next one is filled. If one would like to use a larger buffer e.g. 256 bytes, this means that to use it "properly" one would need to wait until 128 bytes have been filled, making this approach only useful for bulk transfers.

There is another approach, which is to use the DMA_CNDTRx register (STM32 reference manual 13.4.4) to determine the number of bytes the DMA still has to write until the end of the buffer and use it to calculate the number of bytes already transferred into the buffer. Specifically something along the lines of cndtr_last - cndtr (and add the buffer length if negative) should return the number of bytes in the buffer.

I would suggest renaming the current CircBuffer to CircBufferHalves and then implementing new CircBuffer behaviour which provides functions has_data length dequeue or similar.

If something like this makes sense I can try putting together a pull request.

[TheZoq2]

I haven't worked with circular buffers yet, but it sounds like it would be nice to have :) I'm not sure how easy it would be to make it work with the ownership system

Also, I vaguely recall there being some discussion about adding DMA traits to embedded-hal, but I can't find that at the moment

[rudihorn]

would be nice to have

I mainly just wanted to hear that it isn't a bad thing to do. I would be interested in implementing this, so I will try hacking something together this weekend probably. I'll see if embedded-hal mentions anything, though regardless I'm sure it would be roughly the same.

[TheZoq2]

I would be interested in implementing this, so I will try hacking something together this weekend probably.

Sounds great, let me know if you run into any issues :)

I'll see if embedded-hal mentions anything, though regardless I'm sure it would be roughly the same.

The main concern is if embedded-hal is close to finishing their API, in which case we'd have to rewrite parts of it once that gets released.

Also, you'll probably want to have a look at #239 in which I'm changing part of the DMA API. I'll try to finish that conversion today in case you want to base your impl on that