Design Considerations for Serial Communications in an RTOS Environment
Peifang Zhou - Watch Now - Duration: 01:53:08
Serial communications such as console are prevalent in the embedded software development. This workshop will explore options and tradeoffs when implementing serial communications in an RTOS environment, in particular the methods to receive serial data and the interactions between ISR and the data receiving task. The workshop will go through standard techniques and present a simple yet powerful design for high-speed and bursty serial traffic.
The workshop uses an STM32 board for hands-on experience. Any STM32 board is fine. STM32CubeIDE is used to generate the initial startup code to save time. A simple terminal program named Termite is used for serial communications between the STM32 board and a Windows computer. To maximize the benefits of hands-on experience, the hardware and software requirements are detailed below:
- STM32 board – an STM32 Nucleo-64 board is recommended since it is low-cost and uses a single USB cable for power, debugging, programing, and serial communications. It requires little effort to get started quickly.
- USB cable to connect the STM32 board to a Windows computer.
- IDE – Create a user account, download STM32CubeIDE from ST website https://www.st.com/en/
development-tools/, and install it on a Windows computer. stm32cubeide.html
- Terminal program – go to the Termite website https://www.compuphase.com/software_termite.htm, click the “Termite version 3.4 (program only) (76 KiB)” link, unzip the downloaded file in any folder on a Windows computer, and double-click Terminite.exe to run the program.
It would save time to review one of the following documents to identify the UART Rx/Tx pins and the user LED pin (optional) before the start of the workshop:
- user manual – under the Documentation tab of the board webpage, or
- schematic – under the CAD Resources tab of the board webpage
For example, the STM32 Nucleo-F303RE webpage is https://www.st.com/en/evaluation-tools/nucleo-f303re.html#. Under the Documentation tab, there is a link to the user manual “UM1724STM32 Nucleo-64 boards (MB1136)”. Under the CAD Resources tab, there are three links to the Rev. C03/C04/C05 board schematics. On STM32 Nucleo-64 boards marked with the MB1136 identifier, USART2 interface is available on the PA2/PA3 pins and LD2 is a user controlled green LED connected to the PA5 pin.
Note that the examples from the workshop are only intended to illustrate concepts. For the ease of presentation, they are much simpler than the production-level source code developed in real-world projects.
13:23:30 From Michael Kirkhart to Everyone: Should be %d\n 13:24:31 From Michael Kirkhart to Everyone: LD2_GPIO_Port 13:25:08 From Michael Kirkhart to Everyone: It is giving you a hint in the error message 13:26:24 From Michael Kirkhart to Everyone: We can see it working 13:33:08 From Dave Comer to Everyone: Why did you not put the enabling of huart in user protected code region? 13:34:50 From Simon Smith to Everyone: All manually added code needs to be between the USER CODE BEGIN and USER CODE END sections, or will be deleted the next time it's code generated. 13:35:24 From Dave Comer to Everyone: That was the reason I asked my question. I think he placed the code above the user area…am I incorrect? 13:35:29 From Charles Miller to Everyone: Been burned by that many a time, Simon! 13:35:54 From Simon Smith to Everyone: me too, but Git helps 13:36:09 From Charles Miller to Everyone: Reacted to "me too, but Git help..." with 👍 13:39:31 From Chris Williams to Everyone: Something should be "==" 13:39:40 From Chris Williams to Everyone: Line 329 13:41:49 From Chris Williams to Everyone: != actually, it's fixed 13:45:34 From Martin Zimmerman to Everyone: the ability to use multiple buffers is NOT related to which method you use for notifying the command task. You could use multiple buffers with ANY of these. 14:04:07 From Raul Pando to Everyone: When using DMA transfers should one also have to cover the detection of any potential data overruns caused by non-fetched UART data in time, just in case the DMA doesn't get reloaded/armed promptly or there is no need to consider this? 14:04:36 From Nathan O. to Everyone: How do you choose to have 4 buffers ? and not 2 or 6 ? 14:07:09 From Martin Zimmerman to Everyone: really depends on your protocol. 14:08:18 From Martin Zimmerman to Everyone: the most common use of this would use command / response. In that case, each command waits for a response, which also acts as basic flow control. In that scenario you wouldn't need multiple buffers. 14:14:24 From Simon Smith to Everyone: Thankyou, much appreciated your talk as I've had some of these problems with the standard IRQ approach. 14:14:26 From Martin Zimmerman to Everyone: actually, idle line detection is used as a workaround for the fact that DMA uses fixed length transfers. Idle detection allows you to detect the end of a variable length command that is shorter than the DMA transfer size. 14:16:50 From Gonzalo to Everyone: When do you consider it is really necessary to use hardward Flow control? i mean 4 wires uart adding CTS and RTS singnaling 14:17:28 From Bob Fish to Everyone: To what extent does a mixed transmission line determine what software implementation to select i.e. wireless (RF, optical), wired (electrical)? 14:19:38 From Martin Zimmerman to Everyone: STM32 can typically keep up at 115200, you would typically need HW flow control for baud rates higher than that. 14:20:18 From Henry Okoro to Everyone: @Gonzalo, that depends if your application has the pins available to do that. it also depends on the baud and the buffer, as buffer overflow prevention could call for CTS/RTS 14:21:52 From Martin Zimmerman to Everyone: however, there is a firmware issue with the STM32 UART implementation that causes issues with HW flow control. It only works properly if the sender is "well behaved", and by their definition all of the USB to UART parts (FTDI, CP2104, etc) all are not "well behaved" and trigger the issue. 14:23:36 From Gonzalo to Everyone: Thanks for your answers. I asked because I had a device that sent very long strings and my buffers overun with unpredictible length, so Rx and Tx seem not to be enough 14:29:11 From Martin Zimmerman to Everyone: On STM32 you can use DMA in continuous mode (sometimes also referred to as circular mode). The SMT32 DMA will generate an interrupt at the half-complete and complete points of the transfer. You can leverage this to copy data out of the half of the buffer that just completed while DMA is copying to the other half). 14:34:12 From Bob Fish to Everyone: This applies beyond a relatively straight-forward serial interface ... i.e. a link that incorporates numerous technologies (wired / wireless) that have numerous characteristics 14:42:29 From Erwin Pschernig to Everyone: In Germany we often say: I2C = two wires, twice the Problems :-) 14:42:42 From Jacob Beningo to Everyone: Reacted to "In Germany we often ..." with 👍 14:46:11 From Martin Zimmerman to Everyone: Reacted to "In Germany we often ..." with 👍 14:46:38 From Martin Zimmerman to Everyone: ha ha ha… yeah I2C often comes with a world of issues. 14:48:00 From Lisa Shi to Everyone: Reacted to "ha ha ha… yeah I2C o..." with 👍 14:52:20 From Nathan O. to Everyone: Depending on the noise and the environement, you might want to look at things like RS485 or CAN bus also (also with more than 2 devices) 14:53:03 From Martin Zimmerman to Everyone: there are HW solutions that translate I2C into differential signalling over a twisted pair (NXP's PCA9615) which can use ehternet cabling to extend distances well beyond what I2C normally can handle. 14:55:17 From SR to Everyone: Thanks! 14:55:17 From Gonzalo to Everyone: Thank you very much for this chat! 14:55:27 From ggallardo to Everyone: thanks! 14:55:33 From Fabio to Everyone: Thanks