Understanding how the DMA example spi_dac works
Thank you for this nice project, that gives a much more direct hardware access to the MCU as the MounRiver Studio and works fine in Linux.
At this moment I am trying to test a little breakout board I have made for the use of this interesting MCU. https://www.mikrocontroller.net/topic/548353#7427694 Without the knowledge of your project details I have choosen to implement the same interesting IC's like WS2811 and PT8211. :-)
For the first test I tried to use the DAC, but I used an TDA1387 instead of an PT8211 and get an curious output on the sine channel. The pin WS is of course connected to PC4 and not to PC3 as suggested in the diagram (jumper bridge).
The other channel works as expected.
I am not familiar with the use of an DMA and your example uses the hardware on a high level. You already commented your code a much, but at this time I have no idea why this output happens?
TIM1CH4 generates the signal for WS and interrupts to fill the buffer for the DMA. But how this works in detail? The DAC buffer is filled in a mystery way and the output is only strange for one channel.
Is it possible to output a wave directly from the flash with the DMA?
Has someone tips for a low skilled programmer to learn?
The result is not better with setting
// Length of the DAC DMA buffer
#define DACBUFSZ 256
Here is the I2S data format of the TDA1387 that is needed and it should be the same for the PT8211:
When every 16 Bits WS is toggled over TIM1 with 48 kHz why a DMA is needed? SPI could be directly feeded in the timer interrupt routine.
When only one channel is used with one continuos data stream then the DMA makes sense, transferring a buffer direct to the SPI. The DAC chip can convert a datastream up to 384 kHz. But this will not work with this DAC chip, because WS must be toggled to latch the streamed bits.
You can feed it via SPI interrupt if you want, but, you don't have to if you want to use DMA.
You will need to search the TRM maybe to see the best way to configure your WS line.
Your best option MIGHT be to use PWM outputs, and use one of them as the WS line?
Thank You for your quick response.
You can feed it via SPI interrupt if you want, but, you don't have to if you want to use DMA.
That's what I did not understand since yesterday, because the DMA is not able to toggle the WS line and the timer is not synchronized with the DMA in any way?
You will need to search the TRM maybe to see the best way to configure your WS line.
What is the meaning of TRM in this case? https://en.wikipedia.org/wiki/TRM
Your best option MIGHT be to use PWM outputs, and use one of them as the WS line?
From my understanding I would try to use the interrupt of SPI or of a timer for a fixed conversion rate like you have done. But first I must get more familiar with the programming / definitions and hardware to test this. The above was only a (positive) smoke test and the result was very confusing, not understanding the intention of your code regarding the use of the DMA.
In my next test I will try to use the SPI to feed a latch (74HC595) for an LCD display. But there are other tasks that must be done now - so later on ...
TRM = https://www.wch-ic.com/downloads/CH32V003RM_PDF.html
re: My code, you mean my ws2812 demo right?
TRM = https://www.wch-ic.com/downloads/CH32V003RM_PDF.html
Ah - now it makes klick: TRM = Technical Reference Manual
re: My code, you mean my ws2812 demo right?
No - on my breakout board there is a latch (8-bit serial-in, parallel-out shift register) as port expander, feeded over SPI. It is intended for an easy connection of an LCD display and reading of 4 buttons.
But the test with the WS2812 is outstanding too. :-) I have seen that you use the SPI for feeding the WS2812, but SPI is needed for the port expander or DAC. A timer solution or timed code would be better.
I am not sure how to further your turmoil on this? If there is some way to improve this issue so it can be closed, that would be great.
It would be simply helpful if you could explain how the DMA functionality with the buffer is intended to work here.
Or how such an strange sinus output can occur?
Sorry if this issue is annoying, it is not really a bug report, it should be seen as support question. So close it if it is needed - it can still be answered afterwards.
We could enable Discussions and move this there.
Good idea!