Force GPIOTE event manually.

RE: Force GPIOTE event manually.

SeanHowsonTB — Wed, 19 Oct 2022 14:53:49 GMT

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

RE: Force GPIOTE event manually.

Einar Thorsrud — Wed, 19 Oct 2022 14:37:50 GMT

Hi Sean,

[quote user="SeanHowsonTB"]IMHO altering the SDK counstitutes as a dirty hack[/quote]

You could say that. And I agree that you should try to avoid it . But in reality, the SDK does not cover all use cases even though we try to make it as generic as possible, and also, it is not bug free. So it is not uncommon to have to change the SDK code, even though it is not ideal.

[quote user="SeanHowsonTB"]If i'm being honest, while i appreciate the solution you've presented it really sounds like a long winded solution for a very simple problem. [/quote]

I fully agree. 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. I do not like that approach at all, though, as mentioned.

I see the problem with interpreting the button press when it is a wakeup source. I would consider doing this with a completely different approach, handling the startup case as a special case, and using some dedicated code to handel it without the app_button library. You could still use the app_timer (with a dedicated instance) to do the debouncing. This would involve a bit more code so perhaps not ideal, but you would not have to do any changes in the SDK, and you will not have to do any other dirty hacks.

RE: Force GPIOTE event manually.

SeanHowsonTB — Wed, 19 Oct 2022 13:54:03 GMT

Einar, thanks for the reply.

The goal is, as is it was in my original post. Allow the chip to enter shutdown mode. Wake up from the button press and have the button press event handler run (the handler i registered to the button when initialising the app_button).

But i've found that this does not happen because the debounce timer is never started. So i am trying to manually start the chain of events that leads to my button handler being run. I am asking about the gpiote event handler because this seems to be the first domino in the chain/ first item in the call stack, that drives the app_button library. So it seemed sensible to start from the top... I tried just calling the contents of my custom app_button handler. But the app_button library, then doesn't "know" that the button has been pushed, subsequently when the button is released, my app_button handler does not run.

the chain of events i've described, runs my custom event handler, and other functions that tell the app_button library that the button is pressed. I find it odd that i seemingly cant initialised the app_button library in the "already pressed" state... anyway, another approach might be to make sure app_button library to understand that the button is pressed. so that my handler runsproperly when the button is released, that way i could manually run my handler (which is global), once upon startup, to register the press, tell the libary the button is pressed. Then the handler will run just fine when the button is released. This is the equivilent of running all the things that would be triggered by manually calling the GPIOTE event handler as id originally proposed.

I had considered & tried copying chunks of code from the functions run as a result of the debounce timer etc. But the ones i've tried require access to global variables within the app_button library, so basically the same problem i have with calling functions... (scope!)

I take your point on not having a dirty hack. I am not a fan of dirty code so would agree here. IMHO altering the SDK counstitutes as a dirty hack (this isn't the only reason i cant change it). But the purpose of this forum post is to see if there is a non-dirty-hack solution that i'm not aware of.

If i'm being honest, while i appreciate the solution you've presented it really sounds like a long winded solution for a very simple problem. While i appreciate the out-of-the-box idea, it's really not suitable for a peice of firmware being deployed into an active product and makes automation of piplining & deployment very tricky and it could easily result in some serious errors in future, especially when trying to pass the code around multiple developers & use in multiple debugging environments.

Thanks, sorry for the long reply,

Sean

RE: Force GPIOTE event manually.

Einar Thorsrud — Wed, 19 Oct 2022 12:28:06 GMT

Hi Sean,

May I ask why you want to call the event handler directly in the first place? What is the end goal? And can you potentially achieve the end goal in another matter (for instance by doing the same as the event handler from another function)?

Also, while I understand that in some cases you may have qualified the SDK as is and cannot change it, it seems a bit unfortunate that it leads to a the need for potentially dirty hacks. It seems counter productive if the goal of not changing the SDK is related to quality somehow.

If this really is the approach you need to use, then perhaps an alternative could be this: Read a function pointer from a specific address (for simplicity you could perhaps put it in UICR for testing, but in order to support DFU etc later it should be in normal flash). Call that function pointer when you want to call the static event handler. Then, after you have built the project, check the map file to find the address of the event handler, and write that to the location that should hold the function pointer. This could be done manually first for testing. When you get this working, you can script this so that you automatically parse the map file and modify the hex file, writing the address/pointer to the fixed location you have reserved for it.

Einar