I just posted Specify UART buffer size on Task Tracker. Feel free to discuss and make suggestions here.
@ iamin - What would this information help you with?
Well, if you write a program that uses UART you want to know if all boards have the same size buffer and how large it is. Without this information you don’t know when will you run out of space and data will be overwritten (I assume it is circular buffer).
And I would also like to know what is the CDC buffer size 
@ John - Is it a secret? Why don’t you tell us?
I need this peace of information to continue writing my driver.
@ iamin - You need a security clearance, we are in the process of completing your background check. :whistle:
@ Gary - And who is doing my background check? I should consider bribing him/her. Ups… did I said it out loud? :wall:
@ iamin - lol, your secret is safe with us.
I think this info has no direct benefit and can cause confusion if one day we changed the size. Also, there is no “buffer” as the drivers have multiple levels and each had ours own buffer. Even the hardware may have a buffer, like the 16 bytes on G120. This gets even more interesting as the buffers for send and receive are not the same.
Adding to what I said earlier, your program should read and empty the serial date into your own buffer and then prices the data. This way your program will run on any NETMF board similarly. This is how I would do it anyway.
1 Like
@ Gus - It gets much more complicated when you do more than just reading and writing to SerialPort. When you have many threads running that are CPU intensive, when you need to validate and process data that you have received, when you are using RLP - those are the cases when I need to know exactly what is going on. I don’t want to spend days/week/months trying to figure out all the “what if” scenarios.
I am not sure I understand you when you say that there is no buffer. Let’s check two SerialPort related scenarios:
- I send 10 bytes of data to Cobra II, but I don’t read it for an hour. I will be able to read this data later on, it will be still there. So, I call it a buffer that is at least 10 bytes of size.
- I send 10 megabytes of data to Cobra II, but I don’t read it (hypothetical scenario). Will I be able to read those 10 megabytes if I decide to? No. I will be able to read let’s say the last 4kB of data (if buffer size is 4kB).
Let’s take a real world example. I choose to use 256000 baud rate. So I could receive 32 bytes every millisecond. If RLP is doing something for 2 milliseconds and SerialPort buffer is only 32 bytes I will lose 32 bytes of data.
Let’s take another example. I have 5 CPU intensive threads running simultaneously and one thread that is responsible for reading/monitoring SerialPort. In this case I will be able to read data every 100 ms (5 threads x 20 ms allocated to each). I need to know how much data can be stored in SerialPort buffer before it gets overwritten. I could use DataReceived event, but that way I would block those 5 threads in a case when I receive a lot of data for an extensive period of time.
I am pretty sure there are more cases where you need to know exactly what is going on and not relay on hopes/predictions.
I really think that by not telling this info to use you will not help us in any way, you will rather introduce more uncertainty. As we all know, security by obscurity does not work well.
1 Like
I have been doing serial communications programming for many years , including writing serial interrupt handlers, and I have never needed to know the size of the internal buffers when doing application programming.
I vote no on this request.
[quote=“Mike”]I have been doing serial communications programming for many years
[/quote]
It does not mean you was doing it the right way. It is also very possible that your requirements were quite different compared to mine.
It does not mean you was doing it the right way. It is also very possible that your requirements were quite different compared to mine.
[/quote]
You are absolutely correct. It is possible that I have been doing it wrong for many years. The good news is that the commercial products with my code are no longer being used.
1 Like
Well, GHI has refused to tell me, so I had to find it out myself. G120 and G400 as of today offers 16KB buffer for incoming serial data. As nobody has shown any interest in this topic, I will keep my other findings to myself.
1 Like
15 replies and you call that no interest :naughty: either way you should always share your findings with this community no matter what 
1 Like
@ Jay Jay - Well, those replies consist of: (a) me trying to convince that this info is necessary, (b) questions from staff asking why do I need that, (c) one vote to hide/not share this info.
Correct me if I am wrong, but interest from community is expressed in amount of likes and votes. I see zero +1 on the first post in this thread and I see zero votes on the Task Tracker. For me, that’s a clear indication of “I couldn’t care less”.
It takes time to do testing and to write proper conclusions. If nobody is interested, I would rather spent my time doing something else 
I wasn’t talking only about todays community members I was talking about those who might join in the future and find that info to be of interest 
I’ve been following this thread with interest. The idea of doing something with this info is new to me and I’d love to learn more about what you’ve found and how you would implement this information if you had it. Sorry, no +1s from me in the beginning because I simply didn’t know enough to know if there was really a benefit to having the information.
I am following this with great interest and have had too many problems with serial communication to not be interested in your findings.
When people don’t understand your needs it’s natural to start a dialogue.