I just skimmed your previous discussion.
Increasing the size of buffer will help when processing speed of either side is critical.
But in your case, I'm afraid that the data could be corrupted during the trip from on tx to rx.
In such case you need to provide a mechanism to detect bad error and discard it
as well as noticing the transmitter that good data was received (ACK) or not (NAK).
Just like /oddisey1-san suggested having 1 byte check-sum would be nice
and also having a terminator char makes it easier for the receiver to detect the end of the packet.
So if I were you,
I'd like to have some function, something like int send_packet()
which makes the data packet with checksum and send it
then wait for the response from the rx.
And if its return value is not good, resend the packet (or newer packet) in tx.
On the other hand in rx, I'd like to store the received packet and calculate the check sum
and if check sum was correct, then utilize the data, and return tx that data was received OK (ACK),
otherwise discard the data and send tx that the data was not OK (NAK).
So on the transmitter side, would the function UART_PutArray(), be enough/
> So on the transmitter side, would the function UART_PutArray(), be enough/
Right now, I'm thinking so.
To me, your problem seems that when the translation encounters a problem
you have no way to detect/correct it.
(Assuming that most of the time, the system is working as you expected.)
Could you explain what you mean by translation?
I meant transmission.
As I've been translating a lot of KBAs, my fingers needed to type translation.
I'll see if I can implement some termination characters alongside a checksum. I have very limited experience with UART hence why all the problems.
Attached are my idea sketch(es).
By no means they are perfect nor elegant,
but I hope they can show you some "idea".
Note: the packet marked "with error" in the transmitter is not received here.
Wow, thank you. I will try it out. So does the buffer size on the UART component have to be the same size as the string size?
Also, I noticed you added a delay, would that affect the speed at which speed data is written from the ADC(Joystick)
The CyDelay(100) in the Transmitter was to prevent UART overflow by sending the command to often.
The CyDelay(10) in the Receiver was to emulate the process before returning the ACK.
But I think this delay was not necessary.
Note: I have not implemented the confirmation part of Transmitter to check ACK/NAK,
so currently any returning message from Receiver will be ignored.
As the result, I think that both of CyDelay() are not necessary,
but still any interrupt during the transmission or reception could cause transmission problem(s).
But I hope that the receiver can then treat that data as a bad data and try to wait for the next one.
> Wow, thank you. I will try it out.
Please note that this is only an practical idea, it does not have to be reference nor mandatory.
> So does the buffer size on the UART component have to be the same size as the string size?
In my side, Receiver was working with the buffer size 4 (default)
The transmitter's TX buffer size was set to 10, I think that this is the value you.
You can try changing it to smaller number and try.
IMHO, usually the buffer size matters for the Receiver side,
which does not have control over the transmission.
So if error rate, the ratio of the number of sending packets / number of receiving packets
is getting high, it will the time to consider increasing the buffer size and/or considering
some method to prevent dropping incoming packet.
(In such case, please create a new question topic ;-)