Stabilizer asynchronous batch sampling support

[ryan-summers]

This PR updates the stabilizer firmware to utilize batch-based sampling of the ADCs. This essentially offloads the task of triggering SPI reads and gathering ADC samples into a buffer into hardware DMA. This PR also updates DAC outputs to utilize a DMA trigger to periodically write DAC codes to the DAC SPI as well.

A single timer drivers DAC + ADC DMA transfers - four comparison channels (each configured to compare against timer value 0) are used to generate 4 DMA requests, which initiate DAC writes and ADC samples simultaneously.

To generally describe the new ADC implementation, there are four DMA streams and one timer used to offload sampling. The ADC SPI interfaces are configured in infinite transaction mode with auto-suspend CS when no data is available. To trigger an ADC sample, a constant word is written to the SPI TXFIFO by the trigger DMA, which is repeatedly requested by a timer channel. This effectively controls the sample rate on both channels.

Two other DMA streams are configured to continuously read from the SPI RX FIFOs to gather data. The DMA will only read when data is present in the RX FIFO, so these will wait until the desired number of samples are acquired.

Once the DMA completes gathering N samples, an interrupt is generated for the DMA stream and firmware retrieves the buffers provided to DMA, which are now filled with ADC samples. It then schedules the next DMA transaction for additional samples before continuing to perform DSP on the acquired ADC samples.

Once DSP has been completed on the samples, they are enqueued into a FIFO for transmission on the DAC. The DAC DMA transfers are configured and started. The DACs are then asynchronously updated.

TODO

• Wait until Implement DMA based on embedded-dma traits stm32-rs/stm32h7xx-hal#153 is merged into the mainline HAL
  • We will instead track the dma branch, as it may take some time before merge is completed
• Document new modules
• Merge Utilize mainline stm32h7xx-hal #159
• Update ADC0 and ADC1 trigger DMA channels to use distinct DMA requests

[ryan-summers]

@irwineffect After our discussion yesterday, Robert and I discovered that DMA transfers behave differently than documentation would lead you to believe.

When a peripheral generates a DMA request, this results in a single data transfer of the request, not a completion of the entire request.

This means that it's possible to use the DMA channels to also update the DAC output codes regularly. I have since updated the PR to support DMA-driven DAC updates as well.

[jordens]

Would macros or generics for the timer channels, the ADC code, and the DAC code shrink the code?

[jordens]

Looks good. The refactoring with macros/generics to reduce code footprint can also be done later.

[irwineffect]

Looks good!