Dear Stefan Schmidt,
In message 20111106170219.GB20104@excalibur.local you wrote:
Could you please be so kind and explain which exact issues you see for such a separation?
As Andrzej pointed out the DFU spec is written by the USB forum and one can see that there target are USB devices. Let me bring in some facts from the spec.
...
All bound to the USB spec and hardware for using the spec in a standard compliant way.
Yes, indeed.
But I feel you stick way too close to this spec, and are not trying to abstract awway the low level details a bit.
Yes, this spec was written by the USB forum, and they did not even attempt to look over the rim of their plates. But does that mean we all have to do the same? I'm not willing to accept such a narrow view.
Let's - just as a gedankenexperiment - assume our task was to implement a solution that provides similar capabilities as DFU, but must work over serial line, Ethernet, Bluetooth, Infrared, whatever. Assume we thing DFU could be used as base, but we need to find a way to move the USB related things into the USB layer, while things like the state machine, the requests, device status, state transitions, etc. are generic enough.
Yes, the DFU File Suffix contains fields that map nicely to USB devices - but what prevents us to provide similar data on non-USB media, too? We just need to make sure that th code which handles this allows to plug in handlers for other transfer media.
As always in computers one could try to come up with solutions to replace the USB hardcoded parts with something else for a UDP based solution. Its just now longer compliant with the DFU spec. All DFU
I'm not sure what exactly you want to tell me here.
My idea is that of an implementation that is split into a generic and a device specific part. If implemented corectly, the combination of the generic part with the USB specific part would be strictly conformant to the DFU spec.
Of course, the combination of for example the DFU generic part with an Ethernet network interface would not be conformant to the DFU spec, but it would be something that works in a very similar way. And that would most probably be better than inventing yet another download method.
flashing utils out there are only working over USB. All the windows flash utils as well as dfu-programmer, a small dfu util from the bluez project and also dfu-util. The last ones are using libusb for this.
That's the status quo. Agreed. Bit this can be changed, extended. Or not?
The main point is that if you replace the USB related parts with something else not much of DFU stays anymore. It would be a different
I disagree here. DFU is different in a number of aspects, and you know this very well.
flashing procedure. And for systems with a network interface available there are way better ways to flash it then DFU. Even TFP would be more convenient for them. You are way more flexible with Ethernet here.
I'm not sure what your exact argument is here. I'm not the one asking for DFU support. I would be happy to use TFTP over Ethenret over USB. We're actually doing this in some products.
DFU was designed for really small devices with minimal software originally. Best examples are Bluetooth and WiFi USB dongles which can be flashed this way if they. Its just that it becomes more popular as many consumer electronics device are coming with a USB port but no Ethernet these days.
Agreed. And if it's becoming more popular, it might even be a good idea to think about a less restricted implementation, which opens new oportunites.
Yes, I think we should strive for such a separation of USB transport layer and protocol implementation / state machine / command interface.
Best regards,
Wolfgang Denk