• AVR Freaks

EUSART generated code does not limit the value of the input buffer available bytes

Author
obones
New Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2006/03/06 08:15:09
  • Location: 0
  • Status: offline
2019/10/11 10:19:24 (permalink)
0

EUSART generated code does not limit the value of the input buffer available bytes

When using MCC to generate EUSART code, we can ask for input and ouptut buffering.
The code for the input buffering is inside EUSART1_RxDataHandler and looks like this:
 
void EUSART1_RxDataHandler(void){
    // use this default receive interrupt handler code
    eusart1RxBuffer[eusart1RxHead++] = RC1REG;
    if(sizeof(eusart1RxBuffer) <= eusart1RxHead)
    {
        eusart1RxHead = 0;
    }
    
    eusart1RxCount++;
}

 
This means that no matter what happens with the buffer, the count is always incremented. So, if this code runs for a large amount of time, eusart1RxCount can be very large.
When some code then tries to read values from the buffer with EUSART1_Read, the buffer content is duplicated until eusart1RxCount has returned back to zero.
I thus think that eusart1RxCount should only be incremented if it's not already equal to the buffer size. In the code here, I have added this:
 
    if (eusart1RxCount < EUSART1_RX_BUFFER_SIZE)

 
What do you think? Does this look correct to you?
#1
du00000001
Just Some Member
  • Total Posts : 4016
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: EUSART generated code does not limit the value of the input buffer available bytes 2019/10/11 13:43:04 (permalink)
0
Not sure whether eusart1RxCount might get decremented when reading from the RX buffer...
Basically, you (MCC) are free to choose whether to overwrite the ring buffer as well as how counting received characters. And you are free to modify the code MCC generated.
Consider MCC as a means "for starters".

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#2
obones
New Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2006/03/06 08:15:09
  • Location: 0
  • Status: offline
Re: EUSART generated code does not limit the value of the input buffer available bytes 2019/10/11 14:43:49 (permalink)
0
Yes, eusart1RxCount is decremented when reading via the EUSART1_Read call.
I understand that MCC generates "sample" code that serves as a starting point, but I thought it would be nice if it was behaving in a more logical way.
#3
ric
Super Member
  • Total Posts : 28968
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: EUSART generated code does not limit the value of the input buffer available bytes 2019/10/11 14:47:13 (permalink)
0
Fair enough comment, but you'll die of old age waiting for all of MCC to behave in a completely logical way ;)
 
This of it as "something that works", not "an example of best programming practice".
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#4
Mysil
Super Member
  • Total Posts : 3951
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: EUSART generated code does not limit the value of the input buffer available bytes 2019/10/11 15:32:17 (permalink)
0
Hi,
MCC EUSART code to read from the circular buffer will decrement the counter when reading from the input buffer.
But anyway, such code that change the same variable both in Interrupt and in Main loop code,
is vulnerable to obscure synchronization problems.
8 bit PIC microcontrollers are able to increment or decrement a 8 bit variable in a single atomic instruction,
so the test suggested in message #1 seem sensible to me.
 
Another possibility, is to avoid the counter variable entirely, using the 2 separate index variables:
eusart1RxHead   and   eusart1RxTail, 
also when testing if buffer contain data.
One of these variables are only updated by interrupt code, the other only by code in API routines.
There are some boundary cases, so one byte in the buffer array may have to remain unused,
while a separate counter variable may not be needed.
 
In the code generated by MCC, there is the following construct in the eusartRead() function:
    PIE1bits.RCIE = 0;
    eusartRxCount--;
    PIE1bits.RCIE = 1;  

disabling EUSART interrupt while manipulating the counter.
In view that 8 bit PIC have instruction to decrement a 8 bit variable in a atomic instruction?
 
Also the code generated have a status  array using the same number of bytes as the circular buffer.
The Status type have bits to indicate, parity error, framing error or hardware overrun error,
but nothing to record or notify that software buffer overflow have occurred.
 
    Mysil
 
 
 
 
#5
obones
New Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2006/03/06 08:15:09
  • Location: 0
  • Status: offline
Re: EUSART generated code does not limit the value of the input buffer available bytes 2019/10/24 07:43:56 (permalink)
0
ricThis of it as "something that works", not "an example of best programming practice".

But when it comes down to something as complex as the "TCP Lite" library, it's really hard to figure out if anything is wrong amid the dozens of warnings that get emitted from that code.
After a few days experimenting, I had to make sure the connection is closed every now and then or the code would enter a deadlock state where TCP_SendDone never returns unless the connection is closed.
 
It's a bit sad that there is no Bug tracker available, like I'm used to have with other software vendors.
#6
Jump to:
© 2020 APG vNext Commercial Version 4.5