This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

AN36 button state

As far as I can see buttons_init() initializes GPIO and sets up button_event_handler(). button_event_handler() calls ble_lbs_on_button_change() and always set static uint8_t set_push to 1, which is written to params.p_data and transferred to sd_ble_gatts_hvx().At the end uint set_push is logically inverted. If I understood this logic correctly than the code does NOT read the current button state but makes an assumption that it has been changed to inverse and modifies set_push every time ble_lbs_on_button_change() is called. Am I reading this correctly?

Parents
  • You're correct that this will just toggle the state on every button press. This was a simplification that was done since app_button doesn't give you an event on both edges of a press in the current SDK versions. It's also noted in the text, right at the start of section 4.4.5: "To finish the application, you need to define how to handle button presses. Use the app_button module that is part of the SDK for this. This module will give a callback each time the button is pressed, essentially making the characteristic toggle its state for each press."

    If you want to modify this to toggle at each edge of the button press, the easiest way is to use app_gpiote instead of app_button, but this was deemed too much extra complexity for the application note, compared to the benefit it gives.

  • I'm not sure I understand what you mean. The original question talks about the button_event_handler, which has not been mentioned anywhere before section 4.4.5. The service code itself makes no assumptions about anything, it just sends whatever value it got in.

    As I note in my answer, you're correct that the application code makes an assumption, which as far as I can see is explained where the assumption is actually made in the document.

    In case either you or someone else stumbling upon this wanted different behavior, I thought it would be useful to include a quick note on how that could be achieved.

Reply
  • I'm not sure I understand what you mean. The original question talks about the button_event_handler, which has not been mentioned anywhere before section 4.4.5. The service code itself makes no assumptions about anything, it just sends whatever value it got in.

    As I note in my answer, you're correct that the application code makes an assumption, which as far as I can see is explained where the assumption is actually made in the document.

    In case either you or someone else stumbling upon this wanted different behavior, I thought it would be useful to include a quick note on how that could be achieved.

Children
No Data
Related