USART Receiver pointer to zero

[Dani Prieto]

Posted on July 07, 2017 at 11:19

I have a problem at the reception for 4

I use an 8-position buffer where I keep what we receive for USART. When I receive, if the size of the messageis less than that of the buffer, the following receipt is written below what Ialready had. How can I restart the index for this reception buffer?

/**
* @brief This function handles USART1 global interrupt.
*/
void USART1_IRQHandler(void)
{
 /* USER CODE BEGIN USART1_IRQn 0 */
 
 /* USER CODE END USART1_IRQn 0 */
 HAL_UART_IRQHandler(&huart1);
 /* USER CODE BEGIN USART1_IRQn 1 */
 receive_uart();
 contreceived++;

 /* USER CODE END USART1_IRQn 1 */
}

void receive_uart(void){
 
 if(HAL_UART_Receive_IT(&huart1, (uint8_t *)buffRx, 16) != HAL_OK)
 {
 /* Transfer error in reception process */
 // Error_Handler();
 }
 
 /*****Numero identificacio placa ''NUM_IDXX'' ********************************/
 
 if(buffRx[0]==0x4E){//'N' ''NUM_ID''
 if(buffRx[1]==0x55){//'U' 
 if(buffRx[2]==0x4D){//'M' 

//REST of the code here, too long�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

That's what I receive first, and it's OK.

Here is the second reception,which overwrites the first.

Thank you in advance. Daniel Prieto #buffer #rs485 #usart

[Tesla DeLorean]

Posted on July 07, 2017 at 13:41

HAL_UART_Receive_IT(&huart1, (uint8_t *)&buffRx[n], 16-n)

[Dani Prieto]

Posted on July 07, 2017 at 13:45

Hi Clive, in this code I changed the buffer size to 16

Where I modify the value of n?Thanks

[Tesla DeLorean]

Posted on July 07, 2017 at 14:07

Your question implied you needed to restart deeper into the buffer. You need to figure that restart point, as index n.

Your images are not viewable by anyone but you, they point to private gmail views. Just attach images via the camera icon.

If the buffer contains multiple messages your parsing code is going to have to be smarter, so it indexes through the array, or it copies down the tail into the front of the buffer.

[Tesla DeLorean]

Posted on July 10, 2017 at 19:01

Not sure it's overwriting as much as starting at a different part of the stream, your parsing code will need to be smarter and resynchronize with the start of the data you are looking for.

To see if it overwrites, or is new data, fill the buffer with a known pattern before each start, ie something like 0xCD

[Dani Prieto]

Posted on July 11, 2017 at 11:31

I added a ''resetbuffer'' in the callback, but the only thing I get is to clear the buffer after it has been filled. So what has not fit before, starts to fill the buffer again.

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
resetbuffers();
}
void resetbuffers(){
uint8_t i;
for(i=0;i<APP_RX_DATA_SIZE;i++){
buffRx[i]=0;
}
huart1.RxXferCount= APP_RX_DATA_SIZE;
//UserTxBufPtrIn = 0;
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?

First I'm sending READLECTU, and later SETOUTOFF

What I need is to put the 2nd command in position 0, so that my command will always start in the same place and I will never fill the buffer.

[Lucas C]

Posted on July 17, 2017 at 18:10

Hi Dani,

I'm having the same 'issue'. I want to always write to the first address of the input buffer, but even if I call the HAL_UART_Receive_IT function again, I can't get it to reset the pointer. What I have done as a temporary solution was to restart the UART module (by calling HAL_UART_Init) with the same handler you've created before. I don't think this is the right way to do it, but I haven't figured out yet how to reset the pointer to the start of the buffer.

If you have found a better way to do so, let me know.

Cheers!

[Tesla DeLorean]

Posted on July 17, 2017 at 22:05

Resetting the USART is almost inevitably going to result in data loss at some point.

You need to think about this more flexibly, you can move the data to other buffers, you can work through the buffer, and you can modulate the size and position of the next transfer.

[Lucas C]

Posted on July 18, 2017 at 15:50

Hi

Turvey.Clive.002

,

Thanks for your feedback!

I couldn't agree more about losing data. If the application is very sensitive about not dropping packets and does not have any kind of ack, then you should never have a time slot restarting your module. For my application, I have only small chunks of data sporadically, and as long as I can request the data to be re-sent, in the case of a mismatch, there are no issues.

As for using another buffer to store the data, that would be possible. However, the reason why I don't want to do that is that I would introduce another chunk of code that has to track where things start and end and make sure that would work under various faulty conditions, and that will just add complexity and chance for introducing more bugs. So, as it is possible for me to restart the module (when there is a underrun) and ask for the same data again, I prefer to do it this way to make sure that it's all always synced.