This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DMA for SPI master

I'm reading AD-converter data usin nRF51822 SPI-Master. BLE-stack is active so I can't use interrupts with SPI. I get data every 2 ms. Sometimes Events are delayed so long that I get erroneous data from AD.

Is there some way to implement DMA for the SPI-Master, maybe using SPI-slave some way?

Juha Okkonen

Parents
  • Hi Audun,

    Could you please elaborate on how to synchronize radio activity with the AD reading to achieve 500Hz reading?

    I'm in the same situation as Juha that the AD interupts every 2/4/8 milliseconds. And unfortunately, the AD conversion data has to be read out before the next interrupt comes.

    Thanks, Bruce

  • Ah, I understand better now. Length of the radio interrupt is determined by: a) How much data you have put in the softdevice TX buffer b) Procedures initiated by the Master (channel map update, encryption, etc.)

    The softdevice will always try to send as many packets as possible during a single connection event. If you are sending multiple packets, the radio interrupt could be significantly longer (the Master actually decides how many packets can be sent during a connection interval). So, dont put more than X packets (I'm not sure of the exact number) in the TX buffer at a time. Then wait until you get a BLE_EVT_TX_COMPLETE event until you put in more. Secondly, there are control procedures that can happen at any time. There will typically be channel map updates once in a while, but I'm not sure exactly how long radio interrupt that will cause.

    Anyway, I suggest using the radio notifications to trigger a GPIO, and use a logic analyzer or oscilloscope to see how long each interrupt actually takes. You can also have a main loop that toggles a GPIO, and you will see the toggling stopping during interrupts. This will give you a better feel of exactly how long each interrupt is. Note that some control procedures, such as channel map updates, is not something the application is aware of, and you would need a BLE sniffer to see when this is happening.

Reply
  • Ah, I understand better now. Length of the radio interrupt is determined by: a) How much data you have put in the softdevice TX buffer b) Procedures initiated by the Master (channel map update, encryption, etc.)

    The softdevice will always try to send as many packets as possible during a single connection event. If you are sending multiple packets, the radio interrupt could be significantly longer (the Master actually decides how many packets can be sent during a connection interval). So, dont put more than X packets (I'm not sure of the exact number) in the TX buffer at a time. Then wait until you get a BLE_EVT_TX_COMPLETE event until you put in more. Secondly, there are control procedures that can happen at any time. There will typically be channel map updates once in a while, but I'm not sure exactly how long radio interrupt that will cause.

    Anyway, I suggest using the radio notifications to trigger a GPIO, and use a logic analyzer or oscilloscope to see how long each interrupt actually takes. You can also have a main loop that toggles a GPIO, and you will see the toggling stopping during interrupts. This will give you a better feel of exactly how long each interrupt is. Note that some control procedures, such as channel map updates, is not something the application is aware of, and you would need a BLE sniffer to see when this is happening.

Children
No Data
Related