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