Continuous DAC sine generation using SPIM and a HW counter (combined via PPI)

[Pjay]

Hello everyone,

I'm trying to generate a periodical sine signal at the output of a 10 bit DAC without CPU interaction. The DAC uses an SPI interface, thus my idea was to use a hardware counter which is connected to the SPIM module via the PPI functionality.

I have used the example in https://github.com/Martinsbl/nrf5-mpu-examples/tree/master/nrf52-mpu-easydma-using-timers-and-drivers as a starting point and adapted it for my case.

I have put the data that needs to be transmitted to the DAC into an array. As for each data point of the sine wave two bytes have to be transmitted (due to the 10-bit format of the DAC), I have coded an MSB and LSB byte for each data point. So, if the sine wave consists of 50 data elements, the resulting array consists of 100 elements (e.g. SINE0, SINE1, .... SINE49 --> SINE0_MSB, SINE0_LSB, SINE1_MSB, SINE1_LSB .... SINE49_MSB, SINE49_LSB).

I have also set up a hardware timer so that each compare interrupt triggers SPI transfer via PPI.

The problem I face however is that I need to transfer two bytes with every timer interrupt, not only a single one.

Is there any way to accomplish that without CPU intervention? What would be the simplest way?

And another question: what happens if the end of the transmit buffer is reached? Do I need to reinitiate the SPI communication to gain a periodically repeated sine signal?

Thanks in advance for any suggestions!

[Pjay]

I found a solution: I have implemented a second hw timer/counter configured as counter similar as in the link above. With the main timer I transmit 2 bytes over SPI (triggered by the CC event via PPI). The counter is connected via PPI with the SPI transfer done address and counts each transfer done event. After N events (where N is configurable) the counter generates an interrupt, and in the interrupt handler I increment the pointer regarding my sine array (look-up table).
I don't know if this is the best solution as I still need to involve CPU for pointer incrementing, but it is better than per event scheduling (regarding timing robustness).
It was a little tricky with SPI because the CS pin is not toggled automatically by the driver. Here I adapted a solution mentioned here: https://devzone.nordicsemi.com/f/nordic-q-a/18645/no-slave-select-on-spim-xfer-using-ppi-and-gpiote