-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilizer asynchronous batch sampling support #165
Stabilizer asynchronous batch sampling support #165
Conversation
@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. |
Would macros or generics for the timer channels, the ADC code, and the DAC code shrink the code? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. The refactoring with macros/generics to reduce code footprint can also be done later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
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 HALdma
branch, as it may take some time before merge is completed