Issue with sending TXT file through serial communication (UART)

[crossrulz]

---

@gkim83 wrote

What would make it happen that the character, "q" was not sent to embedded device...?

---

Or the embedded device could not receive it.  My thought here is a buffer overflow on one or both sides of the communication bus.

[gkim83]

crossrulz,

Could you explain more about how the buffer on each side works? I am assuming the embedded software has a buffer and the LabView program has a buffer... 

I thought it could be a buffer overflow issue too, so I increased the buffer size in LabView by 1 MB.. but it could not solve the issue. 

When I send the application code (TXT file) through the Tera Term, it works perfectly fine. Does that mean there is no problem with the buffer in the embedded software?

[BertMcMahan]

It's likely the receive buffer on the device. What are you using to receive the buffer? Lots of serial devices don't use an Rx buffer by default.

The transmission rate is limited by whatever your baud rate is. Data will come out of the computer at that rate. The transmit buffer is the buffer on LabVIEW that stores that data. If you write 1000 characters to the serial port, those 1000 characters are stored in the Transmit buffer, and are sent out one at a time. The computer will sit there sending characters out until it's out of characters. The receiving device must accept those characters as they come in. Typically, it either handles them on the fly or it has its own buffer, where it stashes the character into memory but doesn't actually "do" anything with it just yet. Later, your embedded device will go through that buffer at its own speed.

If that internal receive buffer fills up, it'll stop accepting new characters, and LabVIEW has no way of knowing this. It'll send out the "q" character but the device may not have enough memory in its receive buffer to do anything about it.

By any chance does TeraTerm have some delays in it? It may do some kind of batch writing instead of plopping the whole thing in the buffer at once.

Another item- in your IO Trace session, does it log an error when you set the Tx buffer?

[Mark_Yedinak]

---

@gkim83 wrote:

crossrulz,

Could you explain more about how the buffer on each side works? I am assuming the embedded software has a buffer and the LabView program has a buffer... 

I thought it could be a buffer overflow issue too, so I increased the buffer size in LabView by 1 MB.. but it could not solve the issue. 

When I send the application code (TXT file) through the Tera Term, it works perfectly fine. Does that mean there is no problem with the buffer in the embedded software?

---

No, because it works with Teraterm does not mean that there is not a problem with the embedded device. Increasing the buffer on the PC (LabVIEW) side does nothing to address any possible buffering issues on the embedded side. From what you have posted I would say the problem most likely is on the embedded side. What may solve the issue is slowing up hw you send the data. Teraterm is most likely sending the data slower than your application which is why it works. The embedded side has some receive buffer size and if data is sent too quickly it can overrun this buffer and data will get dropped. What you may need to do is send your data in smaller chunks with a very small delay between them. This will give the embedded device a chance to receive and process the data clearing the receive buffer.

I looked at your code and noticed that flow control is turned off. Is it possible to enable flow control for your device? That may help. If not, I suggest you put a small delay, larger than 5 ms, between each line of text that you send to allow the embedded device time to receive and process the data.

[RavensFan]

---

@Mark_Yedinak wrote:

---

That may help. If not, I suggest you put a small delay, larger than 5 ms, between each line of text that you send to allow the embedded device time to receive and process the data.

---

And that is exactly what I told him to do back in message 5!

That conversation with the embedded software programmer should have provided more information than him telling you that there is nothing wrong with what he did.  He should have better knowledge of his software to know if there are any buffer limitations on this side or timing delays in how his software receives the data.