Do I have to add the delay function for receiving the USART data for safely?

[Carter Lee]

Posted on September 18, 2017 at 16:39

Hi.

Now I'm struggling with receiving data by USART.

Currently, I have one USART receive interrupt. and once if there is interrupted by RX, then the data saved into the queue.

I guess but I'm not sure, but while() is too fast. So I can't get the data what I want.

for example, If PC's USART terminal  send data with 0x11 0x22 0x33 0x44.. to eval kit. then procedure with delay()  in while() is working as well.

But If I remove that delay() then, I can't get data of all (0x11~0x44).

Do I have to add the delay function for receiving the USART data for safely?

What is the fairly common way to process UART frame packet?  

One more thing.

USART3_IRQHandler just one activated never after.

void USART3_IRQHandler(void) //RX

{ if(USART_GetITStatus(USART3, USART_IT_RXNE) != RESET) { char rx = USART_ReceiveData(USART3); /*GetCharUSART1();*/ Uart3_EnQueue(rx); USART_ClearITPendingBit(USART3, USART_IT_RXNE); }}

Did I someting miss?

[nibbly78]

Posted on September 18, 2017 at 16:45

post up your while loop

generally, ring buffer would be the way to go > 

http://www.embedded.com/electronics-blogs/embedded-round-table/4419407/The-ring-buffer

 

[Tesla DeLorean]

Posted on September 18, 2017 at 16:51

>>Do I have to add the delay function for receiving the USART data for safely?

NO

>>What is the fairly common way to process UART frame packet?  

One byte at a time?

USART_ClearITPendingBit(USART3, USART_IT_RXNE); // this is unnecessary, reading the DR clears the status

Also you shouldn't clear the interrupt as the last thing prior to exit, there is a race hazard that will cause spurious re-entry.

[Carter Lee]

Posted on September 18, 2017 at 16:50

I've update the main file.

[Carter Lee]

Posted on September 18, 2017 at 16:58

Could you please let me know what am I supposed to do with the attached code to prevent hazard race problem?

[Tesla DeLorean]

Posted on September 18, 2017 at 17:10

I don't have the time/resources to work on your project.

You should perhaps review the use of volatile variables, and the size of data sscanf() writes into variables.

If it is too overwhelming, then reduce the complexity, but you shouldn't need to insert delays for things to work properly.

[Carter Lee]

Posted on September 18, 2017 at 17:24

Thanks but I just want to know what do you exactly point the code in 'Also you shouldn't clear the interrupt as the last thing prior to exit, there is a race hazard that will cause spurious re-entry.'?

I think this is the main problem.

I'm not saying to ask you for fixing my code,  how to prevent race hazard problem? And how to know there interrupt does not clear?

[Tesla DeLorean]

Posted on September 18, 2017 at 19:09

This stuff takes time to review, you are given hints so you can review things yourself, and research, that way you can be self-sustaining rather than dependent.

void USART3_IRQHandler(void) //RX

{ if(USART_GetITStatus(USART3, USART_IT_RXNE) != RESET) { char rx = USART_ReceiveData(USART3); Uart3_EnQueue(rx); }}

Use volatile variable for things you change in interrupt context and review in foreground context.

[Carter Lee]

Posted on September 19, 2017 at 03:15

Currently I send  9Bytes(0x53 0x03 0x01 0x00 0x02 0x05 0x00 0x05 0x45) to the KIT within the baud rate = 115200.

I always received 0x53 in buffer without delay(), but If I use with delay then I can see all 9Bytes are included in the Buffer. Might be the main() is faster than what I thought.

[LMI2]

Posted on September 19, 2017 at 14:26

If you are doing everything correctly, you don't need or want delays in receiving. Use some insecticide, or Google STM32F Uart receiving or something like that.