hathach
Support DFUse (st extension)
Is your feature request related to a problem? Please describe. ST extension is aka DFU 1.1a has some special command such set address, erase etc... I am not sure if it is preferable over std DFU 1.1 but it seems to be popular.
- http://dfu-util.sourceforge.net/dfuse.html
- https://github.com/siemens/dfu-util/blob/master/src/dfuse.c#L162
- https://www.st.com/resource/en/application_note/cd00264379-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf
I had looked at other DFU's at the time, as my company had a nonstandard DFU tool as well that had custom extensions.
From what I saw, DFU 1.1a is quite popular, given how popular ST is as a platform, but DFU 1.1a, is more like DFU 2.0, as it is not compatible with DFU 1.1 devices. The main problematic part is the overloading of DFU_DNLOAD and DFU_UPLOAD. Additionally, many of their custom commands are for specific bootloaders, and thus they have many different versions.
It just so happens that I have an ST part that needs a new DFU mode of transport, and USB might fit the bill. If I were to have time to make a PR ready implementation, how you would want the DfuSe support structured? Should it be a compile time option to specify DFU_1_1 or DFU_FUSE_[Maj]_[Min]? Also, if I were do have the time to do this, I would likely only implement DfuSE 2.1 or 2.2 which has the OTP memory support that someone had wanted, but is reasonably well defined unlike 3.0.
sure thing, please make an PR if you oculd, we can review and merge it. Don't worry too much about the setting we can just invent CFG_TUD_DFU_FUSE_xyz or something. The implementaiton is more important, the rest we can go through via review/comment