Force GPIOTE event manually.

Using SDK17.1.0, I need to manually force an event handler to run. But the event handler is part of the SDK and is declared static. Key constraint is that i cannot modify the SDK.

I'm using the app_button library. But the handler i registered for the button doesn't run when the chip is wakes up from shutdown mode (following button press). I am aware this is because the debounce timer doesn't start (started in the gpiote event handler).

I tried manually running my local app_button handler, but of course this skips many steps within the app_button library and causes all sorts of problems. So, essentially i need to call a function from further back in the call stack/ chain of events.

But every function that potentially provides a route to triggering the app_button event handler is declared static or is out of scope of my code.

The event handler i'd like to trigger is below: (line 245 app_button.c)

 

static void gpiote_event_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    app_button_cfg_t const * p_btn = button_get(pin);
    bool is_set = nrf_drv_gpiote_in_is_set(p_btn->pin_no);
    bool is_active = !((p_btn->active_state == APP_BUTTON_ACTIVE_HIGH) ^ is_set);

    /* If event indicates that pin is active and no other pin is active start the timer. All
     * action happens in timeout event.
     */
    if (is_active && (m_pin_active == 0))
    {
        NRF_LOG_DEBUG("First active button, starting periodic timer");
        timer_start();
    }
}

Ideally i could do to find the memory location in which the pointer to the above handler is stored (when it is initialised). i could, for example, do this using the following code:

   nrfx_gpiote_evt_handler_t handler = channel_handler_get((uint32_t)channel_port_get(BTN_PIN));
         handler(BTN_PIN, GPIOTE_CONFIG_POLARITY_HiToLo);       

But again, both of these functions are static.

 

Ideally, i'm looking for suggestions of global functions that can be used to retrieve a pointer to the gpiote event handler (the one in the first extract of code above). Or some other way of manually forcing a button action. Even if i could perhaps manually force the pin's IRQ at register level?

Thanks,

Sean

Parents
  • Cant find the quote tool, to i've inserted this as code! -_-

     But it was a suggested solution for how to call a static function without changing the code that is static, which is what you describe.

    Yep all reasoning here is sound & appreciate you giving a solution regardless or whether it was dirty. Had i been working in assembler, or on a platform where i perhaps had much better control over the linker i would have considered the option. but as we've both agreed, the more layers you add, the less you want to mess around with the deeper layers/foundations. Thanks for the solution regardless, an interesting thought experiment if nothing else!

    Thanks for the suggestion at the bottom of your last reply. You might not be far off. I could perhaps have a special case, where we accept that for the first press and release, app_button does nothing. then begin handling things through app_button library.... or something similar to this.

    Currently, my button only generates actions based on a couple of fairly specific button presses, (long, super long, and some other special criteria, way outside the realms of normal mechanical bounce)... regardless, what this means is that i have some inbuilt debounce. I was only using the app_button library because months ago, i struggled to get gpiote to work on it's own. While trying to solve this issue i've gained a deeper insight to the app_button library & it may be that i can peel back a layer and just use the GPIOTE library alone.

    I appreciate you working around my requirements and appreciate the feedback, opinions & discussion. It seems you've confirmed that there isn't some "non-static" function i wasn't aware of and i'll have to take some other approach outside of app_button (special cases, or maybe just GPIOTE on it's own). Thanks for the help. I think this concludes my original query regarding functions & pointers so will mark the case closed. Have a good one.

    -S

Reply
  • Cant find the quote tool, to i've inserted this as code! -_-

     But it was a suggested solution for how to call a static function without changing the code that is static, which is what you describe.

    Yep all reasoning here is sound & appreciate you giving a solution regardless or whether it was dirty. Had i been working in assembler, or on a platform where i perhaps had much better control over the linker i would have considered the option. but as we've both agreed, the more layers you add, the less you want to mess around with the deeper layers/foundations. Thanks for the solution regardless, an interesting thought experiment if nothing else!

    Thanks for the suggestion at the bottom of your last reply. You might not be far off. I could perhaps have a special case, where we accept that for the first press and release, app_button does nothing. then begin handling things through app_button library.... or something similar to this.

    Currently, my button only generates actions based on a couple of fairly specific button presses, (long, super long, and some other special criteria, way outside the realms of normal mechanical bounce)... regardless, what this means is that i have some inbuilt debounce. I was only using the app_button library because months ago, i struggled to get gpiote to work on it's own. While trying to solve this issue i've gained a deeper insight to the app_button library & it may be that i can peel back a layer and just use the GPIOTE library alone.

    I appreciate you working around my requirements and appreciate the feedback, opinions & discussion. It seems you've confirmed that there isn't some "non-static" function i wasn't aware of and i'll have to take some other approach outside of app_button (special cases, or maybe just GPIOTE on it's own). Thanks for the help. I think this concludes my original query regarding functions & pointers so will mark the case closed. Have a good one.

    -S

Children
No Data
Related