Serial port not opening or no response at high speed on Linux with Xojo only

Hi all, I think the title should address my question but here goes…

I have a black box device (eprom emulator) that communicates via a FTDI USB to serial chip (virtual serial port) at 921600Bps. This speed is not changeable!

There is a commercial app thats written for Windoze that works well but I’d like to use the device in Linux, So I wrote my own version in Linux software called Gambas. This was successful and worked well but since discovering Xojo I’ve wanted my own version to work cross platform… Once again I re-wrote my version but in Xojo this time.

My app works fine in Windoze XP up to Win 10 on any computer I can throw at it. Linux is a different story!

Problem seems to be the opening of the port at 921600Bps… It doesn’t seem to happen…

What I found is the port is opened at the default computer start up rate of 9600Bps and transmitting the data at this rate… This was tested with a logic analyser on the data lines of a Prolific USB to serial chip…

The interesting thing is if open the com port at 921600Bps and close it again using a different program or three (moserial [after fixing the 921600/927600bps bug], cutecom and gtkterm) then go back to my app, it will work fine at 921600Bps.

What I did find was Xojo was setting DTR to false on serial port opening. This was found after extensive searching for decent serial control line monitors (ended up using statserial) to see if anything bazaar was happening. Setting DataTerminalReady to TRUE has fixed this problem but not the baud rate issue.

But this problem doesn’t seem to be related to just my app. The fine program called CoolTerm written by Roger Meier in Xojo has the same issue. It too is fixed by opening and closing the port with a different program then running CoolTerm again.

Like I said above, My app and CoolTerm have no problems in windows.

I don’t believe its a Linux driver issue due to the fact that other programs have no issue opening the port/device at 921600Bps.
I don’t believe its a USB to serial converter issue as FTDI is well known and supported, other brands also work at the required speed (with different software) and I’ve tried a few different other converters from various sources.

I’ve tried my running my app in Xojo version 2015r2.2 up to 2016r4.1 with the same result. All 32bit builds.

I’ve tried different desktop computers and laptops as well.

Below is the code snippet I’ve used when pressing a “connect” button on the GUI. A keen eye will see that most of this is taken from Xojo’s own serial example…

[code] if me.Caption = “Disconnect” then 'Disconnect from the serial port
me.Caption = “Connect”
SerialPortsPopupMenu.Enabled = true
PortListUpdater.Mode = timer.ModeMultiple 'turn it on
else 'Connect to the serial port
Serial1.DataTerminalReady =True
Serial1.RequestToSend =True
Serial1.SerialPort = System.SerialPort(SerialPortsPopupMenu.ListIndex) 'Set the serial port to the index of the one chosen in the popup menu
if serial1.Open then
TextArea1.Text = "Opening com port " + Serial1.SerialPort.Name + Chr(10)
me.Caption = “Disconnect”
SerialPortsPopupMenu.Enabled = false
PortListUpdater.Mode = timer.ModeOff

					'The following is just debug info and needs to be removed!!!
					MsgBox "RTS is " + HighLow(serial1.RequestToSend)
					MsgBox "CTS is " + HighLow(serial1.ClearToSend )
					MsgBox "DCD is " + HighLow(serial1.DataCarrierDetect )
					MsgBox "DSR is " + HighLow(serial1.DataSetReady )
					MsgBox "DTR is " + HighLow(serial1.DataTerminalReady )
					MsgBox "RI is " + HighLow(serial1.RingIndicator )
					MsgBox "The selected serial port could not be opened."
			end if
	end if

If anyone has an idea to try that I haven’t already then please let me know.


Serial.baud must be a constant i think.

Docs say something about setting non standard baud on linux:
On Linux, some non-standard baud rates are possible to achieve by using the Setserial system call and setting your baud rate to a special value

Thanks Derk for your reply. I did read the Serial.baud docs - as vague as they are for baud rates not included in the table…

Unless I am wrong about this but Setserial is an external application rather than a system call as such on my distro of linux (debain 8.1). It has to be retrieved from the repo or compiled from source. Stty is a similar program that will do the same job and is included with my distro.

I ran the command “stty -F /dev/ttyUSB0 921600” to set by USB com port device to 921600Bps and sure enough my application works.
But setting the serial port baud rate with an external program like Setserial or Stty is just the same as opening the serial port with another serial terminal program then closing it again as stated in my first post… Its a NASTY hack just to get the job done…

Should I be calling Setserial or Stty from within my app to correct the baud rate issue?

I’ve got to ask why can setserial or other applications open the port at a specified baud rate but Xojo can’t get it right (for linux)? Is it something to do with how Xojo interacts with the system, kernel, API’s etc…?

Another question is why does MAC [quote]On OS X, the system supports arbitrary baud rates by passing the request along to the driver. If the driver supports the passed baud rate, then it is set (or approximated).[/quote] try this but not on linux?

921600Bps is not a special value, it is divisible like the rest etc… Can the class constants for baud rates available be updated/added to in future releases to support modern high speed devices? Or does this date back to legacy issues…?

Most programs in linux simply use a pipe or shell to communicate. Xojo is trying to make it more easy but you want something that’s not usual. So your required to do it the unusual way. SerialPorts give you information about rated and max speed. Those are bauds you can use as the device will accept them.

I think the baud 921600 BPS is used from usb 2.0 and later. I don’t think the xojo serial is updated after that. Perhaps you can make a feedback case to update baud rates to faster common rates for all platforms.