uart HAL api's

[SANA SRIKAR]

Posted on December 15, 2016 at 13:42

 i am new to stm32f4 HAL api's. I have some trouble learning them. Anything useful for me is really really appreciated. 

i  was looking at the uart api. i was referring to the examples provided in the keilv5  directory. 

there in the uart using interrupt coding (FILE NAME: UART_TwoBoards_ComIT )  

path in your pc's:C:\Keil_v5\ARM\Pack\Keil\STM32F4xx_DFP\2.6.0\Projects\STM32F4-Discovery\Examples\UART

here are my doubts     __IO ITStatus UartReady = RESET; 

    __IO ITStatus UartReady = RESET;   in this what is __IO and what is ITStatus in which header file can i find about it and how to know the different types present in it  ?

2. what is the difference between HAL_UART_Receive_IT and HAL_UART_Receive (other than blocking and unblocking ) 

and in that program  they are sending data and receiving it using UART interrupts but i dont find any IRQHandler in it .

but in the other c file which is linked to it called stm32xx_it.c 

the function is given as like this

void USARTx_IRQHandler(void)

{HAL_UART_IRQHandler(& UartHandle);}

what does HAL_UART_IRQHandler() do ? where is it defined ?

And if they are sending and receiving data using interrupts whyarent 

HAL_UART_Receive_IT() function and HAL_UART_Transmit_IT() arent mentioned inside the IRQ handler?

I would really love to have the entire code explanation if possible (if anyone with some time to spend and more patience) and I really thank for  such kind action  ......

and sorry if my doubts are very stupid.... pls provide me some tutorial links and videos from st site and i forgot to mention i am using stm32f4VG......... and stm32f4 discovery board......

#stm32f4 #uart #hal

[toby2]

Posted on December 22, 2016 at 19:01

Do you mean my simple, circular buffer code? It is by no means a full implementation but for doing simple printf debug TX I use variations on the following code.....

// irq handler

void USART1_IRQHandler(void)

{    if(USART_GetITStatus(USART1, USART_IT_TXE) != RESET)

   {

      if (u1buf.txin != u1buf.txout)

      {

         USART1->TDR = u1buf.txbuf[u1buf.txout];

         u1buf.txout = (u1buf.txout + 1) % u1buf.tx_size;

      }

      else

         USART_ITConfig(USART1, USART_IT_TXE, DISABLE); 

   }}

// anything sending data to the uart uses something like.....

bool u1_putbyte(u8 channel, u8 c)

{    if ((

u1buf

->txin + 1) %

u1buf.tx_size 

==

u1buf

->txout)       return false; // no space in buffer

u1buf

->txbuf[cbuf->txin] = c;

   u1buf

->txin = (

u1buf

->txin + 1) %

u1buf.tx_size

;

   USART_ITConfig(

USART1

, USART_IT_TXE, ENABLE); 

   return true;

}   

Not exactly replacing the functionality of HAL and obviously needs initialisation etc but if you only want something simple..........

(there is a variation in my other thread on this subject)

[SANA SRIKAR]

Posted on December 24, 2016 at 15:33

Mack.Toby

what happens if we put timeout =0 in uart receivesfunction?

[toby2]

Posted on December 24, 2016 at 17:18

You mean using HAL_USART_Receive() rather than

HAL_USART_

Receive_it()?

I've not tried it but I assume HAL_USART_Receive() would then always return HAL_TIMEOUT (with no data) as you would expect.

Mind you, having looked at code for HAL_USART_Receive() again I am confused. It would appear that for every byte it receives on the USART it sends an 0xFF byte on the TX first eg.....

/* Wait until TXE flag is set to send dummy byte in order to generate the clock for the slave to send data */

if(USART_WaitOnFlagUntilTimeout(husart, USART_FLAG_TXE, RESET, tickstart, Timeout) != HAL_OK) { return HAL_TIMEOUT; }

/* Send Dummy Byte in order to generate clock */

husart->Instance->DR = (DUMMY_DATA & (uint16_t)0x00FFU);

To be honest I cannot remember the last time I used a STM32 usart syncronously so it might be necessary for that but if using asyncronously that looks like a great way of messing up the tx data stream.

Surely this cannot be right? Am I missing something?

[SANA SRIKAR]

Posted on December 25, 2016 at 06:15

sir back to the post where you told that i was in a confusion. yeah that is for sure i was in confusion and one more help to solve it. i have been learning those API's whenever i used to have free time but i got stuck here

before telling my doubt ...

disclaimer : Everything i am talking here refers to the code which is present in the Examples folder of the Keil

correct path for the code is:C:\Keil_v5\ARM\Pack\Keil\STM32F4xx_DFP\2.6.0\Projects\STM32F4-Discovery\Examples\UART\UART_TwoBoards_ComIT

SIR my only doubt in this code now is

if(HAL_UART_Transmit_IT(&UartHandle, (uint8_t*)aTxBuffer, TXBUFFERSIZE)!= HAL_OK)\\\{Error_Handler();}/*##-3- Wait for the end of the transfer ###################################*/while (UartReady != SET) { }/* Reset transmission flag */UartReady = RESET;/*##-4- Put UART peripheral in reception process ###########################*/if(HAL_UART_Receive_IT(&UartHandle, (uint8_t *)aRxBuffer, RXBUFFERSIZE) != HAL_OK){Error_Handler();}�?�?�?�?�?�?�?�?�?�?�?�?�?

what is that i dontunderstand is how is UartReady is getting updated everytime.you told me that some function is updating it but what is that function ? and in which file is it getting updated ? i am not being able to see it.

the only thing i know so far is it is getting its value from the UART_HandleTypeDef structure where there is one member called state ::gstate. but where is it happening pls show me the way sir

thanks for the immense help.......................

and i have read the post regarding your circular buffer my question first of all why do we need a circular buffer.? i am a novice in this so pls excuse me if i am asking silly questions

thank you sir

[toby2]

Posted on December 26, 2016 at 12:45

I cannot answer those questions as I do not have the code but I made a guess in my post above. You really need to do as Clive suggested and learn to use the search function, without that you really are not going to learn much. 

Don't worry about circular buffers yet. They are just an easy way of buffering small but unknown packets of data. You can learn about them using a Google search.

[toby2]

Posted on January 03, 2017 at 11:49

If you cannot find what sets UartReady then I suggest you stop looking at anything else until you solve this 'problem'.

Assuming you are looking at the standard STM UART_TwoBoards_comIT code then it is clear, particularly if you read and understand my post on the 16th Dec. 

If you need help searching using Keil then.......

http://lmgtfy.com/?q=keil+IDE+%20search

[Alexey Ostrejkovsky]

Posted on January 03, 2017 at 12:58

Pleas, see video 

https://youtu.be/IdKx4oWNJfw

 

[SANA SRIKAR]

Posted on January 04, 2017 at 01:36

Yes I found it  out. Sorry for troubling you guys with silly thing it is being done at Txcptlcallback and Rxcptlcallback   function in the program in main.c file...............

Now pls answer the above question regarding interrupts . All are given same  priority and sub priority what is the side effect of that?

[toby2]

Posted on January 04, 2017 at 08:02

Have a read of the sections on the exception model and the NVIC in the programming manual for your processor. Also this document gives some useful info on the NVIC:

http://www.eng.auburn.edu/~nelson/courses/elec5260_6260/slides/ARM%20STM32F407%20Interrupts.pdf

The HAL_MspInit() you show is not really doing anything as it is only setting the priorities to their default state. The idea being that you can change the priorities if you think it is necessary by modifying this routine.

You only need to do this if you need certain interrupts to be higher priority than others. For example, if you are using a timer for some critical timing but just using the USART for debug data you might make the timer interrupt higher priority than the USART. That way the timer IRQ will always be serviced even if it already has an active USART interrupt.

Alternatively, if the timer interrupt is writing data to the USART you might need the USART to be higher priority than the timer so it can always clear the buffers.

Unless you have a good reason just leave the interrupt priorities as they are.