10. Physical Buttons
Motivation
Physical buttons can function as external events usable as triggers from the TouchGFX Designer during application development, or simply used as events in the application backend.
Note
Goal
The goal of this section is to develop code that can be used in subsequent TouchGFX HAL- and/or application development.
Verification
Here are the verification points for this section:
| Verification Point | Rationale |
|---|---|
| MCU is configured | MCU GPIOs must be configured to read the state of connected physical buttons. |
| Connected GPIO can be read | Once code has been developed to read the physical button state from a GPIO this can be used in sub-sequent TouchGFX HAL development. |
| Reading performs as expected | Polling is a part of application render time. If polling takes too long this should be moved to a different thread or made interrupt based. |
Prerequisites
- Physical buttons must be connected to GPIOs on the MCU
Do
The following images show how the schematics might look for a physical button and how it is connected to the MCU
In STM32CubeMX GPIO Port C Pin 13 (PC13) can be configured as an input in the GPIO section of the System Core category:
In the dialog below we have also configured an internal pull-down for the GPIO. This is not necessary, if you have an external pull-down resistor (as on the above drawing). In that case you can select "No pull-up and no pull-down".
The code generated by STM32CubeMX will setup the appropriate GPIO port(s) accordingly. The input pins can now be read:
main.c
uint8_t key;
if (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) != GPIO_PIN_RESET)
{
key = 1;
}
Performance is as expected
Polling the state of physical buttons should be possible within 1 ms if the code is executed in the same thread as the TouchGFX Application. Otherwise you will delay the rendering too much. This is not a problem if you are using buttons directly connected to a GPIO, but it can be a problem if you are using e.g. a shift-register on I2C or similar. If the sampling is not fast enough, consider moving the code to a separate task, at a later stage or making it interrupt based.