first stab at Aeris A300CS support

[Dirk Hohndel]

On Fri, Sep 26, 2014 at 04:58:57PM +0200, Jef Driesen wrote:
> 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.

Brilliant! You are indeed correct.
Now given that you wanted me to generalize this so it can also deal with
the 128 byte pages - do you have a trace for that where I can see the crc
returned there? Your sample code seemed to indicate that in the 128 byte
case just one extra byte was returned, so I'm guessing it's a simply
add8...

> >> * 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.

That did the trick - it now works fine with just one set of DTR/RTS calls.

> >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.

Hehe - it was your code :-)

> >> * 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.

That would be nice. Less complication. How many devices do you have access
to in order to test this?

> >>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.

Funny, I was just in the process of creating a USB-ACM simulator using
g_serial and some userspace glue. If you already have that working, I'd
appreciate if you could share it.

> Of course I still need to update the simulator with the B4 command. It's

It's B8 for the 256 byte page.

/D