• State Not Answered
  • Replies 11 replies
  • Subscribers 62 subscribers
  • Views 4034 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 125855
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Measuring elapsed microseconds between 12 successive rising edges on 12 GPIOS on NRF52832 DK

Enero

Hi everyone,

I'm new with nrf52832, and I need to measure elapsed time in microsecond between rising edges of 12 different Gpios. I have 12 piezoelectric sensors filtered, amplified, getting a 0V-3.3V Logic level in input. Once one of these senors rises up, I need to start counting microseconds and store corresponding elapsed microsecond until I have 11 different values (assuming the first sensor's timing is 0). And then posting it over ble.

I red some documentations, and I heard about Timeslot API, timers and sys_tick, but I don't know which one would be better for my application.

Would you have any idea about how should I take this ?

Thanks for your help, and have a good day !

Parents
  • 0

    Hi,

    Have you considered using PPI? It is possible to have the Logic level input start a timer and a counter automatically. I'm not sure if I understand your use case, but it is e.g. possible to start a timer on the first Logic level event, then use a counter to count 11 logic level events, and finally stop the timer on the 11th event. All this can be done autonomously without using the CPU, Timeslot API, or sys ticks. The CPU can even be sleeping while you time your events. On the 11th event you can chose to trigger an interrupt to process your timer value. I wrote a little bit more about PPI at the bottom of this thread.

  • 0 in reply to MartinBL

    Happy to help. Apparently I didn't read your question thoroughly enough. I thought we talked about one GPIO and 12 incoming pulses, not 12 different GPIOs. Although you have 16 PPI channels, you only have 6 GPIOTE channels available (which I think is what you are referring to?). So now I don't see any obvious workarounds with PPI in your case. I don't know the details of you use case, but maybe it would be possible to:

    1. Configure the GPIOTE channels to measure a certain set of 6 pins
    2. Do 6 measurements
    3. Fire an interrupt routine and reconfigure the GPIOTE channels to use the 6 other pins.
Reply
  • 0 in reply to MartinBL

    Happy to help. Apparently I didn't read your question thoroughly enough. I thought we talked about one GPIO and 12 incoming pulses, not 12 different GPIOs. Although you have 16 PPI channels, you only have 6 GPIOTE channels available (which I think is what you are referring to?). So now I don't see any obvious workarounds with PPI in your case. I don't know the details of you use case, but maybe it would be possible to:

    1. Configure the GPIOTE channels to measure a certain set of 6 pins
    2. Do 6 measurements
    3. Fire an interrupt routine and reconfigure the GPIOTE channels to use the 6 other pins.
Children
No Data
Related