This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

UART Maximum FIFO Size

Hi all,

I have to transfer a lot of data over the UART channel, and run into some problems...

First problem was/is the UART FIFO Size. There are three different defines on the SDK for the RX/TX buffers:

#define 	TX_BUF_SIZE   600u
#define 	RX_BUF_SIZE   TX_BUF_SIZE
#define 	RX_BUF_QUEUE_SIZE   4u
#define 	TX_BUF_SIZE   4u
#define 	RX_BUF_SIZE   32u
#define 	RX_BUF_QUEUE_SIZE   8u
#define 	TX_BUF_SIZE   32u 
#define 	RX_BUF_SIZE   600u
#define 	RX_BUF_QUEUE_SIZE   2u

My block is 512bytes long in data plus 3bytes of header and 1byte of checksum. My first attemp was to use 520bytes of buffer, which resulted in unpredictable behaviour from the NRF51822. Further reading on the documentation, I then realised that the size has to be a power of 2... So how can one expect a reliable behaviour of using 600 bytes (from the builtin defines of the SDK's). If my math is not that bad, there is no power of 2 that gives 600... Unless the exponent part can be decimal (???)...

I now run my fifo with a 1024byte size (from which I'll be only using the 516 bytes above), and it seems to be working... At least my data seems to be travelling ok to the end-point. What is the maximum value of the fifo size one can use? Can I expect reliability from my device while using this 1024 fifo? Again I will be transferring 516 bytes (I have implemented software hand-shake to get more data only once the previous packet as been successfully sent).

Using sizes different from a power of 2 resulted in different behaviour depending on the size of the buffer and the board (tested it across several boards).

From what I can see, there are a lot of UART related problems throughout the forum, when the fifo size starts growing, which I recon can be related to this problem.

Last I can provide some other info about my setup (which I think don't really interfere with this behaviour): SDK 8.1.1 SD130 v1.0.0 NRF51822XXAC REV3

Thanks in advance, Diogo

Parents
  • Yes I was using a direct connection to my Mac and was getting the errors on my computer... Not only between uC and peripheral... I am using Nordics Scheduler slightly modified to accommodate priority on the events. I recon the stack settings are not the cause of the problem, since the only thing changing was the buffer size, and while 512 worked(I truncated my packet)... 516 517 520 and 600 would not work... Once I have come up to 1024 it works... In the documentation of the SDK and even on the app_uart.h (which should be the source of the documentation), it is expressly written to use a power of two as a buffer size... Also on the fifo library there is the same information... So I guess that information is valid, right? Has the 600 byte configuration been tested on intensive data communication (with big chunks of data)? Again, for small portions I recon every size will work...

Reply
  • Yes I was using a direct connection to my Mac and was getting the errors on my computer... Not only between uC and peripheral... I am using Nordics Scheduler slightly modified to accommodate priority on the events. I recon the stack settings are not the cause of the problem, since the only thing changing was the buffer size, and while 512 worked(I truncated my packet)... 516 517 520 and 600 would not work... Once I have come up to 1024 it works... In the documentation of the SDK and even on the app_uart.h (which should be the source of the documentation), it is expressly written to use a power of two as a buffer size... Also on the fifo library there is the same information... So I guess that information is valid, right? Has the 600 byte configuration been tested on intensive data communication (with big chunks of data)? Again, for small portions I recon every size will work...

Children
No Data
Related