How to use PPI for reading data from ADC

Hello

I need help, I have a problem implementing ppi gpiote and spim. The ADC I use is mcp3562 which sends via the irq pin when the data is ready. I need to work in continuous mode at almost 100khz data sample rate. Is it smart to use that pin as gpiote via ppi to start spim task. Plus I have to send that data in real time so I thought that to load data into a buffer and send it like that, I saw some example that uses one buffer and processes it in half while the other half filling, but my problem is how to start spim via ppi. I tried directly connecting gpiote to spim task start, but its seams that im getting fatal error arch_system_halt and im not able to use usb port to see what the actual error is, probably cus CPU is getting traped in forever loop in this fatal.c file.

Parents
  • Hi,

    I am not sure there are any good examples that do what you want no, so I guess you just have to look at potential existing nrfx and nrfxpiote examples and try to use them as reference on how to do it. The description you provide seems to be correct, so if you have any faults you may need to check you have connected tasks and events correctly, and you don't use any ppi channels that are not already in use by other code. If you have an nRF52840 DK you should be able to debug and narrow down the fault.

    I highly recommend that you buffer up data to fill an entire radio payload before you send the data, since it's much more efficient to send several tens of byte rather than a few bytes. Overall this will also improve quality since it can allow some retransmissions and quality of service. But I guess it's up to you what is most important: some latency but less packet loss, or shorter latency but allow more packet loss.

    Kenneth

Reply
  • Hi,

    I am not sure there are any good examples that do what you want no, so I guess you just have to look at potential existing nrfx and nrfxpiote examples and try to use them as reference on how to do it. The description you provide seems to be correct, so if you have any faults you may need to check you have connected tasks and events correctly, and you don't use any ppi channels that are not already in use by other code. If you have an nRF52840 DK you should be able to debug and narrow down the fault.

    I highly recommend that you buffer up data to fill an entire radio payload before you send the data, since it's much more efficient to send several tens of byte rather than a few bytes. Overall this will also improve quality since it can allow some retransmissions and quality of service. But I guess it's up to you what is most important: some latency but less packet loss, or shorter latency but allow more packet loss.

    Kenneth

Children
No Data
Related