This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

High Sample Rate with ADC and SoftDevice

I am trying to sample the ADC every 2ms. I notice lots of slowness with BLE advertising and typically can't connect to device over BLE when sampling. I am using PPI, configuring, and starting before the softdevice is enabled.

  1. Should nRF51822 be capable of reading ADC every 1ms to 2ms reliably?

  2. Should I move all the PPI configuration to after the softdevice is enabled and be using the sd_ppi functions?

Thanks!

Edit: Headline, format, added tags.

  • Peter,

    That is how I would try to configure it as well. But every time the CS/EN pin is pulsed I believe it resets the write address of the RX_Buffer back to RX_PTR. The same is true for the TX_BUFFER and TX_PTR. This is my interpretation of the data sheet. Perhaps we could get a member of nordic to provide some input about this transaction.

  • In another post I saw that instead of pulsing the CS/EN pin, they were enabling the clock signal for a set number of transitions. The number of clock pulses were counted using one of the counters, that way the behaviour of reseting the TX_PTR and RX_PTR would only happen when the end of their respective buffer was reached.

  • Thanks for your comment Peter. I believe this brings our idea of using the SPIS for ADC sampling back to life. Can you point us to this post you are mentioning. I will work on setting this up on my side today.

  • Peter,

    I believe you can enable the clock for a set number of spi byte transmissions. However, the TX_PTR and RX_PTR will both increment every-time a transmission is made. If you set MAXTX to 1 and attempt to let the spi go for multiple transactions a spi overrun error will be thrown. My interrpretation of the data sheet is that in this scenario RX_PTR and TX_PTR will be incremented an controlled in an identical way. There is no way to make RX_PTR go through a 100 byte buffer and TX_PTR read from a single memory location.

  • Your theory is correct Lucas. I have actually set up the example and tried this. I managed to clock out just one byte at a time, which is triggered each time by an ADC->END event. I sample 13 times and then set the CSN high to trigger a SPIS->END event. In the SPIS->END interrupt handler I read out the data in RXDPTR. Every time a byte is clocked out on MISO, both RXDPTR and TXDPTR are incremented. If I set MAXTX = 1 the ADC->RESULT is read once and all subsequent bytes sent out on MISO are the ORC overread character. Anyway, this was a nice try gentlemen, but I think my attempt for making this work stops here unless you have some additional suggestions.

Related