This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
en:iot-open:introductiontoembeddedprogramming2:cppfundamentals:programmingpatterns [2023/11/17 14:36] – pczekalski | en:iot-open:introductiontoembeddedprogramming2:cppfundamentals:programmingpatterns [2024/05/27 10:53] (current) – [Finite State Machine] ktokarz | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Programming patterns ====== | ====== Programming patterns ====== | ||
+ | {{: | ||
This chapter presents some programming templates and fragments of the code that are common in embedded systems. Some patterns, such as non-blocking algorithms, do not use '' | This chapter presents some programming templates and fragments of the code that are common in embedded systems. Some patterns, such as non-blocking algorithms, do not use '' | ||
[[en: | [[en: | ||
- | ===== Tracing vs Debugging - Serial Ports ===== | + | ==== Tracing vs Debugging - Serial Ports ==== |
Almost any MCU has a hardware debugging capability. This complex technique requires an external debugger using an interface such as JTAG. Setting up hardware and software for simple projects may not be worth a penny; thus, the most frequent case is tracing over debugging. Tracing uses a technique where the Developer explicitly sends some data to the external device (usually a terminal, over a serial port, and eventually a display) that visualises it. The Developer then knows the variables' | Almost any MCU has a hardware debugging capability. This complex technique requires an external debugger using an interface such as JTAG. Setting up hardware and software for simple projects may not be worth a penny; thus, the most frequent case is tracing over debugging. Tracing uses a technique where the Developer explicitly sends some data to the external device (usually a terminal, over a serial port, and eventually a display) that visualises it. The Developer then knows the variables' | ||
Note to use a '' | Note to use a '' | ||
Line 22: | Line 23: | ||
* '' | * '' | ||
- | ===== Interfacing with the Device - Serial Port ===== | + | ==== Interfacing with the Device - Serial Port ==== |
The serial port and a class '' | The serial port and a class '' | ||
<note important> | <note important> | ||
Data in the serial port are sent as bytes; thus, it is up to the developer to handle the correct data conversion. Reading a single byte of the data using '' | Data in the serial port are sent as bytes; thus, it is up to the developer to handle the correct data conversion. Reading a single byte of the data using '' | ||
- | ===== Hardware buttons | + | ==== Hardware buttons ==== |
Hardware buttons tend to vibrate when switching. This physical effect causes bouncing of the state forth and back, generating, in fact, many pulses instead of a single edge during switching. Getting rid of this is called debouncing. In most cases, switches (buttons) short to 0 (GND) and use pull-up resistors, as in the figure {{ref> | Hardware buttons tend to vibrate when switching. This physical effect causes bouncing of the state forth and back, generating, in fact, many pulses instead of a single edge during switching. Getting rid of this is called debouncing. In most cases, switches (buttons) short to 0 (GND) and use pull-up resistors, as in the figure {{ref> | ||
<figure pullupsample> | <figure pullupsample> | ||
Line 67: | Line 68: | ||
A more advanced technique for complex handling of the buttons is presented below in the context of the State Machines. | A more advanced technique for complex handling of the buttons is presented below in the context of the State Machines. | ||
- | ===== Finite State Machine | + | ==== Finite State Machine ==== |
A Finite State Machine (FSM) idea represents states and flow conditions between the states that reflect how the software is built for the selected system or its component. An example of button handling using the FSM is present here. The FSM reflects the physical state of the device, sensor or system on the software level, becoming a digital twin of a real device. | A Finite State Machine (FSM) idea represents states and flow conditions between the states that reflect how the software is built for the selected system or its component. An example of button handling using the FSM is present here. The FSM reflects the physical state of the device, sensor or system on the software level, becoming a digital twin of a real device. | ||
Line 80: | Line 81: | ||
A flow between the states can be then described in the following diagram (figure {{ref> | A flow between the states can be then described in the following diagram (figure {{ref> | ||
<figure statemachine> | <figure statemachine> | ||
- | {{ : | + | {{ : |
< | < | ||
</ | </ | ||
Line 94: | Line 95: | ||
unsigned long tDebounceTime; | unsigned long tDebounceTime; | ||
unsigned long DTmr; | unsigned long DTmr; | ||
- | void(*ButtonPressed)(void); | + | void(*ButtonPressed)(void); |
- | void(*ButtonReleased)(void); | + | void(*ButtonReleased)(void); |
- | void btReleasedAction() { | + | void btReleasedAction() { //Action to be done |
+ | //when current state is RELEASED | ||
if(digitalRead(ButtonPin)==LOW) { | if(digitalRead(ButtonPin)==LOW) { | ||
buttonState = DEBOUNCING; | buttonState = DEBOUNCING; | ||
Line 102: | Line 104: | ||
} | } | ||
} | } | ||
- | void btDebouncingAction() { | + | void btDebouncingAction() { //Action to be done |
+ | //when current state is DEBOUNCING | ||
if(millis()-DTmr > tDebounceTime) | if(millis()-DTmr > tDebounceTime) | ||
if(digitalRead(ButtonPin)==LOW) { | if(digitalRead(ButtonPin)==LOW) { | ||
Line 111: | Line 114: | ||
buttonState=RELEASED; | buttonState=RELEASED; | ||
} | } | ||
- | void btPressedAction() { //Action to be done when current state is PRESSED | + | void btPressedAction() { |
+ | //when current state is PRESSED | ||
if(digitalRead(ButtonPin)==HIGH) { | if(digitalRead(ButtonPin)==HIGH) { | ||
buttonState=RELEASED; | buttonState=RELEASED; | ||
Line 118: | Line 122: | ||
} | } | ||
public: | public: | ||
- | PullUpButtonHandler(uint8_t pButtonPin, unsigned long pDebounceTime) { // | + | PullUpButtonHandler(uint8_t pButtonPin, unsigned long pDebounceTime) { |
+ | // | ||
ButtonPin = pButtonPin; | ButtonPin = pButtonPin; | ||
tDebounceTime = pDebounceTime; | tDebounceTime = pDebounceTime; | ||
} | } | ||
- | void fRegisterBtPressCalback(void (*Callback)()) { //Function registering a On PRESSED callback | + | void fRegisterBtPressCalback(void (*Callback)()) { |
+ | //Function registering | ||
+ | //a button | ||
ButtonPressed = Callback; | ButtonPressed = Callback; | ||
} | } | ||
- | void fRegisterBtReleaseCalback(void (*Callback)()) { //Function registering a On RELEASED callback | + | void fRegisterBtReleaseCalback(void (*Callback)()) { |
+ | //Function registering | ||
+ | //a button | ||
ButtonReleased = Callback; | ButtonReleased = Callback; | ||
} | } | ||
- | void fButtonAction() | + | void fButtonAction() |
- | { | + | //Handles state machine logic |
+ | { //along with private functions above | ||
switch(buttonState) { | switch(buttonState) { | ||
case RELEASED: btReleasedAction(); | case RELEASED: btReleasedAction(); | ||
Line 165: | Line 175: | ||
} | } | ||
</ | </ | ||
- | <note important> | + | <note important> |
The great feature of this FSM is that it can be easily extended with new functions, such as detecting the double click or long button press. | The great feature of this FSM is that it can be easily extended with new functions, such as detecting the double click or long button press. | ||