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

low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Dear all,

I need to measure a pulse width on a GPIO pin which is in between 100mseconds and 7.2 seconds long without the use of "regular" timers due to low power requirements. I am pretty sure this can be done with PPI and the 32.768 kHz lfclock ( which runs anyway due to S210 use ). But I am simply lost in the examples and driver docs. Especially as I base my work on the bikepower ANT+ example which uses the board support package and app_button. Due to this I cannot copy-paste any code example as this always conflicts with something in the BSP or app_button.

Is there a hint which drivers / app_whatever to "implement" into existing examples that use BSP and app_button to connect a GPIO via PPI to a lsclock counter/timer ?

I "simply" need to start a lsclock counter by a GPIO pin interrupt (Low-High) and stop it by a high-low interrupt. Sadly I seem to be unable to do implement this simple task into the existing example code. As my max pulsewidth is > 10 seconds, a 16 bit counter is not sufficient @ 32.768 kHz clock. I am not sure if I can handle timer overflows due to the softdevice interrupting my program at any time.

Anyhow, the RealTimeCounter is 24 bits which is enough for my purpose. So, with RTC prescaler = 0 ( as used in app_button like it seems..) I could store the current TICK count at the low-high interrupt and then compare to the TICK count at the high-low interrupt and that's it. The counter roll-over case could be handled outside the ISR.

Just: How to do it ?

Any help like "remove this driver, add that one, re-use this timer.. " is very appreciated.

Thanks a lot, Wolfgang

Parents
  • It doesn't matter if ap_twi uses it - not that it could, if it did you'd have multiple GPIOTE_IRQHander() functions and your code wouldn't link. All that unavailable error code means is that the interrupt is unavailable because the softdevice uses it, and since we know it doesn't, it must be the other one.

    Since you say you don't set the priority - that's your problem - default 0, softdevice doesn't like that. Set it to APP_PRIORITY_HI or LO or whatever the constants are. There's an sd_* function for that too, or just call the NVIC_* one

    I wonder why Keil eats error codes, don't use it myself. Often feel like using Keil must be like ploughing a field with a horse, possible, but really hard work.

Reply
  • It doesn't matter if ap_twi uses it - not that it could, if it did you'd have multiple GPIOTE_IRQHander() functions and your code wouldn't link. All that unavailable error code means is that the interrupt is unavailable because the softdevice uses it, and since we know it doesn't, it must be the other one.

    Since you say you don't set the priority - that's your problem - default 0, softdevice doesn't like that. Set it to APP_PRIORITY_HI or LO or whatever the constants are. There's an sd_* function for that too, or just call the NVIC_* one

    I wonder why Keil eats error codes, don't use it myself. Often feel like using Keil must be like ploughing a field with a horse, possible, but really hard work.

Children
  • Jepp, RK , that's it. I set the interrupt priority to "1" ( no, no 37-letter-define used ) and it works. Thanks a lot ! So, maybe the nrf_drv_gpiote_in_init I originally wanted to use also defaults to interrupt priority 0 and thus failed ? Again, thanks to all for helping me out. Over time, the number and stupid-ness of my questions will degrade :-)

Related