On 2014-09-26 20:19, Dirk Hohndel wrote:
Let me know if we are getting closer or if there are more parts you want me to rework (e.g. the cache code).
I still need to look at your code, but I received some additional test data that will be of interest for your work. Someone tried to download an A300CS with an unpatched libdivecomputer build. Strange enough, reading the data packets worked out of the box, and the download failed only because of the wrong (default) memory layout. Downloading a memory dump succeeded after just a minor patch for the larger memory size.
So it seems that the old B1 command is still working, and without any DTR/RTS changes. You told me none of that worked for you, so I wonder what is going on here.
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.
I have attached the data files, so you can have a look too.
Jef