Aeris A300CS patches [V2]

Jef Driesen jef at libdivecomputer.org
Fri Oct 3 00:52:39 PDT 2014


On 2014-10-02 17:18, Dirk Hohndel wrote:
> On Thu, Oct 02, 2014 at 05:08:42PM +0200, Jef Driesen wrote:
>> I may have an explanation for the DTR/RTS part, but not for the B1 
>> part. The
>> tester is using Windows. If you look at the serial_win32.c code, 
>> you'll
>> notice that the serial_configure function always sets DTR/RTS with:
>> 
>> dcb.fDtrControl = DTR_CONTROL_ENABLE;
>> dcb.fRtsControl = RTS_CONTROL_ENABLE;
>> 
>> So that means when you configure the serial settings on Windows, you 
>> are
>> forced to also set (or clear) the DTR/RTS lines. This is different on 
>> Linux,
>> where the api to control DTR/RTS is completely independent from the 
>> other
>> settings. This independent api also exists on Windows, but DTR/RTS are
>> already set and the extra calls are thus not necessary. That probably
>> explains why it works out of the box on Windows, but not on Linux.
> 
> That would make sense - I did all that testing on Linux. What do you
> recommend we do about this? Make the additional DTR/RTS Linux specific, 
> or
> simply leave them in place as they shouldn't hurt on Windows, either?

I see two possible solutions:

The first solution, which is what you did, is to set DTR/RTS 
unconditionally in the atom2 driver. On Windows this isn't strictly 
necessary, but it shouldn't really hurt either. If possible, operating 
system specific code should be kept out of the device backends, because 
it doesn't belong there.

The second solution is to set DTR/RTS in the Linux serial_configure() 
function. Right now the state of DTR/RTS is basically undefined after 
this call returs on Linux, while on Windows they are always set as a 
side effect of how the Windows api works. By setting DTR/RTS in the 
Linux code too, the resulting state would be the same. So this would 
lead to more consistent behavior across different operating systems. On 
the other hand, devices that need DTR/RTS to be in a specific state 
should always set them explicitly, because the serial_configure() has 
never guaranteed anything about the state of DTR/RTS.

These two options are not mutually exclusive. So I think setting DTR/RTS 
in the atom2 driver is fine. But in addition it might be a good idea to 
change the Linux serial code to match its Windows counterpart. Just to 
avoid similar surprises in the future.

Jef


More information about the devel mailing list