• AVR Freaks

Helpful ReplyDRV_USART_BufferRemove and Error management

Page: < 12 Showing page 2 of 2
Author
Totem
Super Member
  • Total Posts : 266
  • Reward points : 0
  • Joined: 2014/12/04 02:18:11
  • Location: Mars
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/08 01:04:21 (permalink)
3 (1)
Try with Rx and Error interrupts with same priority. Just give it a try and see.

Everything is Relative!
#21
Aiden.Morrison
Super Member
  • Total Posts : 729
  • Reward points : 0
  • Joined: 2005/02/25 11:18:31
  • Location: Canada
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/08 03:43:23 (permalink)
0
leftShifted
My apologies but this comment to me feels short-sighted. Consider the case of multiple tasks logging data to a terminal. 

 
At first pass this seems reasonable, but devil's advocate - the multi writer terminal is a very special case of the USARTs usages and not the model that should dictate its driver.  In a micro-controller environment one is just as often talking to single devices in a 1:1 arrangement.  The multi-access belongs in the terminal message handler that would connect to a UART - pushing these concepts to the low level pushes the complexity, bugs and performance penalties there too.
 
#22
NKurzman
A Guy on the Net
  • Total Posts : 19031
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: DRV_USART_BufferRemove and Error management 2017/05/08 06:08:40 (permalink)
0
Aiden.Morrison
leftShiftedMy apologies but this comment to me feels short-sighted. Consider the case of multiple tasks logging data to a terminal. 
 At first pass this seems reasonable, but devil's advocate - the multi writer terminal is a very special case of the USARTs usages and not the model that should dictate its driver.  In a micro-controller environment one is just as often talking to single devices in a 1:1 arrangement.  The multi-access belongs in the terminal message handler that would connect to a UART - pushing these concepts to the low level pushes the complexity, bugs and performance penalties there too. 

Consider the same task on anything else.
N tasks can write data to a ring buffer.
That is its point. The data will come out in the order it was written. The only issue is its size.

The fact that the driver may work better than a ring buffer in a very limited number of Applications says those applications use the hardware with their own special purpose driver, not they becomes the general case.

My apologies to the OP cluttering His active thread.
post edited by NKurzman - 2017/05/08 06:15:30
#23
leftShifted
New Member
  • Total Posts : 22
  • Reward points : 0
  • Joined: 2016/03/16 22:27:00
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/09 03:08:26 (permalink)
0
Aiden.Morrison
 
At first pass this seems reasonable, but devil's advocate - the multi writer terminal is a very special case of the USARTs usages and not the model that should dictate its driver.  In a micro-controller environment one is just as often talking to single devices in a 1:1 arrangement.  The multi-access belongs in the terminal message handler that would connect to a UART - pushing these concepts to the low level pushes the complexity, bugs and performance penalties there too.
 



I agree and if you would have noticed, that the Harmony Console system service handles this responsibility. But what I have quoted here is only an example. What about a multi-drop RS485 bus, say running a DMX-512 protocol. Surely a multi-client driver would be of benefit.

The one question I have is "Isn't the DRV_USART_Read/Write API the same as a ring buffer implementation". I agree the driver does not implement an internal buffer but rather uses the hardware FIFO. Even if it did implement a ring buffer, the DRV_USART_Read/Write API would have still worked.
#24
sige
New Member
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2015/08/25 04:06:32
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/10 00:27:10 (permalink)
0
Hello Totem
 
I have tried and there is any difference.
 
I am working on this and I have seen one point in usart driver which can be improved:
  • In my opinion, function _DRV_USART_BufferQueueRxTasks should do, when it unlinks a buffer:
    bufferObj->currentState = DRV_USART_BUFFER_IS_FREE;
    like DRV_USART_BufferRemove does. Now, a free buffer can "say" wrongly (if it was unlinked by _DRV_USART_BufferQueueRxTasks) that it is a read (DRV_USART_BUFFER_IS_IN_READ_QUEUE) or write (DRV_USART_BUFFER_IS_IN_WRITE_QUEUE) buffer. I'm not sure yet if this can cause an error, but variable  bufferObj->currentState is used by another functions (DRV_USART_BufferRemove) to manage the queue. It seems reasonable that a bad unlinked queue element can cause a corrupted queue.
I'm very frustated.
#25
Johnny0099
Super Member
  • Total Posts : 158
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/12 13:05:48 (permalink)
4 (1)
Hi Totem,
 
I've tryed with the DRV_USART_BufferAddRead with 2x 1 byte buffers concurrently active, with different RX and Error Interrupt levels (RX > Error, RX = Error, RX < Error). I have problems with the buffer queue (iterator = iterator->next) with all of the above interrupt priority combinations. I've also tryed with a high level interrupt (level 5, the highest one in project for both RX and Error) without success.
The problem with 1 byte depth buffers is that each interrupt handles 1 byte only at a time. If one interrupt is missed, the USART FIFO begin accumulating unread bytes. This is the code to read bytes from hardware FIFO in _DRV_USART_BufferQueueRxTasks function:
 

/* The USART driver is configured to generate an interrupt when the FIFO
is not empty. Additionally the queue is not empty. Which means there
is work to done in this routine. Read data from the FIFO until either
the FIFO is empty or until we have read the requested number of bytes.
*/
while((PLIB_USART_ReceiverDataIsAvailable(plibID))
&& (bufferObj->nCurrentBytes < bufferObj->size ))
{
bufferObj->buffer[bufferObj->nCurrentBytes] = PLIB_USART_ReceiverByteReceive(plibID);
bufferObj->nCurrentBytes ++;
}

 
This will cause a buffer overrun sooner or later and/or buffer to become corrupted  (iterator = iterator->next), expecially if DRV_USART_BufferAddRead is used in conjuncion with DRV_USART_BufferRemove function.
This is my experience with the Buffer Queue Transfer Model.
 
This is really frustrating, I fully understand Sige. This driver issue is tricky to debug. I've spent 1 month or more to get rid of it, I've changed my code several time and finally I gave up.
#26
Johnny0099
Super Member
  • Total Posts : 158
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/12 13:15:06 (permalink)
3 (1)
Hi Sige,
 
sorry for replying you so late, I've been busy recently. I've solved this issue by writing my own driver add-on with ring buffer. Now the application and the modified driver works perfectly. I've a version working with Harmony 2.02b and a few days ago I ported it in Harmony 2.03b. It's not complete at all, but usable. Unfortunately I've not used and/or tested with Harmony 1.10.
 
I fully understand your frustration, this is what happened to me and I wasted 1 month or more of my time trying to figure it out. Write me in private if want to try using the driver I've modified.
 
#27
Totem
Super Member
  • Total Posts : 266
  • Reward points : 0
  • Joined: 2014/12/04 02:18:11
  • Location: Mars
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/14 19:44:26 (permalink)
3 (1)
Johnny0099
Hi Totem,
 
I've tryed with the DRV_USART_BufferAddRead with 2x 1 byte buffers concurrently active, with different RX and Error Interrupt levels (RX > Error, RX = Error, RX < Error). I have problems with the buffer queue (iterator = iterator->next) with all of the above interrupt priority combinations. I've also tryed with a high level interrupt (level 5, the highest one in project for both RX and Error) without success.
The problem with 1 byte depth buffers is that each interrupt handles 1 byte only at a time. If one interrupt is missed, the USART FIFO begin accumulating unread bytes. This is the code to read bytes from hardware FIFO in _DRV_USART_BufferQueueRxTasks function:



Is it really a overrun issue? There are applications which will test the USART for it's robustness like Bluetooth apps which uses USART driver at 115200 baud and adding multiple buffers to keep USART ready.
Call DRV_USART_ErrorGet to see the type of error.
 
And let me know more about ring buffer implementation you are using.
The length of ring buffer? Is it just 2 bytes?

Everything is Relative!
#28
Johnny0099
Super Member
  • Total Posts : 158
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/15 02:42:38 (permalink)
0
Hi Totem,
 
I don't think the problem is with multiple buffers in general, but with multiple buffers each one of 1 byte (I'm using 2x 1 byte). I need that callback notify each byte at arrival since I'm parsing unknown lenght strings.
 
I've checked the error in debug mode and it's overrun, I'm sure about this. I'm also getting a framing error at startup, but this is handled properly and doesn't make any issue.
#29
NVergunst
Super Member
  • Total Posts : 390
  • Reward points : 0
  • Joined: 2007/02/11 19:58:16
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/18 20:53:31 (permalink)
0
Johnny0099
Hi Aiden,
 
I simply modified the driver with the option to handle the USART rx with ring buffer instead of single buffer operations without the need to use DRV_USART_BufferAddRead function. This is useful when there is the need to get 1 byte at time from USART. The driver still remains in full Harmony style with this change.
 
<snip> ...
 
I solved my problem in this way. One day or less to write this driver add on, debug and test. Worked at first shot and is "Harmony compliant"! I have also to note that I opened a ticket for this USART driver issue in february (suggestions and help attempt was unuseful, at the hand the ticket guy suggested me to write my own driver) and I have already informed local FAEs about this driver BUG.
 
I will probably pass this code to a local FAE that is in contact with Harmony Dev Team, but don't think that they will do anything with it :-)
 
My next challenge is to get rid of PIC32MZ EF I2C silicon issue.




Any chance you can post the code publicly? Having the same issues.
#30
Johnny0099
Super Member
  • Total Posts : 158
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/20 02:24:49 (permalink)
0

 
Any chance you can post the code publicly? Having the same issues.
 

 
Unfortunately I can't post the code publicly. Contact me in PM if you want to try this code. I have It available only for Harmony 2.02b and 2.03b.
#31
Page: < 12 Showing page 2 of 2
Jump to:
© 2020 APG vNext Commercial Version 4.5