UART Buffer

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
CaDu_3933941
Level 4
Level 4
50 replies posted 25 replies posted 10 replies posted

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?

0 Likes
1 Solution
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

View solution in original post

0 Likes
11 Replies
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes

So on the transmitter side, would the function UART_PutArray(), be enough/

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes

Hi,

Could you explain what you mean by translation?

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I meant transmission.

As I've been translating a lot of KBAs, my fingers needed to type translation.

moto

0 Likes

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.

lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

000-tx-log.JPG

Receiver log

Note: the packet marked "with error" in the transmitter is not received here.

001-rx-log.JPG

moto

0 Likes

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?

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes

Also, I noticed you added a delay, would that affect the speed at which speed data is written from the ADC(Joystick)

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes