usbdfu small tidy up #230
usbdfu small tidy up #230
Conversation
The only difference between these different implementations is the pin configuration for pulling up the USB D+ wire, and related clock setup. Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
this is exactly why I'm not doing any changes like this, it's too easy to just have copypasta all over the place, I'm not touching these further in the same path. |
|
Erm, what is your suggestion here? Can't you e.g. just pick the second commit, which improves documentation? |
|
I find it a bit confusing that the 4 examples have these small differences. Wouldn't it make sense that for each difference there is one way that is better than the other, and the best is used in all examples? A normal reflex here would be do make a common code, and just select board settings somehow. But I see the advantage of having everything compact in one file, especially for a educational example. What path do you see forward for these examples? |
|
yes, you've understood the problems :) common code and a board selector or set of boards is good for demonstrating a peripheral, but quite bad for being an easy to use self contained example. The current repo tried to do both, and has become largely unmaintainable copy pasta. For instance, you've tried to synchronize things, but have actually missed stm32/f1/stm32-h103/usb_iap and stm32/f1/other/usb_hid which also use DFU. The forward path is unclear, but a likely path is a split of two repos. One repo with "peripheral api" examples, with no duplicated code and a limited set of example platforms, much like the current libopencm3/tests/gadget-zero uses shared code for the usb stack. This repo largely doesn't exist. The other repo(s) would be like libopencm3-miniblink, where all/any boards are supported, so you can get an evaluation going quickly, but only a limited set of peripheral apis might be supported, that are available on all boards. This also has the "downside" of not being these single totally contained examples that the current repo has, but it's debateable whether that's actually been a worthwhile goal, given taht no-one should really be building their apps like that anyway. |
|
I didn't miss stm32/f1/stm32-h103/usb_iap though :) The two HID examples are a bit different, but true, they could also need the same documentation update. I guess the original problem that I want to help solving is, if you want to improve a duplicated example, where do you start? If they have been synchronized you can then apply the same change all over. For instance if someone wants to add DFU to their project, it would be nice if libopencm3 would show the best example. But I do understand it is out of your scope to provide reference implementations of everything. BTW, I now found #205, which seems to nicely add UPLOAD support. What should be done to get this in? |
|
Someone said in #119: "The general problem with something like this is that it results in the examples being different. They really need to be more common, not diverging with this cdcacm example being completely different from the others." |
No description provided.