- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I made a recent post on receiving data from a transmitting PSOC. For some reason it got blocked, either way,here is the link to it should you need background info
https://community.cypress.com/message/237342?et=watches.email.outcome#237342
I wanted to continue this discussion asking, should I increase the buffer size on both UARTs for transmitting and receiving?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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).
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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).
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So on the transmitter side, would the function UART_PutArray(), be enough/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
> 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.)
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Could you explain what you mean by translation?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I meant transmission.
As I've been translating a lot of KBAs, my fingers needed to type translation.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Got it,
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Attached are my idea sketch(es).
By no means they are perfect nor elegant,
but I hope they can show you some "idea".
Transmitter log
Receiver log
Note: the packet marked "with error" in the transmitter is not received here.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
> 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 😉
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, I noticed you added a delay, would that affect the speed at which speed data is written from the ADC(Joystick)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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.
moto