I don’t see how CoolTerm can handshake, since the sending mechanism is a device I built and it doesn’t shake. Both CoolTerm and my Xojo project receive the same Bluetooth feed from the system. I just checked … I have Flow Control unselected in CoolTerm. And, my data feed is now waiting half a second between groups of 15 bytes, so it’s definitely not too fast. Something else must be going on in my Xojo code.
When I run the serial terminal project generously shared by LangueR, it reads the first 3 or 4 lines correctly, then displays nothing more. I presume this is because it is getting characters with a value of 00 and E0 and doesn’t show them. So it appears that his code has the same difficulty as my own.
So your problem is not that you are loosing data. It is that you can’t display it correctly. May I guess those are all hex characters being sent. Meaning, you are not receiving ascii characters from the device, but hex characters. The example I gave you displays any ascii characters it receives, but hex ones which do not translate to a visible character will not display. And yes that has nothing to do with handshaking. Most of the embedded devices we work on have no handshaking whatsoever. Anything related to PICs, AVRs, Arduinos, etc follows pretty much that same design logic.
For displaying HEX values coming on the RS232 stream we’ve used MemoryBlocks if I recall. But what happens if you change the code within DataAvailable to something as follows:
Dim s as String
s=Serial1.ReadAll()
s = EncodeHex(s, True)
TextAreaRs232Rx.AppendText(s)
No, the characters aren’t hex, and CoolTerm shows them correctly. My hardware sits in a loop and outputs a new line every half second. But your project and my project only manage the first 3 or 4 lines correctly. Then my program displays them as 00 and E0, and your program shows nothing. If I exit your program and re-enter, it shows the first 3 or 4 lines correctly again (like my program does). The sending software never changes.
THis is copied out of CoolTerm:
abcdefghijklmno
abcdefghijklmno
abcdefghijklmno
abcdefghijklmno
abcdefghijklmno
abcdefghijklmno
abcdefghijklmno
abcdefghijklmno
abcdefghijklmno
…
And just out of curiosity, you say the device spits out “abcdefghijklmno” over and over. That matches with “61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 0D”. What the heck is this “E0 00” that seems to go on forever then. Again this question is just mere curiosity.
Well, that’s the problem I’m writing about. The two apps I have in Xojo are unable to receive (or show) the correct characters. The 00 E0 characters are not correct, but they are what Xojo reports from the serial port.
Remember, if I exit your program and come back in, it shows me a few lines of “abcdefghijklmno” again, and then reverts to invisible characters. I have not started and stopped the sending device, it just runs forever.
I will attempt to program a PIC tonight that outputs “abcdefghijklmno” over and over. At 9600, with 500msec between repeats. And see what the terminal captures. I hope it is not related to the virtual driver you have (something like a Prolific driver). All the stuff we’ve used uses FTDI drivers.
That’s a lot of effort to go to, but I greatly appreciate your help. My situation is complicated by the fact that my PIC chip serial I/O pins feed a Microchip RN-41 Bluetooth module, which sends the data to the Mac’s Bluetooth interface. It is the Mac that creates a serial port that Xojo can open.
You might think there are lot of things that could go wrong, but CoolTerm on the Mac reads the same data correctly from the same Bluetooth “serial” port.
I can’t imagine how. My PIC board has no USB interface. And, while it might be interesting to try that, the point of my Xojo project is to monitor the data stream of the Bluetooth output.
It occurred to me that I have two Bluetooth projects with PIC chips. I make a timing tool that measures the time between ticks of watches. The output of the watch timer is a string of ASCII text 18 characters long. The same program that can’t read “abcdefghijklmno” five times in a row can read every measurement from a watch that’s ticking five times a second.
Trying to think of what’s different between the two PICs, I added a after the . It still fails to read.
Maybe the watch timer is in a slower loop. I put a quarter second delay between each character and the “abcdef…” still fails to read.
You will say there must be some fault in my PIC device. But CoolTerm can read it all. For some reason Xojo seems unable to manage this data stream.
Along those same lines Tim is pointing to, can you connect the PIC’s serial output to the Mac directly? That takes the Bluetooth out of the equation for a momen (forgetting for a moment CoolTerm is working fine).
Tested this on both XP and W8.1 (sorry only one Mac, it belongs to my better half and I am not allowed to tinker with it - yet). I received all the bytes with no problem. Tried three different USB-serial cables I have (all FTDI though).
So, thinking a bit more on what Tim was saying earlier. Have you tried using a timer and adding the “Serial1.Poll()” within its action event. An example of that is here.
This other example uses a timer to update the TextArea using the BytesAvailable propery.
Hopefully one of this two things will get you going.
Forgive me for insisting, but as often quoted from Arthur Conan Doyle’s Sherlock Holmes, “when you have eliminated the impossible, whatever remains, however improbable, must be the truth”. Your device does not use software handshake. Got it.
Nothing ever happens in a technical setup without a reason. On one hand, you have a Xojo program that looses it after 45 bytes, and on the other hand Cool Term which happily reads what your device sends.
The device may not use software handshake, I do not see how you can have it communicate without hardware signals :
I suppose Cool Term is monitoring hardware signals to synchronize. Blue tooth or not they are present the same. Sounds like the only explanation for it working fine.