CoolTerm xon/xoff problem

If you have specific questions or problems with any of my Freeware applications, post them here.

CoolTerm xon/xoff problem

Postby catkins » Wed Jan 25, 2017 4:10 pm

Hi there,

First, I'd like to say thanks for creating such a great app. I've been using the Mac version for a little while now, and it's great!

I have a slight problem getting xon/xoff to control the rate of transfers to my Arduino when using the "send text file" function. In CoolTerm's connection options menu, I have enabled xon support. My device writes xoff (0x13), when the serial buffer exceeds 50% (and xon once it is drained). CoolTerm correctly displays the state "xoff" in the status bar at the bottom of the window, but file uploads do not stop. As a result my arduino serial buffer is overflowing and my application fails.

Because of the way the serial port on arduino is wired up, I cannot use hardware flow control.Have I understood the xon function correctly, or am I making a mistake with my assumptions?

Many thanks!
catkins
 
Posts: 3
Joined: Tue Jan 24, 2017 5:47 pm

Re: CoolTerm xon/xoff problem

Postby roger » Wed Jan 25, 2017 8:11 pm

Hi,

Your understanding of how Xon works sounds correct. Xon/Xoff flow control is a feature that is handled by the API and the driver, at a lower level than CoolTerm. If Xon/Xoff flow control is enabled and the targets sends an Xoff character, the serial port should stop sending data immediately. However, this is beyond CoolTerm's control. It is only by chance (i.e. a bug in the FTDI and Prolific drivers) that Xon and Xoff characters "leak" through to CoolTerm's receive buffer, allowing the app to display "xoff" in the status bar. If everything worked correctly, CoolTerm should never receive Xon or Xoff characters if flow control is turned on as it is suppose to be trapped by the driver. If you try the same with a SiLabs device, you won't see the "XON" string change to "XOFF" if xoff is received.That said, I have verified that data transmission is stopped immediately once the serial port receives an Xoff character with all my USB/serial adapters (FTDI, Prolific, SiLabs, Keyspan). Most likely, there is an issue with your device driver. Perhaps Xon/Xoff flow control does not get enabled properly on a lower level while CoolTerm thinks that it is. I would recommend installing the latest driver. Which Arduino model are you using?

Roger
User avatar
roger
Site Admin
 
Posts: 203
Joined: Fri Apr 24, 2009 12:41 am

Re: CoolTerm xon/xoff problem

Postby catkins » Thu Jan 26, 2017 4:40 am

Hi Roger,

Thanks very much for the quick reply! :-)

Most likely, there is an issue with your device driver. Perhaps Xon/Xoff flow control does not get enabled properly on a lower level while CoolTerm thinks that it is. I would recommend installing the latest driver. Which Arduino model are you using?


I am using an Arduino UNO Rev3 board (https://www.arduino.cc/en/Main/ArduinoBoardUno). It uses an ATmega16U2 as a usb/serial port interface, which is supported by the OS COM port driver. I can't update the driver since it's the built in Mac OS COM driver. I'm running Mac OS Sierra 10.12.3. I don't know if there are any alternative third party drivers - I couldn't find any on the web...

I'm not really sure what else to try. Do you know of any OS-level settings/configurations that might affect this device?

Many thanks!
catkins
 
Posts: 3
Joined: Tue Jan 24, 2017 5:47 pm

Re: CoolTerm xon/xoff problem

Postby roger » Thu Jan 26, 2017 10:28 am

I'm not aware of any other drivers for the Arduino Uno. Do you have access to an Arduino that uses an FTDI chip instead of the ATMega16U2?
You might also want to try this with a different terminal, just to rule out that there is some weird interaction between the driver and the API CoolTerm is using that causes this problem. Meanwhile, can you send me your sketch, or a test project that demonstrates the issue? I can get my hands on an Arduino Uno R3 to see if I can replicate this. Please send it to my e-mail address (you can find it on my website http://freeware.the-meiers.org/)
User avatar
roger
Site Admin
 
Posts: 203
Joined: Fri Apr 24, 2009 12:41 am

Re: CoolTerm xon/xoff problem

Postby catkins » Fri Jan 27, 2017 4:05 am

I'm not aware of any other drivers for the Arduino Uno. Do you have access to an Arduino that uses an FTDI chip instead of the ATMega16U2?


I have three Arduinos, but I'm afraid they all use the same ATMega chip for comms. :-(

You might also want to try this with a different terminal, just to rule out that there is some weird interaction between the driver and the API CoolTerm is using that causes this problem.


I think I understand the problem a little better now. I tested with other terminal apps on mac (minicom, screen) and I also used stty to set the port parameters directly, while echoing the output using cat. I found that none of these programs responded to xon/xoff settings. After a little digging around on the net I think that the default serial driver when connected to an Arduino does not support xon/xoff. I don't know if this is due to the driver, or due to the ATMega16U2 firmware indicating that the device does not support xon/xoff.

In any case, I think the problem is not with CoolTerm!

Meanwhile, can you send me your sketch, or a test project that demonstrates the issue? I can get my hands on an Arduino Uno R3 to see if I can replicate this. Please send it to my e-mail address (you can find it on my website http://freeware.the-meiers.org/)


I'll send you the sketch in any case, perhaps you might come to a different conclusion!

Many thanks for your support!
catkins
 
Posts: 3
Joined: Tue Jan 24, 2017 5:47 pm

Re: CoolTerm xon/xoff problem

Postby roger » Fri Jan 27, 2017 10:21 am

Thanks. I'll try your sketch over the weekend. Meanwhile, there are ways in CoolTerm to throttle the data. You could run the serial port at a lower baudrate, which might be easier for your Arduino code to catch up. Secondly, you can turn on the character delay option which adds a wait time between characters. You can access this feature in the Connection Options under "Transmit". If you have a way to gauge 'fullness' of your receive buffer (you could blink an LED when it reaches a certain level), you can play around with the delay value until you dialed it in so that it never reaches a critical level. This is a type of feed-forward flow control (as opposed to feed-back flow control like Xon/Xoff).
User avatar
roger
Site Admin
 
Posts: 203
Joined: Fri Apr 24, 2009 12:41 am


Return to Support

Who is online

Users browsing this forum: No registered users and 1 guest

cron