innomatic

Sometimes implementation of UART communication is asymmetric. In general, Rx tasks are time critical and total size of the data is unknown, thus it is best to handle the task in an interrupt service routine where individual incoming bytes are checked without delay. While Tx tasks can be implemented rather relaxed manner. For example, you can use a blocking call inside the main loop. In this sense, UART HAL functions provided by STM32Cube framework is useful for Tx but not very much so for Rx task. Thus you may have to write your own UART interrupt handler using LL drivers while still using HAL UART Tx functions in Tx task. Use STM32Cube to generate all the chores of setting the UART module except the interrupt part. LL interrupt is activated after the UART port is initialized using LL functions: Source file 414 void SerialComm_Init () 415 { 416 LL_USART_EnableIT_RXNE ( huart1 . Instance ); 417 } Then write the interrupt handler to call Rx routine:

In this post, actual pushbutton checking algorithm is explained. As discussed previously, it utilizes the software timer (UsrTimer) to address the chattering issue and to implement a multi-function input button. The main timer routine is registered by calling: Source file 103 // initialize the pushbutton handler with mask byte. 104 PushButton_Init ( 0x01 ); where the mask byte (0x01) indicates the location of the state bits of active buttons in the 8bit button state byte. Here we have only one button that is located at the first bit location. This call starts a timer routine that runs indefinitely at a predefined interval, PUSHBTN_TMR_PERIOD whose value is set to 80 msec at the moment. This period can be tuned to serve particular hardware better. However you have to remember that other parameters such as the duration values that determine short click and long click have reference to this value. For example PUSHBTN_TO_SHORT value is set to 3, which means tha

The Event Queue is a simple ring buffer, whose element is a byte array of fixed size. You can use it any purpose as long as it fits. When it is used as an event queue, the meaning of each byte is supposed to be defined by the user. In this example, we define the first byte as the event id followed by event data as below: Source file 73 /** Pushbutton input event 74 * 75 * Event Data: (PBTN_ID)(EVT_TYPE) 76 * 77 * * PBTN_ID: id of the pushbutton that generated the event 78 * * EVT_TYPE: type of the event such as single click, double click, 79 */ 80 #define EVT_PBTN_INPUT 0x10 ///< event code for pushbutton input 81 #define PBTN_SCLK 0x01 ///< single click 82 #define PBTN_LCLK 0x02 ///< long click 83 #define PBTN_DCLK 0x03 ///< double click 84 #define PBTN_TCLK 0x04 ///< triple click Posting an event is

Project Design Pushbuttons, or tactile switches are convenient way of interacting with the firmware, whether the final product retains them as its UI components or not. There are a couple of things to consider to implement the pushbutton handling features. Debouncing and Software Timer First you have to deal with the contact bouncing effect of the switch.  Following snapshot of  an oscilloscope from Wikipedia page illustrates one situation. However it can be radically different from one case to another. There are numerous ways of addressing the issue, each of which has its own pros and cons. So one method works better in one situation but not necessarily in other cases primarily depending on the chattering characteristics but also depending on other situations. Here we are going to use software timer, in which a timer routine checks (samples) the state of the switch with a regular interval. Short Click vs. Long Click, Single Click vs. Multiple Click Another consideration