Hi,
I need to send a hex byte to the serial port (USB), which is echoed back by the device plugged into the port - at the moment, this is a simple Arduino routine which accepts the byte and echoes it. I'm pretty sure this is OK, as indicated on the Arduino serial monitor.
I'm getting myself into a real mess trying to read this single byte in Gambas. I found several descriptions, but am not having much success with any of it.
Linked to this, is there any way for Gambas to monitor the serial RX port until the byte is received? I may end up with a delay between sending the byte, and getting the echo.
At the moment, my code looks like this. It does appear to transmit the byte, and the Arduino gets it, and (I think!) is returning it, but I get an 'end of file' error when I try to read it, and so far I can find no info on this.
While Not Eof(sHexFile)
oneByte = Read #sHexFile As Byte
If IsOpenPort Then
Write #Spp, oneByte As Byte
'Print Hex$(oneByte)
inByte = Read #Spp As Byte
Print Hex$(inByte)
Endif
Wend
Serial Port Usage
-
- Legend
- Posts: 2081
- Joined: Thu Jul 23, 2020 5:20 pm
- Location: Isle of Wight
Re: Serial Port Usage
how do you Open the port?
Re: Serial Port Usage
I don't know if this would be of any help to you. I had a project a number of years ago that I needed to read an USB stream and decode it. https://forum.gambas.one/viewtopic.php?t=20&start=10 Maybe there is something in my old thread that might make something click for you.
sholzy
You may start a journey with certain goals or objectives, but things don’t always turn out the way you expect them to.
You may start a journey with certain goals or objectives, but things don’t always turn out the way you expect them to.
Re: Serial Port Usage
Hello, Bruce.
Sorry - I only posted the bit of code about reading the byte. The port is opened by the following, earlier in the routine:
Try Spp.Open()
If Error Then
viewMessage(Error.Text)
Return
Endif
It doesn't throw any errors. I am pretty sure it connects OK, because I have an Arduino UNO on the USB port, which is running a sketch to echo the received byte, and when the port parameters are set and the port opened, the LED on the UNO blinks momentarily (Ok - its not positive - but it does indicate the computer is trying to talk to the UNO). The UNO sketch is one I have used previously to talk to a second UNO, so I know it should pass bytes OK.
I was a little surprised by this problem - I have other code which transmits/receives strings via USB, and have no problem with that - but can I get a byte through???? I guess I'm missing something, but can't see what for the life of me.
Got2BeFree - thanks for the reference, I'll take a look.
Regards An
-
- Legend
- Posts: 2081
- Joined: Thu Jul 23, 2020 5:20 pm
- Location: Isle of Wight
Re: Serial Port Usage
you are sure you have set correct speed, parity, bits, flowcontrol, etc?
Have you tried using th Read event?
Have you tried using th Read event?
Private Spp As SerialPort
Public Sub Form_Open()
Spp = New SerialPort As "SPort" ' provide an event name when creating the object, i used "SPort"
End
' The Read event for Spp
Public Sub SPort_Read()
Dim vData As Variant = Read #Spp, -256
Print vData
End
Re: Serial Port Usage
Hi, Bruce,
According to the Arduino data:-
"An optional second argument configures the data, parity, and stop bits. The default is 8 data bits, no parity, one stop bit.".
The only value I set in the Arduino was the speed (115200), so I assume that it is using the default values for Parity/Start/Stop. (Note to Self - check this!)
I set these same values in my Gambas program, so I believe both ends of the serial connection are the same.
If I use the Read #Spp line, as follows:
While Not Eof(sHexFile)
oneByte = Read #sHexFile As Byte
If IsOpenPort Then
Write #Spp, oneByte As Byte
Print Hex$(oneByte)
inByte = Read #Spp As Byte
Print Hex$(inByte)
Endif
Wend
then it throws an 'End of File' error, which confuses me.
oneByte and inByte are declared as Byte
The test file I am using in the above routine has just 9 bytes at the moment, but I get the same error regardless of the size of the test file. When the code above runs, I get the first hex byte transmitted from Gambas printed out as 41 - its the character A, so it does seem to transmit the correct byte. At the moment, I can't check if the Arduino is receiving it correctly, because the Arduino IDE serial monitor uses the same pins as the USB serial connection, and at the moment I don't know how I can get round that - maybe change the Arduino code so it blinks the UNO led if a particular character is received.
However, assuming the Arduino does echo a byte (it should be A or 41 in this case) the error I mentioned is thrown on the next line of the Gambas code (highlighted above), presumably when the Gambas routine (tries to) read #Spp for the first time.
I don't understand the error message - does it refer to the end of file it is receiving?, and since it has stopped after 1 byte, why is it 'End of File'?. It implies it has read all that has been received - but nothing is printed out, and the routine should be printing Tx - Rx - Tx - Rx etc, so I would see all the 'original' bytes being sent to the Arduino. (?)
I asked in the original post if there was a Gambas way to wait until a byte had been received, partly because eventually there may be a pause between transmission and echo, and partly so I could be sure I had received something!
At one point I suspected I maybe had Serial Tx/Rx Buffer problems, but now I don't think that applies at either end because only one byte seems to be involved, so I am at a loss.
Its all the more confusing when I have working code to read lines of text from a serial port - I'm beginning to think in terms of simply adapting that code to read 1-character lines, then convert the received characters to HEX - but thats a clunker, and it would mean the incoming data would have to have LF and/or CR characters after every data character - and that ain't possible!
In any case, thanks for your input.
Regards, An
According to the Arduino data:-
"An optional second argument configures the data, parity, and stop bits. The default is 8 data bits, no parity, one stop bit.".
The only value I set in the Arduino was the speed (115200), so I assume that it is using the default values for Parity/Start/Stop. (Note to Self - check this!)
I set these same values in my Gambas program, so I believe both ends of the serial connection are the same.
If I use the Read #Spp line, as follows:
While Not Eof(sHexFile)
oneByte = Read #sHexFile As Byte
If IsOpenPort Then
Write #Spp, oneByte As Byte
Print Hex$(oneByte)
inByte = Read #Spp As Byte
Print Hex$(inByte)
Endif
Wend
then it throws an 'End of File' error, which confuses me.
oneByte and inByte are declared as Byte
The test file I am using in the above routine has just 9 bytes at the moment, but I get the same error regardless of the size of the test file. When the code above runs, I get the first hex byte transmitted from Gambas printed out as 41 - its the character A, so it does seem to transmit the correct byte. At the moment, I can't check if the Arduino is receiving it correctly, because the Arduino IDE serial monitor uses the same pins as the USB serial connection, and at the moment I don't know how I can get round that - maybe change the Arduino code so it blinks the UNO led if a particular character is received.
However, assuming the Arduino does echo a byte (it should be A or 41 in this case) the error I mentioned is thrown on the next line of the Gambas code (highlighted above), presumably when the Gambas routine (tries to) read #Spp for the first time.
I don't understand the error message - does it refer to the end of file it is receiving?, and since it has stopped after 1 byte, why is it 'End of File'?. It implies it has read all that has been received - but nothing is printed out, and the routine should be printing Tx - Rx - Tx - Rx etc, so I would see all the 'original' bytes being sent to the Arduino. (?)
I asked in the original post if there was a Gambas way to wait until a byte had been received, partly because eventually there may be a pause between transmission and echo, and partly so I could be sure I had received something!
At one point I suspected I maybe had Serial Tx/Rx Buffer problems, but now I don't think that applies at either end because only one byte seems to be involved, so I am at a loss.
Its all the more confusing when I have working code to read lines of text from a serial port - I'm beginning to think in terms of simply adapting that code to read 1-character lines, then convert the received characters to HEX - but thats a clunker, and it would mean the incoming data would have to have LF and/or CR characters after every data character - and that ain't possible!
In any case, thanks for your input.
Regards, An
Re: Serial Port Usage
Hi, Bruce (and other helpful people),
I came across the example of a serial port (gb.Terminal) in Gambas earlier today, and it appears to be doing just what I need it to do - I downloaded and ran it, and it talks to my Arduino test unit no problems. It sends one (or more) bytes, and they are echoed back, and displayed in Gambas with no problem. So that means (
hang head in shame) I am definitely doing something wrong somewhere, and it must be in my Gambas code - so now I need to work through the terminal example and find out what. (wish I knew!). I've had a quick look through the Gambas code for the g.Terminal, and can see nothing different to what I'm trying to do, but obviously there must be something - wish I'd found it earlier.
Anyway, many thanks for trying to help me. At least, once I've got it sussed, I should know all about sending text and data via the Gambas serial port.
Regards, An
I came across the example of a serial port (gb.Terminal) in Gambas earlier today, and it appears to be doing just what I need it to do - I downloaded and ran it, and it talks to my Arduino test unit no problems. It sends one (or more) bytes, and they are echoed back, and displayed in Gambas with no problem. So that means (

Anyway, many thanks for trying to help me. At least, once I've got it sussed, I should know all about sending text and data via the Gambas serial port.
Regards, An
Re: Serial Port Usage
Sorry to revive this thread again, but once again I've dug myself into a hole.
I've now successfully got my serial link working in both directions, but now I've run into a problem I mentioned earlier.
I have a system which sends configuration details to the serial device. The Serial device needs to take this configuration data, and set itself up depending on the data. In order to tell the controlling PC it has done, it should echo back the configuration data.
My problem is that there may be a delay while the configuration is carried out - at the moment I simulate this on my serial device (Arduino), by simply adding a delay between receiving the configuration data, then echoing back to the PC. However, I need the PC to wait after transmitting the configuration data until the serial device responds - and as yet, I can't find a way to do this, so my question is how can I get an indication from the SerialPort_Read() event that it has data ready for reading. Do I have to let the Read() event put the data in a buffer, then read the buffer when I get round to it, or is there another way to do this?
I've now successfully got my serial link working in both directions, but now I've run into a problem I mentioned earlier.
I have a system which sends configuration details to the serial device. The Serial device needs to take this configuration data, and set itself up depending on the data. In order to tell the controlling PC it has done, it should echo back the configuration data.
My problem is that there may be a delay while the configuration is carried out - at the moment I simulate this on my serial device (Arduino), by simply adding a delay between receiving the configuration data, then echoing back to the PC. However, I need the PC to wait after transmitting the configuration data until the serial device responds - and as yet, I can't find a way to do this, so my question is how can I get an indication from the SerialPort_Read() event that it has data ready for reading. Do I have to let the Read() event put the data in a buffer, then read the buffer when I get round to it, or is there another way to do this?
Re: Serial Port Usage
As far as I recall from my serial coms efforts in the 1980s, yes you have to poll. There is nothing I know of where the local UART interrupts some program to say "I got something" it has to be read on some periodic basis for available data.
But something may have changed in the intervening centuries.
b
: Serial Port Usage
Hi, Bruce,
The Gambas Serial Port (and me) has got me in quite a mess. There is a Read() event, which is triggered by the Serial Port having something in its buffer ready to read. This has then to be read programmatically, so in effect data is dumped in it, then you can poll it. My problem seems to be happening because the Read() event happens, but there is no indication of this, so (in my case) I cannot get to read it before (sometimes) a second Read() event occurs, and more data is dumped to the port, so I lose the first chunk.
I added a line or two in the Read() event to dump the data into a string, which I could read later, but this fails simply because another Read() event overwrites i, because it is inside the event. I'm trying to work out how to retrieve the data before it is overwritten, or to dump it into a different variable each time (wasteful of space, and a bit tricky for me!). My application calls for a byte to be sent from the Gambas application (to an Arduino), which is then echoed by the Arduino (after some processing) to confirm it was received and handled correctly.
I think what I need is some kind of software interrupt to tell me that data is available, and so far, I think this doesn't exist, hence my question. I am now on the point of scrapping the application written in Gambas, and use an alternative language, which I am not too happy about - lot of work will be wasted.
The Gambas Serial Port seems fine if you just want to push serial data out and can wait to read incoming data, but once it becomes time critical, it is no use. Long ago I had a similar application written in VB (which is why I turned to Gambas) and I don't remember having the problems I am having with the Gambas serial port. I hoped I was missing something which someone would be kind enough to point out.
Nonetheless, thanks for the input.
The Gambas Serial Port (and me) has got me in quite a mess. There is a Read() event, which is triggered by the Serial Port having something in its buffer ready to read. This has then to be read programmatically, so in effect data is dumped in it, then you can poll it. My problem seems to be happening because the Read() event happens, but there is no indication of this, so (in my case) I cannot get to read it before (sometimes) a second Read() event occurs, and more data is dumped to the port, so I lose the first chunk.
I added a line or two in the Read() event to dump the data into a string, which I could read later, but this fails simply because another Read() event overwrites i, because it is inside the event. I'm trying to work out how to retrieve the data before it is overwritten, or to dump it into a different variable each time (wasteful of space, and a bit tricky for me!). My application calls for a byte to be sent from the Gambas application (to an Arduino), which is then echoed by the Arduino (after some processing) to confirm it was received and handled correctly.
I think what I need is some kind of software interrupt to tell me that data is available, and so far, I think this doesn't exist, hence my question. I am now on the point of scrapping the application written in Gambas, and use an alternative language, which I am not too happy about - lot of work will be wasted.
The Gambas Serial Port seems fine if you just want to push serial data out and can wait to read incoming data, but once it becomes time critical, it is no use. Long ago I had a similar application written in VB (which is why I turned to Gambas) and I don't remember having the problems I am having with the Gambas serial port. I hoped I was missing something which someone would be kind enough to point out.
Nonetheless, thanks for the input.