first stab at Aeris A300CS support

[Jef Driesen]

On 2014-09-26 15:59, Dirk Hohndel wrote:
> The checksum for 256 times 'FF' is '00 FF' so I think you are wrong.

I think that gives away the checksum function. 256 times 0xFF is 0xFF00. 
Store that as little endian and you have a perfect match with your 
checksum bytes! So it's summing up 256 bytes in a 16bit integer. Now 
just check on some other, more random packets to confirm this.

>>  * Setting DTR/RTS twice looks really odd. Are you sure this is really
>> needed? Does the Aeris application does this too? (Note that due to 
>> how the
>> win32 api works, DTR/RTS are automatically set when configuring the 
>> line
>> settings, but there are also separate calls for DTR/RTS.) For other 
>> devices
>> I noticed that setting DTR/RTS may require a small delay after opening 
>> the
>> serial port. So maybe you are just not doing it at the right time. Try 
>> to
>> move it after that 100ms sleep.
> 
> I can play with it some more. The Windows app does exactly that (I 
> would
> never have come up with trying to do it twice) but it's entirely 
> possible
> that it's instead a delay that I need.
> I also noticed that I didn't insert these four calls in the correct 
> spot -
> the check of the return code of the serial_configuration call should 
> come
> first.

I need to look at the portmon files before I can tell anything useful 
here.

> And staring at this code some more (this is basically your code just 
> moved
> into a different function) I notice that we are inconsistent in when we
> use rc and when we directly check the result of a function call. I'll
> clean that up as well.

I noticed that too, just forgot to mention it.

>>  * I don't see the different baudrate anywhere in the patches. Did you
>> forgot to include that part?
> 
> No, after Linus' comments I went back and did more experiments and 
> things
> work fine with 38400 - what was needed was the RTS/DTR toggling.

Ah great. That means that we can maybe set RTS/DTR unconditionally. And 
then we no longer need to pass the model number. I need to check whether 
setting RTS/DTR affects current devices or not.

>> Can you send me a full memory dump so I can try your code? Preferable 
>> with a
>> portmon capture too.
> 
> Sure. Do you have a USBACM simulator? Or are you just telling
> libdivecomputer to use a normal serial port for testing it?
> Attached.

The kernel g_serial module can emulate an USB-ACM devices. I've used it 
in the past, to attach the USB-CDC device to a VM in order to use the 
manufacturer software. But for the libdivecomputer simulator a normal 
serial port (or even a pty) will do.

Of course I still need to update the simulator with the B4 command. It's 
already partially there, from when I was experimenting with the OC1 
command B4 command.

Jef