The back-end parser seems to be the same as for the Uwatec Smart (aka
Galileo Sol). At least that's the assumption right now.
The downloader just uses USB HID (very similar to EON Steel) rather than
the horrible IrDA thing.
There's also eventually a BLE thing, but that's for the future.
This is an unholy mixture of the Uwatec Smart downloader logic and the
EON Steel usbhid transfer code. The back-end is pure Uwatec Smart
(model 0x11, same as Galileo Sol).
I'm not at all sure this gets everything right, but it downloads
*something*.
[Jef Driesen: Renamed the backend to uwatec, and made some smaller
cosmetic changes to match the existing coding style.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When the device family is provided without an explicit model number, we
simply choose the first available model. But since new models are being
added all the time, this default model is not guaranteed to remain the
same. That's not desirable because it can alter the behaviour of the
application.
The introduction of the Aeris 500AI is an example of this problem. The
default model in the vtpro family used to be the Oceanic Versa Pro. But
because the Aeris 500AI has a lower model number, it automatically
became the new default model. Since both use a different protocol
variant (MOD vs INTR) they are not interchangable.
The default model is now hardcoded. The best option is of course to
provide the model number explicitly!
The universal application works well, but is quite difficult to extend
with more functionality. Therefore a new and more modular application is
needed. The new dctool application will support multiple sub-commands,
to carry out specific actions. Extending the application will be as easy
as adding new commands.
The public api is changed to require a context object for all
operations. Because other library objects store the context pointer
internally, only the constructor functions need an explicit context
object as a parameter.
