SerialConnection.Flush bug? (continued)

General
1

Continuing the discussion from Serial.Flush bug?:

Yep, took me some time to figure this out as well. And then I forgot since I haven’t used flush for anything anymore and then recently stepped into the same trap again :slight_smile:

But yes, it’s absolute true that SerialConnection.Flush will wipe the receive buffers, which is NOT what the documentation would have you believe.

Here is a little test code to demonstrate this. All you need is to create a new Desktop project with a TextArea and a Serial Connection, and plug in a serial port adapter with a loopback jumper.

#if TargetWindows
  SerialConnection1.Device = SerialDevice.WithName("COM3")
#ElseIf TargetMacOS
  SerialConnection1.Device = SerialDevice.WithName("/dev/cu.usbserial-FTDGUV4P")
#ElseIf TargetLinux
  SerialConnection1.Device = SerialDevice.WithName("/dev/ttyUSB0")
#EndIf

// Install a jumper between the TX and RX pins of the serial port connector

var p as SerialConnection = SerialConnection1
var t as DesktopTextArea = TextArea1

// Open the port
p.Connect

// Write Data
var s as String = "Hello World"
t.AddText("Sending: " + s + EndOfLine)
p.Write(s)
p.XmitWait

// wait for data to arrive
while p.BytesAvailable < s.Length
  p.Poll
wend

// Check the receive buffer
t.AddText("BytesAvailable: " + p.BytesAvailable.ToString + ", " _
+ p.LookAhead.DefineEncoding(Encodings.ASCII) + EndOfLine)

// Flush the port
t.AddText("Flushing the port" + EndOfLine)
p.Flush

// Check the receive buffer
t.AddText("BytesAvailable: " + p.BytesAvailable.ToString + ", " _
+ p.LookAhead.DefineEncoding(Encodings.ASCII) + EndOfLine)

p.Close

Should this perhaps be reported as a bug if the intended behavior of SerialConnection.Flush is to only flush out the transmit buffer and leave the receive buffer alone? Or is wiping both buffer actually the intended behavior and the documentation needs to be updated?

1 Like
2

I would call it a bug. And a nasty one, at that.

1 Like
3

Would you need to poll the receiving socket after the final write?

4

Reported: https://tracker.xojo.com/xojoinc/xojo/-/issues/75917

1 Like
5

I would expect Flush to clear both buffers. You’re wiping the slate. I could be wrong tho.

6

The Xojo documentation states this:
"Immediately sends the contents of internal write buffers to disk or to the output stream.

This function can be useful in point-to-point communication over sockets and similar connections: To optimize for transmission performance, some types of output streams try to collect small pieces of written data into one larger piece for sending instead of sending each piece out individually. By calling Flush, the data collection is stopped and the data is sent without further delay, reducing latency."

This pretty much prevents the serial connection from working in a full-duplex manner. I can’t imagine this being the intended behavior. But I guess we’ll find out once someone at Xojo takes a look at the bug report :slight_smile:

2 Likes
7

Nope. I guess Xojo lacks Clear(). Flush() acts only on the output buffer, and it does not clear it, it dumps its contents to the output emptying it as a result. Flush() makes sense only in cooperative multitasking to pump things out.

To clear buffers, VB.Net has 2 separated methods: DiscardInBuffer() and DiscardOutBuffer()

In Rust Clear() does what you expect too. Discards. Parameters let you choose input, output or both.

I guess Xojo lacks the proper functionality.

Flush() should not touch the input buffer.

3 Likes