I’m very new to xojo, but have lots of time with Arduino and serial comms
I have two problems that I suspect are related
I’m trying to talk to an Arduino UNO
the software is ok - I can use the Arduino monitor at 57600 and it works a treat
now trying to develop a xojo App to do the same
I am able to send simple command to the UNO
each one send back lots of data
the symptom is that I seem to be losing data
I’m using a serial port; tried lowering the baud rate to 1200, but to no avail
the code for receiving is trivial
recvText.visible = False
recvText.visible = true
the text box (recvTest) blinks a lot, so data is arriving in chunks
I only added the visible on/off to see if that made a difference
and another thing…
on the MAC (OSX) the text is filling up with shed loads of “question makrs in side black diamond” characters
I tried various combinations of flow-control, but not surprised that it makes no difference
Arduino IDE seems to be able to not lose data at 57,600 even on the MAC
so - c’mon chaps - what’s the secret?
could it be a problem with encoding?
maybe you put result from read all in variable, so you can make breakpoint and check if there is something inside?
Or count in a property how many bytes arrived and show that in al abel?
Finnally, is this code in DataAvailable handler for Serialport control?
answering the questions in reverse order:
yes that code is in the Serial1.DataAvailable event
checking the data is a neat plan will give that a try
can’t see where to change encoding or what effect it’s likely to have
when the data arrives it’s ok (aside from the odd ??? in MAC land)
well that is strange
I changed the event code to store the data in a string (so I can use the debugger to look at it)
debugger shows it’s ok
er - and the code works now
maybe you just can’t jam the data fast enough directly into a text box
thanks for the pointer!
Keep in mind that BytesAvailable may be greater than zero, but that doesn’t mean that all of the data has been received. Usually there is some sort of terminator on communications so you can tell when the end of message is received. If the messages are quick, you may have the start of the next message too.
Your event will have to keep track of the data sent, parse it (using the terminator), and then process it. I think what you’re seeing in the debugger is that by stopping to look at some data, the entire message makes it into the socket queue and then you handle it all. Whereas at runtime you’re leaving too soon.
thanks for the feedback
the “protocol” such as it is consists of a simple, one or two character command, with loads of data as response
storing the data in a variable, instead of directly to the text box control, has fixed the problem
it runs perfectly at 57600 baud with no debugging
and another thing…
seems the MAC side of the house needs
data = me.readall(Encodings.windowsansi)
so bunny.happy := 2