So, I have been working on this project to read files on the SD card and then Output via COM2. I can output a 28KB picture just fine with all bytes there. However, I need to transfer a ~814K File. When doing so the data will stream in fine up and then slow down and start to chunk in about 10 bytes at a time. When it starts slowing down is kind of random but I would say average around 270K Bytes.
I have tried using the RST line to prevent overflow and such, but I am thinking it could be a memory issue?
Just curious to see if anyone has experienced the same problem and what they did to fix it.
I’d say it’s unlikely to be directly UART related but in how you’re handling/buffering the data. It’s certainly time to show code - as Mike says, make it small and to the point.
I was a little vague sorry about that. I am using a 9600 Baud Rate and I am using a XBee chip through the COM2 port and then receiving it through a Digi XStick. I have my terminal set to control the flow through Hardware. Though I used a logic analyzer and didn’t see the RST pin ever being tripped.
Also, I did not see any garbage collection message in the debug output window. Is there something I need to put in the code so it will display this?
Here is a sample of the code below.
Thanks!
if (VolumeInfo.GetVolumes()[0].IsFormatted)
{
FileStream fHandle;
int bytesRead;
long totalBytesRead;
long totalBytesWrite;
string rootDirectory =
VolumeInfo.GetVolumes()[0].RootDirectory;
string outstr = "Files in " + rootDirectory + "\r\n";
string[] files = Directory.GetFiles(rootDirectory);
Debug.Print(outstr);
// Each available file will be printed after this within the 'for' loop
Debug.Print("Files available on " + rootDirectory + ":");
// Open the SerialPort
UART.Open();
// Begin XML Output
outstr = "<polaris><images>";
UART.Write(UTF8Encoding.UTF8.GetBytes(outstr), 0, outstr.Length);
for (int i = 0; i < files.Length; i++)
{
totalBytesRead = 0;
totalBytesWrite = 0;
Debug.Print(files[i]);
outstr = "<image filename=\"" + files[i] + "\"><!CDATA[";
UART.Write(UTF8Encoding.UTF8.GetBytes(outstr), 0, outstr.Length);
// This is where we copy the image contents
// Create a file stream object
fHandle = new FileStream(files[i], FileMode.Open, FileAccess.Read);
Debug.Print(files[i] + " length: " + fHandle.Length);
bytesRead = 0;
while ((bytesRead = fHandle.Read(fData, 0, fData.Length)) > 0)
{
Thread.Sleep(50);
totalBytesRead += bytesRead;
UART.Write(fData, 0, bytesRead);
totalBytesWrite += fData.Length;
// Give it a bit to send
Thread.Sleep(50);
}
UART.Flush();
// We're done.
fHandle.Close();
outstr = "]></image>";
UART.Write(UTF8Encoding.UTF8.GetBytes(outstr), 0, outstr.Length);
Debug.Print("Total Bytes read from file: " + totalBytesRead);
Debug.Print("Total Bytes written to UART: " + totalBytesWrite);
// Free processor for a bit before continuing with additional files
Thread.Sleep(100);
}
// Send end of XML file
outstr = "</images></polaris>";
UART.Write(UTF8Encoding.UTF8.GetBytes(outstr), 0, outstr.Length);
UART.Close();
}
}
The thing is though the data streams in very fast as you would expect and then just starts lagging and taking in about 100 bytes every second, then pausing a second, then taking on another 100 bytes.
So that proves that the delay cant be the culprit… I think.
Edit: Do you think it could be the terminal’s fault?
RTS/CTS are unlikely to be a part of this equation since you’re unlikely to get interaction with them over that many different methods (the XBees in the middle) even if each of them passed that along.
Honestly, thread.sleep is not necessary. You do a uart flush - why? Just pump data in and forget it, don’t try to hang around until it should be send, just rely on it sending it when it can. SerialPort.Flush Method | Microsoft Learn just shows this forces the send process then clears down the buffer - which in theory will just simply hang around exactly until the end of the data is sent, so worst case you don’t even need to hang around at all, just write to the port and flush away. But the serial port sends when it can, so I’d still say don’t bother with flush.
And if you really want speed, 9600 is woefully slow
There is often some other buffering at play - for instance some SUB to UART devices will buffer something like 16 to 64 bytes before putitng them into the PC. Don’t know if the xbee device you have has that
Ok, so I grabbed a video of what is exactly happening, because I feel it is hard to explain. In the terminal program it shows how many bytes it has recieved so far, and right at 275, you will see this slow down I am having a problem with.
Ok I completely started a new program and added everything in. Now, I am getting a steady flow of data, but on the terminal side of things I am only seeing 345K Bytes out of the 850K it should be.
