• AVR Freaks

Helpful ReplyDRV_USART_BufferRemove and Error management

Page: 12 > Showing page 1 of 2
Author
sige
New Member
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2015/08/25 04:06:32
  • Location: 0
  • Status: offline
2017/05/03 07:24:23 (permalink)
0

DRV_USART_BufferRemove and Error management

Hi
 
I'm using PIC32MZ2048EFG100, MPLAB X 3.60, XC32 v1.42 and Harmony 1.09.
 
 
I have a Modbus Driver using Buffer Queue Transfer Model (read buffer of 1 byte). It works properly but sometimes (once a day aprox) the system gets blocked. I have seen the problem is in DRV_USART_BufferAddRead. Sometimes, this "while" becomes in an infinite loop (queue seems corrupted):
 
while(iterator->next != NULL)
{
/* Get the next buffer object */
iterator = iterator->next;
}
 
I use the DRV_USART_TasksError of Harmony 2.02 because 1.09 hadn't implemented.
 
Looking DRV_USART_BufferRemove, I have seen that it disables read or write interrupts (depending if it is a Read Buffer (DRV_USART_TasksReceive) or a Write Buffer (DRV_USART_TasksTransmit), in order to avoid asynchronous updates of the queue.
 
if( DRV_USART_BUFFER_IS_IN_WRITE_QUEUE == bufferObj->currentState)
{
           interruptWasEnabled = _DRV_USART_InterruptSourceDisable(hDriver->txInterruptSource);
}
else if( DRV_USART_BUFFER_IS_IN_READ_QUEUE == bufferObj->currentState)
{
           interruptWasEnabled = _DRV_USART_InterruptSourceDisable(hDriver->rxInterruptSource);
}
 
 
But Error Interrupt (DRV_USART_TasksError) also updates the queue and it isn't disabled. It seems a mistake.
 
Is it correct? Could it cause my problem?
 
Thanks in advance
 
 
 
 
 
#1
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/03 20:37:53 (permalink) ☄ Helpfulby sige 2017/05/04 01:00:02
0
That's a great observation!
Yes, ideally error interrupt also has to be disabled when adding or removing buffers. 
As errors are mostly on receive side, only receive buffer add/remove need to take care of this.  
I'll report this.
 
If you are getting receive overflow error, I would suggest you to use more than one buffer in the queue so that for any new byte received there will be always a buffer ready to read it.
post edited by Totem - 2017/05/03 23:57:11

Everything is Relative!
#2
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/04 00:27:31 (permalink)
0
Thank you Totem
 
I think there is another problem with DRV_USART_BufferRemove. A problem with mutex.
 
When the function checks if buffer is in Use ( "if(!bufferObj->inUse)" ), mutex has already been locked.
 
But if the buffer isn't in Use, function returns without unlocking the mutex. It will never be unlocked and the uart will get blocked
 
Thanks
 
 
#3
am.sh
Senior Member
  • Total Posts : 92
  • Reward points : 0
  • Joined: 2012/08/23 04:33:57
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/04 23:02:16 (permalink)
0
Egis
Thank you Totem
 
I think there is another problem with DRV_USART_BufferRemove. A problem with mutex.
 
When the function checks if buffer is in Use ( "if(!bufferObj->inUse)" ), mutex has already been locked.
 
But if the buffer isn't in Use, function returns without unlocking the mutex. It will never be unlocked and the uart will get blocked
 
Thanks
 
 




 
This is very good observation.
#4
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/05 13:37:23 (permalink)
0
Sige, I have the same problem on USART driver with Harmony 2.02b. My application is crashing once every 2 hour, sometime more often, sometime less. When this happens the queue is corrupted and goes in a infinite loop like you:
 
while(iterator->next != NULL)
{
/* Get the next buffer object */
iterator = iterator->next;
}
 
I have "disabled" the Harmony error handling function, but the problem still remain.
 
Finally, after struggling for more than 15 days to get rid of this problem I decided to modify the USART Harmony driver adding a circular buffer within the Buffer Queue Transfer Model USART driver. It make no sense to read 1 byte at time using DRV_USART_BufferAddRead function. When the buffer event is complete, the receive interrupt is disabled and there is the risk of buffer overflow. I also tried adding more than 1 buffer in the queue as suggested by Totem, something was going better, but the problem was not solved at all.
 
You can see the discussion I started some months ago about this issue:
 
http://www.microchip.com/forums/m971662.aspx?tree=true
 
CF
#5
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/05 14:28:58 (permalink)
4 (1)
Hi Johnny,
 
I'm really sorry to hear that you've invested a whopping 15 days debugging the Harmony USART code.  One would expect that a framework would emphasize getting the simple stuff right, but alas from my limited experience and reading the low level interfaces (e.g. SPI, I2C, UART, Timers, IC, OC/PWM) are things that are much better handled by the user rather than the framework unless absolutely necessary.
 
Do you have the option to replace the buggy harmony code with your own slim implementation?
#6
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/06 00:11:52 (permalink)
5 (1)
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.
 
Here it is some details:
 

/* Open USART Driver to read/write in NON Blocking and exclusive mode */
hDriver->usartDriverOpenHandle =
DRV_USART_Open (hDriver->usartDriverModuleIndex, DRV_IO_INTENT_EXCLUSIVE|DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NONBLOCKING);
 
/* Registers an event handler with driver. This is done once. */
DRV_USART_Open (hDriver->usartDriverModuleIndex, DRV_IO_INTENT_EXCLUSIVE|DRV_IO_INTENT_READWRITE|DRV_IO_INTENT_NONBLOCKING)
DRV_USART_BufferEventHandlerSet(hDriver->usartDriverOpenHandle, USARTBufferEventHandler, (uintptr_t)hDriver);
 
/* Enable receive FIFO, this adds a ring buffer to RX */
DRV_USART_ReceiveFIFOEnable(hDriver->usartDriverOpenHandle, 256, true);

 
The USARTBufferEventHandler has 2 more events now (can be enabled or disabled with the DRV_USART_ReceiveFIFOEnable, last parameter, bool):
 
DRV_USART_FIFO_EVENT_RECEIVE (trigger a single byte received on usart)
DRV_USART_FIFO_EVENT_TRANSMIT (not implemented yet)


With the DRV_USART_FIFO_EVENT_RECEIVE is possible to set a flag and get FIFO buffer content in code loop, or even get the received  bytes in the callback:
 

/* Get received bytes from USART FIFO buffer until empty */
while (DRV_USART_ReceiveFIFOIsGetReady(hClient))
{
      uint8_t byte;

      /* Get next byte form USART FIFO buffer */
      DRV_USART_ReceiveFIFOGet(hDriver->usartDriverOpenHandle, &byte);
 
      /* Proces bytes here */
}

 
Software FIFO ring buffer can be disabled at any time and is fully interoperable with DRV_USART_BufferAddRead function. If software FIFO is enabled buffer operation in queue with DRV_USART_BufferAddRead are suspended until software FIFO is disabled.
 

/* Disable receive FIFO */
DRV_USART_ReceiveFIFODisable(hDriver->usartDriverOpenHandle);

 
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.
#7
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/06 00:29:59 (permalink)
0
The buffer model in the Harmony USART was really intended for transferring large amount of data, say blocks of data. A typical application is A2DP profile data in Bluetooth communication through USART based HCI interface with a bluetooth radio.
 
For transferring a byte of data, you could have considered using the byte mode API or Read/Write mode API.
 
DRV_USART_ByteRead/ByteWrite and DRV_USART_Read/Write.  
 
I am sorry that you had to waste so much time...but I honestly believe that  you are using the Buffer queue functions are an overkill. Did you choose the Buffer Queue function because this is the only demo application available?
 
 
#8
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/06 00:35:32 (permalink)
0
Aiden.Morrison
Hi Johnny,
 
I'm really sorry to hear that you've invested a whopping 15 days debugging the Harmony USART code.  One would expect that a framework would emphasize getting the simple stuff right, but alas from my limited experience and reading the low level interfaces (e.g. SPI, I2C, UART, Timers, IC, OC/PWM) are things that are much better handled by the user rather than the framework unless absolutely necessary.
 
Do you have the option to replace the buggy harmony code with your own slim implementation?




I will have to disagree with this.  The user would in several cases end up writing the same functionality that the driver is implementing. If there are bugs in the code, these should be reported and Microchip Harmony team should fix these. 
#9
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/06 02:00:28 (permalink)
5 (1)
Hi leftShifted, 
 
here a few considerations:
 
1) byte mode (DRV_USART_ByteRead/ByteWrite) and Buffer Queue Transfer Model (DRV_USART_BufferAddRead/BufferAddWrite) cannot coexist in the same project (you can choose one mode only). I need Command, Console and Debug services that are not working in byte mode. Furthermore I have another driver in the same project that uses Buffer Queue Transfer Model.
 
2) More generally. I'm writing a WiFi driver that uses USART that should be Harmony compliant. I will add it to the harmony MCH, so I cannot use byte mode since it's not compatible with Command, Console and Debug services and other Harmony drivers that requires Buffer Queue Transfer Model.
 
3) DRV_USART_Read API in non blocking mode (DRV_IO_INTENT_NONBLOCKING) just read the 8 byte deep hardware FIFO when called. It should be used in a polled mode. Even though it can be used within Buffer Queue Transfer Model, if any buffer operation is active (DRV_USART_BufferAddRead is not used), the USART interrupt is disabled and there is the risk of USART module overrun if hardware FIFO get full faster than DRV_USART_Read polling time. 
 
4) If any USART buffer overrun happens within the Buffer Queue Transfer Model, the DRV_USART_TasksError will not handle this error properly, since in Harmony 2.02b the USART queue management is still not working as it should do. I've experienced iterator = iterator->next looping several time due asynchronous updates of the queue.
 
My attempt in modifying the USART driver is to include a simple interrupt driven ring buffer within the Buffer Queue Transfer Model that is what 95% of Harmony users should require. In this way DRV_USART_BufferAddRead/BufferAddWrite functions and Command, Console and Debug services can be still used preserving each one to write it's own interrupt driven ring buffer driver from scratch. I suggest you to have a look around on this forum to see how many users decided to write it's own USART driver!
#10
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/06 02:31:58 (permalink)
5 (3)

I will have to disagree with this.  The user would in several cases end up writing the same functionality that the driver is implementing. If there are bugs in the code, these should be reported and Microchip Harmony team should fix these. 

 
I've reported this USART driver issue to Microchip FAEs and to Microchip Support trough a Ticket. The last reply to my ticket by a Microchip Support guy was "I suggest you to write your own USART driver". Furthermore, if a large number of users of this forum are writing their own USART driver instead of using Harmony one, there is a problem that goes beyond bugs. Driver performance is another issue that Microchip is never taking into account!
#11
Tez
Moderator
  • Total Posts : 480
  • Reward points : 0
  • Joined: 2006/10/04 11:09:05
  • Location: 0
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/06 23:48:07 (permalink)
0
Johnny0099
 
1) byte mode (DRV_USART_ByteRead/ByteWrite) and Buffer Queue Transfer Model (DRV_USART_BufferAddRead/BufferAddWrite) cannot coexist in the same project (you can choose one mode only). I need Command, Console and Debug services that are not working in byte mode. Furthermore I have another driver in the same project that uses Buffer Queue Transfer Model.
 

 
This is an issue with Command Console and Debug System Services and not with the USART Driver. We will see if these system services can be updated to either use the USART Read/Write Model or the Buffer Queue model.
 
Johnny0099
2) More generally. I'm writing a WiFi driver that uses USART that should be Harmony compliant. I will add it to the harmony MCH, so I cannot use byte mode since it's not compatible with Command, Console and Debug services and other Harmony drivers that requires Buffer Queue Transfer Model.
 

 
I agree. The byte model does is really suited for extremely simple applications. You should look at using the buffer queue model in your driver.
 
Johnny0099
3) DRV_USART_Read API in non blocking mode (DRV_IO_INTENT_NONBLOCKING) just read the 8 byte deep hardware FIFO when called. It should be used in a polled mode. Even though it can be used within Buffer Queue Transfer Model, if any buffer operation is active (DRV_USART_BufferAddRead is not used), the USART interrupt is disabled and there is the risk of USART module overrun if hardware FIFO get full faster than DRV_USART_Read polling time. 
 

 
This is not clear. The USART driver when opened in non blocking mode will cause the  DRV_USART_Read/Write API to be non blocking.  Clearly the onus of servicing the FIFO and preventing over flow lies with the application. You must make sure that you call the read function at regular intervals to prevent overflow. Adding an internal buffer will only defer the overflow.
 
If you do not want to poll, you can then open the driver in blocking mode. This will cause the  DRV_USART_Read/Write API to block till the read and write operations have completed. But the driver must be configured for interrupt mode operation.
 
Johnny0099
4) If any USART buffer overrun happens within the Buffer Queue Transfer Model, the DRV_USART_TasksError will not handle this error properly, since in Harmony 2.02b the USART queue management is still not working as it should do. I've experienced iterator = iterator->next looping several time due asynchronous updates of the queue.
 
Could you please provide instructions on how to reproduce the issue. This will be investigated.

 
Tez
 
 



#12
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/07 04:41:10 (permalink)
4.25 (4)
Johnny0099

I will have to disagree with this.  The user would in several cases end up writing the same functionality that the driver is implementing. If there are bugs in the code, these should be reported and Microchip Harmony team should fix these. 

 
I've reported this USART driver issue to Microchip FAEs and to Microchip Support trough a Ticket. The last reply to my ticket by a Microchip Support guy was "I suggest you to write your own USART driver". Furthermore, if a large number of users of this forum are writing their own USART driver instead of using Harmony one, there is a problem that goes beyond bugs. Driver performance is another issue that Microchip is never taking into account!




 
This seems to be true of most of the low level drivers in Harmony (e.g. Timers, Input Capture, Output Compare, USART, I2C and SPI) in that they have a relatively high level of abstraction with the attendant performance hit and steep learning curve, and are often still in alpha/beta status so are of limited reliability.  
 
Additionally the people working on Harmony apparently have permission to alter the functionality of the drivers between versions to such an extent that it will break existing customer code --> http://www.microchip.com/forums/m915264.aspx#915264  See that thread for a particularly offensive example where they changed an I2C function that was supposed to wait for the transaction to finish to not actually wait!  Since this would mean that any projects relying on that driver functionality would silently break if the framework version were updated it means that Harmony drivers must cannot be trusted for production code, or at the very least you have to lock down your version at the start or be prepared to have functionality silently break.
 
This might not be so bad if technical support was actually proficient at solving problems rather than passing the buck and closing the ticket, but the reality is that you're basically on your own anyway - my advice is to only touch harmony if absolutely necessary for something poorly documented like USB functionality, otherwise it's much faster and easier to just grab the FreeRTOS PIC32MZ example and roll your own drivers.
#13
Mysil
Super Member
  • Total Posts : 3951
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: DRV_USART_BufferRemove and Error management 2017/05/07 08:48:48 (permalink)
4.33 (3)
Hi, Johnny0099
Could you be willing to share the complete implementation of Buffered UART Receive mode updates in the harmony driver?
 
If UART receiver hardware loose synchronization when the transmitter is sending without any pause between bytes, it will be difficult to recover in any case.
Disabling UART receiver to clear and then reenable the receiver, will only have about 1/10 probability of finding the correct transition from Stop to Start bit.  And then there is no way to know if the synchronization is correct, or not, until the next framing error.
UART is self synchronizing, only if there is at least 1 Character  Stop time somewhere in the data stream.
 
UART handshaking, either software XON/XOFF, or hardware RTS/CTS was designed to protect against overflow conditions. Using UART without handshaking, require drivers that do not let hardware overflow, and recover / tolerate / report, software buffer overflow. 
If hardware overflow still happen, there is either too low ISR priority for driver, or there is bug in driver code.
 
So, in my opinion, UART driver should continue processing received characters, whenever buffer transfer model driver is enabled.
This should be done whether there is: an active buffer in receive queue,
circular buffer mode is established with a buffer provided by the driver,
or no buffer is available at all.
In the last case, received characters obviously will have to be discarded, but driver should not let receive hardware get into a overflow condition.
 
The abstract model of Harmony peripheral layer, doesn't make debugging harmony driver code any simpler.
There still beeing issues with UART driver, more than 3 years into Harmony development, may indicate that there is not sufficient attention to testing and maintenance of essential driver infrastructure, or the driver model is too complicated for Harmony software maintenance.
 
Regards,
   Mysil
 
post edited by Mysil - 2017/05/07 08:59:39
#14
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/07 22:00:23 (permalink)
0
Hi sige and Johnny0099,
 
Can you guys share the interrupts(TX, RX and Error) priority configuration in your projects?
If RX and Error interrupts are configured with different priorities, probably that's where the root cause is.
 
Individual vectors for RX and Error switch contexts and breaking the queue.
If you are adding more than 1 buffer and still getting into error context, I suspect parity and framing errors instead of overflow. Even if overflow, I could say there is a ample time spent in USART receive callback function.
 
Let me know the priority settings before digging deep.
 

Everything is Relative!
#15
NKurzman
A Guy on the Net
  • Total Posts : 19033
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: DRV_USART_BufferRemove and Error management 2017/05/07 22:50:58 (permalink)
4.33 (3)
Interesting thread. I usually ignore the uart since it's entire concept is non standard to every uart implementation did since the conception of the UART.
The world uses a ring buffer. Not buffered command blocks. To the Harmony team. What is the PCs you are writing this on use? Hint: ring buffers.
There is a single uart, multiuser is of zero benefit. It makes some sense in the i2c and spi logic, they are tracaction based.
And there is no guarantee in the real world that you will receive every byte you expect, or never get extra. That makes the concept of get N bytes from the UART wish full thinking that will periodicly fail.
#16
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/07 23:11:13 (permalink)
0
NKurzman
 
And there is no guarantee in the real world that you will receive every byte you expect, or never get extra. That makes the concept of get N bytes from the UART wish full thinking that will periodicly fail.



Which is precisely the reason that the Driver contains a DRV_USART_Read and DRV_USART_Write functions. What surprises me is that some of us will refer to a data sheet when using a new microcontroller but when it comes to software, we will rarely refer to the documentation. The Abstraction model section of the USART driver documentation in Harmony help clearly describes the 3 transfer models that the driver supports.  I have the habit of seeking software documentation. While there are drivers in Harmony whose documentation is lacking, the USART driver is certainly one of the better documented drivers.
 
NKurzman
There is a single uart, multiuser is of zero benefit. It makes some sense in the i2c and spi logic, they are tracaction based. 

 
My apologies but this comment to me feels short-sighted. Consider the case of multiple tasks logging data to a terminal. Yes one could implement a logging system service, but a multi-client USART driver would also provide a similar functionality. And then what happens in case of a multi drop RS485 type of setup. 
 
I would expect to discontinue or change a driver completely if its API is as useless as this thread is making it out to be. I used the Harmony USART driver with DMA to service Audio A2DP data over HCI to a Bluetooth Radio. I looked at the documentation and the code example and this worked like a charm. 
 
What I did notice though is that there are no examples for DRV_USART_Read and Write API. The Harmony team should consider adding this.
#17
NKurzman
A Guy on the Net
  • Total Posts : 19033
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: DRV_USART_BufferRemove and Error management 2017/05/07 23:45:47 (permalink)
4 (2)
I gave up looking for anything clearly described in the harmony documentation a long time ago. There is only so many times I can read its thousands of pages in the hope it will be improved. Has it been improved. Is the uart section been fixed? I know the timer bootloader and wifi are not.
Yes some uart communications are transaction based, but not in the driver.
The typical method for transaction implementations is to:
clear the rx buffer.
Send the rx data.
Wait for a minimum number of bytes to appear in the buffer, then start taking them out. Some drivers will allow a peek mode to look at the bytes without removing them.
This is usually done under a timeout.
The driver does not handle this, and should not.
Using a transaction queue just adds overhead.
And again what OS uses this transaction queue model?
What text book?
What other framework?
The dual pointer Circular queue aka ring buffer is the decades old solution to this problem on bigger CPUs. the dual pointers or indexes insure that there is no need to disable interrupts while adding or removing bytes from the buffer. Sometimes the best shape for the the wheel is round.
Just becuse the hardware supports ping pong buffers does not mean that is the best general solution.

And what about non-transactional implementations. Where messages come asynchronously from the response.
And modbus where the timing is important?

Now if the ring buffer used DMA to transmit, or used DMA to transmit blocks that is value added since it request less CPU time. ( my opinion here)
But it will not help on the receive since you can never be sure about missing or extra bytes.
#18
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/08 00:32:37 (permalink)
0
Hi Totem
 
My Rx/Tx interrupt priority is 3
My Error Interrupt prioriy is 1. I was using priority 3 but these days I have done a lot of tests with different configurations.
 
Best regards
 
#19
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/08 00:43:23 (permalink)
0
Thank you for your feedback Johnny0999!
 
I have one question. If I have understood properly, you are not using DRV_USART_BufferAddRead, you are using your own functions which implements a ring buffer.
 
But you still have problems with the buffer queue (iterator = iterator->next). Isn't it? I haven't understood if you have solved the problem in that way.
 
Best regards
#20
Page: 12 > Showing page 1 of 2
Jump to:
© 2020 APG vNext Commercial Version 4.5