Dear Wolfgang Denk,
Please see my comments inline.
DFU is part of USB; an extension to be precise, but an extension
bound
so tightly to the design and philosophy of USB that it is rather inconceivable to separate the two.
Could you please be so kind and explain which exact issues you see for such a separation?
First of all, I think that it is more proper to speak of communications part and state machine part. They are bound together by the standard. For example, in the dfuIDLE state, the receipt of DFU_DNLOAD request with wLength == 0 triggers a "device stalls the control pipe" action. This kind of stuff is very USB specific - I am not sure what would "the control pipe" be for serial/Ethernet, nor what "stall the control pipe" would mean for either of them. Another example, in the dfuMANIFEST state, when the status poll timeout occurs and bitManifestationTolerant == 1 then "device can still communicate via the USB".
The communications part is of course the very USB itself, so the only thing which could be extracted is the state machine part. But, then, in order not to be bound to USB but reusable, it should be abstract. Being abstract, it would not be DFU anymore, but some "Generic Update Protocol" that you have on your mind, but we don't know of. Is there any standard for such a protocol?
Seriously speaking, in view of ties between DFU and USB IMHO it is impossible, or, at least, highly impractical.
Can you please support this statement with a few facts?
Please see my comment above.
If my assumption is correct, then what would it take to split off protocol part and make it independent of the actual driver
interface?
I guess that in the situation given it would be of little use.
What do you think would be of little use?
As far as I understand you correctly, you would like the state machine code extracted from the initial DFU implementation posted on this mailing list. And then you would like the DFU implemented in terms of this abstract state machine. This means actually more code, probably not a desired thing. The generic state machine would also require some accompanying generic data structures, and this would also mean code to translate back and forth between USB/DFU (DFU _is_ USB) and state machine's data structures. All in all, this means adding more complexity and code. This looks like a premature optimization (which is widely known to be the root of all evil), while at the moment, there are no use cases to justify it. Should the use cases appear, the code can be reworked based on the needs of both USB/DFU and new state machine users.
Regards,
Andrzej