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/stm32cubeide.html, and install it on a Windows computer.
• 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