I am sending data from a linux application through serial port to an embedded device.

In the current implementation a byte circular buffer is used in the firmware. (Nothing but an array with a read and write pointer)
As the bytes come in, it is written to the circular bufffer.

Now the PC application appears to be sending the data too fast for the firmware to handle. Bytes are missed resulting in the firmware returning WRONG_INPUT too mant times.

I think baud rate (115200) is not the issue. A more efficient data structure at the firmware side might help. Any suggestions on choice of data structure?

Thanks

No code, not much help. How are reads and writes synchronized?


Missing or being overwritten? Again, no code, not much help.


Really, how can we make any suggestions without at least seeing what it is you're trying to accomplish and whether or not you have "issues" with how you're implementing it?

There could be dozens of reasons as to what is going wrong. Also, you say "firmware," but what does that mean exactly? Is there some target microcontroller or microprocessor running other than the PC test model or whatever it was you called it?

Choice of data structure? You're getting bytes from a serial port, right? How can we possibly know what "data structure" would be a better choice without some notion of the organization of the data and/or expectations of how the data is to be processed or used by consumers in the system?

Are you assembling the data from bytes in to ordered sets of bytes? Are we seeing a mixture of bytes out of sequence?

You say that your current "data structure" is an array with a read and write pointer. Does that mean that there is one pointer that performs two roles at various intervals? Does it mean there are two pointers, one who reads and one who writes?

What method are you using to synchronize reads and writes? How can we tell whether or not your data structure is adequate, but your interactions (algorithms) for processing the data is adequate? How can we tell if your data "structure" is inadequate for the algorithmic interactions you wish to perform using the data?

What do we know of the data? Is it character data as in a text message or something? Is it binary data and you're transfering JPGs around or something?

What do we know about the transmission protocol used to move the data?

Maybe we should blindly guess for several hours until we magically hit upon it?

My first thought when I read your post (other than, this sucks without code) was that a flat array and a pointer (shared role) or dual pointers (split roles) is very unlikely "the" correct structure. An array and a pointer(s) is hardly what I'd call a "data structure." But, it may as well be, so going with it, one can only assume that if you're having problems with it:

Your interactions with the structure are the problem (algorithms)

Your combined implementation of algorithms and data structure are inappropriate for your intended usage.

Also, what does firmware mean in this case? Is it something living at the end of the wire connected to a PC UART? Why not give us some background info on what it is?

Is there some reason for the ambiguity? Why not just spew forth with all of the relevant information so that we can be of help? Oftentimes the mere process of putting together the information into a concise statement of the problem including supporting information allows for an "AH HA!" moment and you don't even need to click Submit Reply.

And, if you don't have the time to put together a decent statement of the problem and at least some relevant example code that shows your method of attacking the problem, then why should we spend any time trying to help you with it?

We're here to help. We want to help you. As many have said in the past, help us help you. Give us at least a fighting chance to make a recommendation by showing us what you've found that DOES NOT WORK...we may be able to fix it. At the very least, the combined talent here should be able to offer some very probable solution paths.


MxB