Flow Control Behavior Changed between 4.0.7 and 6.0.0

[vicatcu]

I'm opening this (documentation only?) issue in follow up to closing https://github.com/node-serialport/node-serialport/issues/1358. The default hardware flow control signaling (i.e. RTS / DTR) behavior changed, on Windows only, between 4.0.7 and 6.0.0. I think this should at least be documented in the upgrade guide. Though perhaps this is the statement that's already there describing this:

windows: We previously hard coded to have RTS on for windows at all times it now default to off.

My observed/measured experience, using an FT231X USB-Serial interface chip, was that 4.0.7 leaves these signals in a state of RTS=LOW, DTR=LOW, whereas 6.0.4 leaves these signals in a state of DTR=LOW, RTS=HIGH. Because my hardware circuits depend on the prior state to hold, in order to migrate from 4.0.7 to 6.0.4 in my applications, I had to explicitly add into anywhere I created a new SerialPort into the callback a line like this:

var SerialPort = require('serialport');
var port = new SerialPort('COM5', function (err) {
  // ...
  port.set({dtr: true, rts: true});  // this is the only line I added.
  // ... 
});

It took a long time for me to get to the point of this being the root cause of my problems, it might be nice to make future developers get there faster by identifying this as a possible migration issue explicitly in the docs. I know, for example, that many ESP8266 based designs (and in particular NodeMCU) use the same circuit on their hardware to manage boot state and reset of the ESP8266, but perhaps they use a different USB-Serial interface chip.

[vicatcu]

I'm actually willing to have this issue be closed, but I'm interested in the rationale that lead to changing the RTS behavior.

[reconbot]

It matched the other platforms, documented in the changelog. Totally acceptable to be in the actual docs too.

On Tue, Nov 14, 2017, 9:51 AM Victor Aprea [email protected] wrote:

I'm actually willing to have this issue be closed, but I'm interested in the rationale that lead to changing the RTS behavior.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/node-serialport/node-serialport/issues/1399#issuecomment-344282621, or mute the thread https://github.com/notifications/unsubscribe-auth/AABlbjDV69Gf8kClfU-smJNYIvfemSiqks5s2aj6gaJpZM4QdavF .

[vicatcu]

It's kind of befuddling why Linux and Windows behave differently in this regard then...

[unknowndomain]

This is a potentially major issue, myself and a colleague have spent hours trying to figure out why it was causing the Arduino microcontroller to reset in a weird way while older versions worked fine, this was reproducable on all versions of node and OS X that we tested.

[reconbot]

The flow control is now the same between systems, previously it was unable to be set on windows and defaulted to different than linux defaults. The change was introduced in a major version change of the library with notes in the change log and upgrade guide.

Happy to accept a PR with notes in the readme calling out this change as well. Happy to hear what else we could do to prevent wasting people's time.

[unknowndomain]

So here's the issue, this library is used frequently by people with Arduino boards or other clones where the reset into programming mode is performed by the DTR or RTS lines which are normally not used, all previous versions of this library work just fine out of the box with no special settings.

Now with this new update it has enabled flow control by default which is unusual as serial monitor/consoles go and that is resetting the Arduino every time you try to write to it.

This was reproducible on Node 6.x and 9.x on OS X Sierra and OS X High Sierra on Arduino Uno and Leonardo (both R3).

I don't know what the discrepancies were between Windows and Linux previously, however now the default behaviour creates a pesky issue when using any device which utilised the hardware flow control pins for reset, programming or DFU modes. This presents at best a massive headache for everyone using the latest version as they'll have to spend hours trying to figure out whats going on, at worst it could result in someone bricking a device by resetting into programming mode on a commercial product and then sending it junk data.

Perhaps I am misunderstanding, but none of the serial monitors or consoles that I've looked at have flow control lines enabled by default, so why now is serialport suddenly doing this?

[reconbot]

I'm 99% sure it's always done that to arduinos on linux for all versions.

[unknowndomain]

I've been using this node module for a long time and never encountered this issue until yesterday.

Is the way it works on OS X the same as Linux?

[vicatcu]

Not to be obtuse, but again I'm pretty confident it's not the same right now (i.e. in 6.0.4) on Windows compared with Linux (haven't tried on Mac).