I just included this in a build and it seems to boot with the screen off, then doesn't wake until the 2nd button press.

I just included this in a build and it seems to boot with the screen off, then doesn't wake until the 2nd button press.

This doesn't happen for me. Can you try the dfu artifact?

I had a bunch of other stuff merged so its likely something I did wrong, I'll try it again tomorrow.

@Riksu9000 is it will be possible to select which app will be tied to the long button?
because when i'm testing this only the notification popup and i would like to be able to have something other than notification(like heart counter, or the timer for instance)

@Riksu9000 is it will be possible to select which app will be tied to the long button? because when i'm testing this only the notification popup and i would like to be able to have something other than notification(like heart counter, or the timer for instance)

Yes, my plan was to allow selecting what app the double click opens. I was thinking that this could be integrated with #708.

Thanks for this newer new version of the button handler :)
I like that we don't need a dedicated task for the button! However, I'm thinking we might be able to go a bit further : in this version, SystemTask is triggered as soon as the debounce timer did its job. SystemTask then read the input state and delegate the processing to ButtonHandler, which is nice.

However, I'm wondering if button handler could be called directly after the debounce timer (or handle the debouncing in ButtonHandler?) That way, SystemTask would need to be woken up only when we know exactly which type of action (Short press, long press, double press) was triggered.

Any opinion?

The reason I use the timer to wake up SystemTask is to minimize the use of the Timer task. I have been thinking that the timer task is quite big, and if we only used it to push messages to other tasks, we could shrink its stack size saving memory.

That's a good reason, indeed!
As the functions we call in timers are short (with not many function calls), do you think the stack of the timer task will need to grow bigger?

As the functions we call in timers are short (with not many function calls), do you think the stack of the timer task will need to grow bigger?

Are you asking if the stack size would need to be increased if the button was handled in the Timer task? I don't think it would, and I suspect it is already quite oversized for just pushing messages. I can't really test things like that though other than just shrinking it until it crashes or something, so someone else would have to take a closer look at that.

That was also my impression. I was asking this question to see if pre-processing the button actions in the timer callback would cause any issue with the stack of the timer task.

In my opinion (but I might be wrong), it would make more sense if the system task was triggered only when the actual action (short press, long press, double press) is known, which would mean we would have to move some of the code from systemtask to the timer handler.

In my opinion (but I might be wrong), it would make more sense if the system task was triggered only when the actual action (short press, long press, double press) is known, which would mean we would have to move some of the code from systemtask to the timer handler.

We would first need to decide how the timer should be used. Allowing only to push messages means we should be able to determine a small and optimized stack size. If we instead used the timer to push messages AND handle the button, then it probably needs more memory. Now if the timer task also handles the button, why not use it to handle some other things as well, and soon we end up with another general task.

So we could avoid a task switch by possibly increasing memory usage. Would there be benefits to doing this?

Obviously right now using the timer would be fine, but this was done in preparation of shrinking it.

EDIT: Also there's a lot of guessing here, so these things would need to be checked more thoroughly.

We would first need to decide how the timer should be used.
I think this must be decided case by case. You're right, we must keep the stack of the timer task under control and as small as possible. In this case, the functions called by the timer to handle the button should not grow that much as they do not call a lot of nested functions and most of the memory is already allocated by the ButtonHandler.

Anyway, it's probably good enough, and we'll still be able to change the implementation if needed later on :-)