Potential DMA overhaul/rethink/cleanup discussion

[usbalbin]

Thought I would make an issue to have somewhere to discuss

Some prior art

• f4
• g0
• h7

Doc

• embedonomicon - DMA

cc @AdinAck

[usbalbin]

I have quite limited experiance with DMA so take this with a grain of salt but here are some of the use cases I think might be nice to support:

1. DMA for collecting ADC samples. Might for example be useful when the ADC is triggered by hardware and timing is very important like measuring at specific points in the switch period of a DC/DC converter, still letting the processor do other things at the same time.
2. UART Tx. Send an entire message asyncronously
3. UART Rx. Receive an entire message asyncronously (how do we know when to stop? timeout, msg len, etc?)
4. more?

[AdinAck]

1. Yes I believe G0 has an example of this.
2. To be a bit more specific, send messages of differing lengths one after the next.
3. There are two ways (Embassy has both):
   • Receive until idle line
   • Receive until receive buffer full
4. A peripheral to peripheral example would be nice. (ADC -> FMAC ?)

[usbalbin]

4. A peripheral to peripheral example would be nice. (ADC -> FMAC ?)

Would that mean that you could have the entire control loop running in FMAC? So for example ADC -> FMAC(for example pid IIR regulator) -> PWM-duty, with the help of DMA?

Something along those lines might be done in AN5788

[AdinAck]

Interesting idea! I have never used the FMAC so I don't know if this is within it's capabilities. I was just thinking denoising an ADC signal before serving it to the CPU, but if the FMAC can facilitate a PID loop for the duty cycle of a timer that would be an awesome example to provide!

[usbalbin]

Reading an5497 page 51 they seem to "only" have the DMA transfer from ADC to FMAC and then trigger an interrupt which does some clamping and then passes the value along.

[usbalbin]

Table 9 of AN5788 gives some performance numbers on regulator in software vs in FMAC

[AdinAck]

Yeah those numbers make sense, I kind of expected the performance improvement to be much greater (like CORDIC) but I guess filtering takes a long time even when done by a dedicated co-processor. Still would be a good DMA example.

[usbalbin]

2. To be a bit more specific, send messages of differing lengths one after the next.

Could something like next_transfer described in #171 solve this use case?

[AdinAck]

I really don't have enough information to say right now. It might be some time before I have enough experience with DMA to speak to any design choices. I am thinking on it but I don't have any answers yet.

It likely would be a step in the right direction, though.

[AdinAck]

Just spitballing here (@usbalbin let me know what you think of this). What if transfers were split into sources and sinks? For example, sending bytes over UART, the USART peripheral would take ownership of the sink (or the sink take ownership of the USART) (hopefully the USART can also be split into Tx and Rx) and then the user can write to the source whenever they want. It could even implement fmt::Write (like USART currently does). Under the hood we would just change the DMA source address to whatever slice was passed in, and check if a transfer is currently in progress already, so it would be try_write I guess. The slice passed would need a static lifetime, of course, and would probably need to be taken as a shared reference. I know the current implementation uses an exclusive reference but I don't think that is necessary.

Do please poke holes in this idea.

[usbalbin]

What use case would splitting the source from the sink open up that would not be possible with one single type(Tx<Dma>, or DmaTransfer<Tx> in the mem to peripheral case(or reverse)?

Oh, that would probably help with peripheral to peripheral transfers right?

[AdinAck]

Yeah good point, I guess it could be one type. But you're right for p-p it could be useful, I hadn't thought of that.

Nonetheless, split or not, I think designing an interface with a try_write(src: &'static [Transfer::Word]) -> Result<(), Transfer::Error> would make sense.

An async interface could accept a non-static reference.

[AdinAck]

Ah, I guess this is reminiscent of a "oneshot" transfer, perhaps that could be a type-state of Transfer which exposes the appropriate interface (circular vs oneshot).

Edit: It's kind of almost set up like that but the interfaces exposed don't seem appropriate.

[boondocklabs]

I've been experimenting with DMA quite a bit recently on a G474VET6 with FMAC, CORDIC, and DACs, and thought I would share some of my experiences with it.

I've successfully got a pipeline that takes a single delta sigma parameter in a RAM location which is autonomously DMA'd to FMAC (1 tap, 2 coeffs making it just a MAC, so effectively a phase angle accumulator that wraps at pi to -pi). The FMAC output is DMA'd to an intermediate buffer with halfword writes to set the lower arg1 parameter to CORDIC SinCos function, while the upper half has a modulus of 1.0. CORDIC is then configured to DMA from this intermediate location to compute sin and cos. The DualDac then DMA's from CORDIC paced by a timer trigger. Sine synthesis from a single delta theta (2 * freq / sample rate) that can be set once and updated arbitrarily, and the rest is done in hardware with no interrupts or CPU.

There is lot to be desired in setting up DMA, often resorting to just configuring DMA channels directly in unsafe blocks, as ownership issues can really start to fight you, and a lot of things are lacking TargetAddress impls.

The nomenclature ST use for "peripheral" and "memory" is somewhat misleading - as you can actually DMA between any memory mapped location you want - the peripheral is really just about direction and request line. You can also use the same peripheral to trigger multiple requests. I use CORDIC Write request line for example in the MUX to drive FMAC DMAs while also using the same request line to have CORDIC DMA from the same buffer with a higher priority.

So in this case "memory to peripheral" is actually from a peripheral register, to a RAM location, but is being triggered by a peripheral (which is where the direction matters).

        unsafe {
            // The "peripheral" is the temporary buffer where the lower half word from FMAC will be written
            dma3.set_peripheral_address(&buffer[0] as *const _ as u32);

            // The "memory" is the FMAC output register
            dma3.set_memory_address(FMAC::steal().rdata().as_ptr() as u32);

            // 16 bit transfers from FMAC to write lower half of CORDIC input word
            dma3.set_memory_size(2);
            dma3.set_peripheral_size(1);
            dma3.set_number_of_transfers(1);
            dma3.set_circular_buffer(true);
            dma3.set_direction(DmaDirection::MemoryToPeripheral);
            dma3.set_priority(Priority::High);

            // Pace the transfer from CORDIC write DMA requests
            dma3.set_request_line(DmaMuxResources::Cordic_Write as u8);

            dma3.enable();
        }

        unsafe {
            dma2.set_peripheral_address(CORDIC::steal().wdata().as_ptr() as u32);
            dma2.set_memory_address(&buffer[0] as *const _ as u32);
            dma2.set_memory_size(2);
            dma2.set_peripheral_size(2);
            dma2.set_number_of_transfers(1);
            dma2.set_circular_buffer(true);
            dma2.set_direction(DmaDirection::MemoryToPeripheral);
            dma2.set_priority(Priority::VeryHigh);
            dma2.set_request_line(DmaMuxResources::Cordic_Write as u8);
            dma2.enable();
        }