feat: add spi rx dma (and migrate to embedded-dma)

[ForsakenHarmony]

No description provided.

[ForsakenHarmony]

According to this it seems to always be map2

[korken89]

Hi, what is the status of this PR?
It is marked as Draft, but it sort of seems like it's close to ready?

[korken89]

Ping again :)

[ForsakenHarmony]

@korken89 it is / was marked as a draft because it depends on the SPI slave PR

[MathiasKoch]

marked as a draft because it depends on the SPI slave PR

Just merged that one for you :)

[korken89]

Thanks @MathiasKoch! I'll review this today!

[ForsakenHarmony]

Ah, right I also noticed the Frame Reader is in a bit of a weird state with this

Not sure if the character_match should be used / moved to a different place

[korken89]

@ForsakenHarmony Not quite sure I am following, could you expand on that?

[ForsakenHarmony]

See the failing test

error[E0599]: no method named `is_character_match` found for mutable reference `&mut Rx<stm32l4xx_hal::pac::USART2>` in the current scope
Error:    --> examples/rtic_frame_serial_dma.rs:115:28
    |
115 |         if cx.resources.rx.is_character_match(true) {
    |                            ^^^^^^^^^^^^^^^^^^ method not found in `&mut Rx<stm32l4xx_hal::pac::USART2>`

rx is consumed by the dma with the new API, so is_character_match has to be moved somewhere else

I also haven't found the FrameReader API in any of the other stm32-rs repos so far, so I'm not entirely sure how it works / is supposed to work

[korken89]

Ah, I see waht you mean. The frame reader works like this:

1. Select a frame delimiter character, lets say 'a'
2. The DMA will read into the buffer until it is full or an 'a' is then received (hence the character match)

E.g.: The following is received: sdfsdfaqweqwea.
Then we get 2 frames with sdfsdfa and qweqwea from the driver, assuming they fit in the buffer size provided.

A common use-case is if you encode data with COBS (\0 delimited), and then the DMA does all the work to detect frames for you.

So we need to find someway to make it work, what are you suggestions?

[ForsakenHarmony]

@korken89 added a trait for the character match and added it to the FrameReader
let me know what you think

[ForsakenHarmony]

Hmm, I suppose it would also be possible to just implement the trait here

[korken89]

I think this is the right place :)

[korken89]

Super, we are getting close! :D
I think your comment on the frame reader is correct as well.

One question, the DMA for SPI is setup for RX are you planning to support TX and TX/RX transaction, or is this left out for now?

[korken89]

Could you have a look at fixing the failing tests?
I think we can merge this as soon as possible, and we can extend the missing features in coming PRs.

[korken89]

Hi, @ForsakenHarmony , I provided fixes for the errors here: #230

One questions has popped up for me, how is it planned that this will be used?
From what I understand from the code I cannot see how to perform a SPI transfer using DMA based on this, as there is no way to send data (which drives the SPI read transfer).
Could you provide an usage example indicating this please?

[ForsakenHarmony]

Sorry, I keep missing these GitHub notifications, I have too many

https://github.com/ForsakenHarmony/roboclub-lighting/blob/main/stm/src/main.rs#L225-L228

Here's how I'm using it, I've only used it in slave mode, which means a master sends data and clock

[korken89]

Ahh, makes sense - thanks!
I'll continue adding the SPI master Tx and RxTx support then in the parallel PR.

[korken89]

This was merged as a part of the work in #230.
Thanks for starting this PR!