I’ve tried this on Mac OS 15.0.1 and Windows 11. I used code in the demo linked below in the past to talk to Arduinos as controllers. The issue is I can now run through this in about 4 minutes. At design time it works as long as I’m in the same design session. Once saved and closed, reloading it will not give any serail data. I can remove all of the entries and redesign it and again it will work until the session is closed. Rinse,Repeat. I can’t be the only person to see this?
I don’t quite understand your description of the issue but it sounds like it sometimes works and then it doesn’t?
I’m not sure about that but I do see one issue. In DataReceived you have:
Var data As String
data = Me.ReadAll(Encodings.ASCII)
If data.IndexOf(EndOfLine.Windows) >0 Then
TextArea1.Text = TextArea1.Text + Me.ReadAll(Encodings.ASCII)
End If
The first ‘ReadAll’ is getting all of the available serial data and clearing the buffer. The second ‘ReadAll’ is then getting nothing.
If you look at DataReceived in the Bar Code example:
Var data As String
data = Me.LookAhead(Encodings.ASCII)
If data.IndexOf(EndOfLine.Windows) > -1 Then
TextArea1.Text = TextArea1.Text + Me.ReadAll(Encodings.ASCII)
End If
It is using ‘LookAhead’ which reads the serial data but doesn’t clear the buffer, it will keep doing this as data is received and then when the check below sees a linefeed in the data, the ‘ReadAll’ will proceed to grab all of the data from the buffer.
Yep. The DataReceived code form the Bar Code example should work better. As Indy G pointed out LookAhead should be used to check if an EndOfLine has been received so that the received data remains in the receive buffer until it contains an EndOfLine.
Once an EndOfLine is in the receive buffer, I would also recommend only reading the received data up to (and including) the EndOfLine and leaving anything after the EndOfLine in the buffer until the next time DataReceived fires and you’re checking for a new EndOfLine.
Here’s an updated version of the code from that blog:
var PacketSize as integer
var Terminator as string = EndOfLine.Windows // this is the data terminator
// check the buffer for at least one full packet. IndexOfBytes is zero relative,
// so it effectively returns the packet size
PacketSize = me.LookAhead(Encodings.ASCII).IndexOfBytes(0, Terminator)
// wait for at least one full packet
if PacketSize < 0 then
return
end
do
// read the data packet without the terminator
var DataPacket as string = me.Read(PacketSize, Encodings.ASCII)
// remove the terminator from the buffer
call me.Read(Terminator.Bytes, Encodings.ASCII)
// >>>>>>>>>> deal with the data here (DataPacket)
// recheck the buffer for a full packet
PacketSize = me.LookAhead(Encodings.ASCII).IndexOfBytes(0, Terminator)
loop until PacketSize < 0
Are you using a different microcontroller board this time around? Some (such as ESP32, etc) may use the DTR or RTS lines to reset the controller and/or invoke programming mode. I.e. a deasserted DTR signal may hold the controller in reset when the port opens.
Glad to hear it!
CoolTerm lets you toggle the DTR and RTS signals manually. You can use that to see if toggling any of these signals reset your microcontroller.
The DTR slider in IDE actually corresponds to SerialConnection1.DTR, not SerialConnection1.DataTerminalReady. The DTR propertry enables or disables DTR/DSR control flow. It has no bearing on the state of the DTR line when the port opens. It is SerialConnection1.DataTerminalReady that sets the state of the DTR line.
The Arduino UNO includes circuitry that resets the microcontroller when DTR toggles from high to low. I believe this also how the Arduino IDE resets the board to upload new code.
