Unable to implement receive data on UART interrupt on STM32F103C8T6

[JPanc.1]

I bought STM32 blue pill(STM32F103C8T6) and started learning on STM32 usng STM32CubeMX and TRUEStudio and successfully LED and UART2 transmitt.

But I want to implement UART receive using interrupt but unable to do so.I have tried as per example but still not getting data.Can any body help me with this?

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle)

is i right function for uart recive interrupt??? 

[Tesla DeLorean]

Well that's the callback function, you'd still need the USART IRQ Handler, and have that call back into the HAL, and with the NVIC side enabled. And the part would actually need to be physically receiving valid data for the USART to accept it.

[JPanc.1]

Can you please give me an example??

[JPanc.1]

Please anybody provide some steps for UART receive interrupt

[Guenael Cadier]

Hello,

If not already done, you could download STM32F1xx FW package from st.com at following adress :

https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-mcu-mpu-packages/stm32cubef1.html#overview

Then, in Projects directoy of this package, a lot of code examples are provided. For your question related to UART reception in Interrupt mode, you might have a look to below examples (exapmples running on STM32F103RB-Nucleo board, but exists also for other baords) :

• Projects\STM32F103RB-Nucleo\Examples\UART\UART_TwoBoards_ComIT : example highlighting communication between Nucleo boards, using HAL API (with IRQ enabling done in HAL_UART_MspInit() function)
• Projects\STM32F103RB-Nucleo\Examples_LL\USART\USART_Communication_Rx_IT : example highlighting reception from PC com port using VCP, in IT mode, using LL API.

Hope this helps.

Best regards.

Guenael

[JPanc.1]

Now I am able to receive data on uart 2 and display on PC's serial port.

But there is a long space between 2 data.

Please help me to solve out this I also attached snaps.

For an example, I send three times ''Hello world " from pc's serial port and STM32 reflect back on pc's serial but there is a long spaces between two data.

I share my receive callback function and snap of serial port of PC.

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
	{
		uint8_t i;
		if (huart->Instance == USART2)             //is current uart?
		{
			if (Rx_indx == 0)                       //if data is not being received
			{
 
				for(i=0; i<100 ; i++)
					Rx_buffer[i] =0;
 
			}
			if (Rx_data[0]!='\n')                     //if received data different from ascii 13 (enter)
			{
				Rx_buffer[Rx_indx++]= Rx_data[0];     // store data in buffer
			}
			else 																	// if received data = 13
			{
				Rx_buffer[Rx_indx] = '\n';
				Rx_indx= 0;
				sprintf(Tx_buffer,Rx_buffer,sizeof(Rx_buffer));
				HAL_UART_Transmit_IT(&huart2, Tx_buffer, sizeof(Tx_buffer));
			}
			HAL_UART_Receive_IT (&huart2, Rx_data, 1);     // activate receive
		}
	}

[S.Ma]

This seems to show that the provided usart examples needs to be closer to application needs and require xtra work for most dev people?

[Guenael Cadier]

Hello,

What do you mean by "a long space between 2 data" ? is there some time between typing "Hello world" in your console, and seeing it printed back ?

Could you try to use Rx complete callback, only to catch the information of Reception sequence completed, and to perform buffer reset, buffer analysis + scheduling of new HAL transactions (Transmit, and/or next reception) out of HAL_UART_RxCpltCallback callback ?

Please remind this callback is executed in Interrupt context.

2 other things to check :

• Please note that current call of HAL_UART_Transmit_IT(&huart2, Tx_buffer, sizeof(Tx_buffer)) as shown in your code sample, will lead to sending of 100 bytes, whatever the size of entered string.
• arguments passed to sprintf call seems strange in my opinion. Not sure to understand what you want to do here .

regards

Guenael

[Clive1 (HNL)]

Or that the HAL simply fails to do the job adequately? It is over engineered, and STILL doesn't manage buffering properly and is apt to fail or block rather than add data to a queue. More examples help in most cases, here the basic paradigm is broken.

#NotFitForPurpose

[Clive1 (HNL)]

The use of HAL_UART_Transmit_IT() takes no account of the disparity in size between the output and the frequency of the callback, nor if a current request is already pending, or recovering if an error is returned.

The whole HAL UART subsystem is VERY POORLY conceived and doesn't fit well with any normal buffering and processing scheme. Interrupt processing needs to be simple and elegant, and not dwell for multiple byte times on a system with NO internal FIFO. The "callback" hides the fact it is called in interrupt context so the user imagines they can perform complex tasks, which in reality need to be posted for some worker task to consume.

ST needs to do some serious soul searching as to why this all such a complete cluster f**k of a design.