Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

STM32 HAL - Getting data from RS232

ElecDesigner

Member level 5
Joined
Jul 22, 2014
Messages
86
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Activity points
2,107
Im using a STM32 with Cube IDE.

Im using the HAL UART libaries and using the function HAL_UART_Receive_IT which has decleration:
HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

I am calling this fuction using:
HAL_UART_Receive_IT(&huart2, (uint8_t *)inData, 1);

I only want to get one character at a time, but have found that I always have to define inData as an array i.e.
uint8_t inData[1];
to get it to work. How do I make is work with a single uint8_t
 

KlausST

Super Moderator
Staff member
Joined
Apr 17, 2014
Messages
23,036
Helped
4,716
Reputation
9,448
Reaction score
5,091
Trophy points
1,393
Activity points
152,610
Hi,

in my eyes: What you want to do does not make sense.

you use the ".._IT" function.
This means when a data is received, then in the receive ISR the data is stored in the array.
But if the size of the array is just one byte ...
...what do you gain
* from the buffer (= array)
* using an interrupt?

*****
The "..._IT" function is non blocking. It is meant you declare a receive buffer with usueful size. You thell the _IT function where to store the received data (the array). That´s all.
Now you can do other tasks while you don´t miss incoming UART data.
After you have finished the other taksy you may read the contents of your UART recieve buffer.

Klaus
 

ElecDesigner

Member level 5
Joined
Jul 22, 2014
Messages
86
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Activity points
2,107
You might be right in some respects; however, my input is from someone typing in a terminal and I need to react to every character.
I did it by interrupt as I thought there would be less chance of missing characters than polling.

I simply want to get around having to refer to inData[0] whilst checking the data. Sorry I'm not the most knowledgeable person when it comes to C. It almost feels like I need to "cast" a one-byte array to a single uint8_t.
 

KlausST

Super Moderator
Staff member
Joined
Apr 17, 2014
Messages
23,036
Helped
4,716
Reputation
9,448
Reaction score
5,091
Trophy points
1,393
Activity points
152,610
Hi,

I need to react to every character.
Then show us what you want to do. A flow diagram, your code ... (written text is not that suitable)

With a 1 byte buffer you have the same chance to miss data than with polling.

Klaus
 

FvM

Super Moderator
Staff member
Joined
Jan 22, 2008
Messages
50,805
Helped
14,603
Reputation
29,481
Reaction score
13,687
Trophy points
1,393
Location
Bochum, Germany
Activity points
290,912
I notice that you don't ask about required buffer size, just how to obtain a single char result. In terms of C-programming, this is a rather elementary question. Instead of a char array variable, you supply the address of your char as actual function argument.
 

vishweshgm

Member level 4
Joined
Dec 17, 2021
Messages
68
Helped
4
Reputation
8
Reaction score
6
Trophy points
8
Activity points
903
Hi,
As @FvM mentioned, you can just pass address of a uint8_t variable as shown below:
Code:
volatile uint8_t inData; /*make sure this is a global volatile variable, as the address of this variable will be used in ISR*/
HAL_UART_Receive_IT(&huart2, &inData, 1);

Also I hope you know how to use these HAL APIs

1. HAL_UART_Receive_IT(&huart2, &inData, 1); <-- Call this funtion only once (can be at init)
2. The above function will start calling default HAL ISR function void HAL_UART_IRQHandler(UART_HandleTypeDef *huart) everytime a byte is received.
3. Since we have configured receive bytes to be '1', after each byte a default callback function --> void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) is called.
4. void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
function is a blank _weak function available for user to code the "reaction" thay want after receive is completed.
 

ElecDesigner

Member level 5
Joined
Jul 22, 2014
Messages
86
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Activity points
2,107
Hi,

That worked ok (I thought I had already tried that to be honest, but most have done something wrongly).

One thing is that if I make this variable "volatile", I get a warning everywhere its used in the ISR (stating that the volatile qualifier is discarded). It appears to work ok without being volatile.
 

vishweshgm

Member level 4
Joined
Dec 17, 2021
Messages
68
Helped
4
Reputation
8
Reaction score
6
Trophy points
8
Activity points
903
volatile qualifier is discarded
I guess this error might be due to the fact that the HAL_UART_Receive_IT function takes pointer to non-volatile variable. The error/warning might get resolved by using cast
HAL_UART_Receive_IT(&huart2, (uint8_t*)&inData, 1);
It appears to work ok without being volatile.
that's good. But personally I would always use volatile as in future developments, if compiler optimization kicks-in, it becomes nightmare to debug the issue.
 

Aussie Susan

Advanced Member level 4
Joined
Jan 5, 2015
Messages
1,473
Helped
402
Reputation
804
Reaction score
440
Trophy points
1,363
Activity points
17,312
I guess the need for the volatile qualifier depends on the usage and whatever compiler optimisations are applied.
Certainly volatile is needed (in theory) whenever a variable is changed in an ISR but read from elsewhere - basically it tells the compiler that the value of the variable can change outside the control of the compiler.
I *guess* that if you only reference the variable inside the ISR (and that might be what the creators of the HAL were thinking would be the common usage) then it is unnecessary.
Alternatively if the ISR sets a flag that is detected in the main loop (or elsewhere) and only then is the variable accessed, it might be OK if the compiler has not tried to cache the variable value in a register and always reads from the variable address.
I would always use 'volatile' and live with the warning (and it is only a warning).
Susan
 

LaTeX Commands Quick-Menu:

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top