signal11
RFC: Add support for DFU
Hi,
My name is Richard Hughes and I'm the guy behind the ColorHug project. For a few hardware versions I've been using the Microchip USB stack which I've been getting increasingly frustrated with. In comparison, m-stack has been an absolute pleasure, and is available as GPL which makes producing easy-to-consume OpenHardware so much easier. Thanks!
For an upcoming project, I've decided to switch the bootloader to DFU (www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf) which allows me to support different OS's and use a standardised interface rather than the ColorHug-specific HID bootloader I'm using now.
I've implemented usb_dfu.c and am currently using it as a runtime-mode and DFU-mode state machine. I've implemented enough to make my device work work, but I wondered if you were interested in having this implementation as a pull request into m-stack? If so, I'll do all the extra work to write a demo program, use the same documentation style as the rest of your project, and add all the optional parts of the specification. If you're not interested (it is self contained, and doesn't need any changes to existing files in m-stack) that's fine too.
I'm also the guy behind the fwupd and LVFS projects, so I'm quite interested in making it easy for OpenHardware projects to deploy updates onto thousands of devices securely. I'm also a PIC guy, although there is also one person working on the arduino support for DFU as well. If I can get people using a standard protocol (e.g. I tell them "just use this file from m-stack") then I only have to write one USB update provider for fwupd, rather than the plethora of USB bootloaders there are now.
I'm also happy to sign the ICLA. If this sounds interesting to you I can put together a pull request for some initial review. Thanks.
I had a look at the code, and I think it looks great! I'll provide some more detailed comments in the coming days. Which MCUs are you currently targeting, and which userspace DFU software have you validated with?
I'm currently using a 18F46J50 on a custom PCB although there's nothing intrinsically pic18 specific about it I think. I've got the J50 buried somewhere at home for the app examples which I'm guessing you'll want at some stage.
I've validated the implementation with dfu-util, although I have opened up a feature request for a little extra feature that makes it easier to deploy on a device like the ColorHug+: https://sourceforge.net/p/dfu-util/tickets/10/ -- without it everything still works but you have to tell the user to do dfu-util --list when in appIDLE mode to make sure the bootloader does the extra step. Or, you could just implement a bootloader app that uses DFU without the "auto-boot" eeprom check if the device has something like a "force bootloader" button, or if the device has a single firmware/bootloader space that shares the USB stack code. Anyway, I'm probably confusing you now. For a demo app we'd probably just want to keep it simple and provide the hooks in usb_dfu to do the more complicated things.
I'm also the guy behind fwupd, and I've just merged in a LGPLv2+ libdfu private implementation (which also does the extra step) which means we can deploy DFU updates on https://secure-lvfs.rhcloud.com/ -- libdfu is pretty new and as-yet-unreleased but it does support things like cancellation and loading files from remote locations.
The fwupd code is here: https://github.com/hughsie/fwupd/commit/a3acd7f7111295ffecbd7957a56b19d94961502d The ColorHug code (what the dfu example app code would mostly look like) is here: https://github.com/hughski/colorhug-plus-firmware
All review very welcome, I'm also happy to "sign" the CLA and update the file headers with GPLv3/commercial if you send me it via email (info_at_hughski_dot_com).
I forgot to say; I'm also happy to send you a ColorHug PCB for free if you want to test DFU on a real device with all the LVFS and fwupd integration, although I suspect you'll just want this working on the demo boards.
