button_event_handler and matrix

[JohnBrown]

I am using a simple 4 by 4 matrixed keypad, and I would like to handle some of the decoding myself. In essence, I would like to configure all 4 rows as low driven output pins and have the sd handle the 4 column inputs as though they were single buttons. Then, in the button event handler, I'd like to change the configuration of the rows to inputs with pull-ups, drive the columns low, and read the row inputs. After doing the decoding, I'll restore the original configuartion, i.e columns input with pull-ups, rows driven low. So nothing clever, just one of the standard ways of reading a simple matrix. My question is will this work, or will I need to disable the button_handler for the duration of the event handler by some means?

The alternative would be for me to configure a timer event and do the scanning manually, but I'm not sure which method would result in the lower power consumption.

[Hung Bui]

@JohnBrown: if you add your code inside GPIOTE_IRQ, think you should be fine. Make sure you don't clear the GPIO PORT event before you start your scanning. Then you can disable sense, modify the configuration to do the scanning. Then switch back to the original configuration, clear GPIO_PORT event, and continue to flip the SENSE signal for the signal which triggered the interrupt as we normally do with app_gpiote.

[JohnBrown]

I see. I was planning on using the button handling stuff(because it has debouncing and I know it works with the SD). I will check out what you're talking about.

John

[JohnBrown]

In the end, I decided to run a timer and have a periodic interrupt scan the matrix. The extra power consumption is fairly insignificant, I believe, but it's much simpler(and to my mind more reliable) than trying to use edge sensing via the GPIOTE. I may, however, use the GPIOTE sensing to start the timer/interrupts, and stop them again when the key is released. That way I should be able to reduce the power consumption slightly, unless a user keeps a button pressed for a while.

[Hung Bui]

@JohnBrown: I agree, the app_gpiote is getting pretty complicated and not really glitch free especially when it comes to multiple input sources and users. Your idea of using a timer for polling could be actually a good solution. The RTC and a short period of processing time with the CPU should not cause too much current consumption. Thanks for sharing the solution.

[HSA]

Hi @Hung Bui

I am also trying to configure the button_debounce handling while reading the pin_status during debouncing. I am following [--ble_app_lbs_master--] sample example. Please tell me the required modification to read the pin_status while button_press and debouncing.

/Thanks n Regards