I dunno... I have like a 50% success rate between DFU, UF2, and whatever the Arduino IDE does (varies by chip). Meanwhile, SWD/JTAG works for me 100% of the time, and is faster. I wouldn't use anything else.
The downside is that it requires $6 in hardware (or $20 if you splurge on a J-LINK EDU) and so I guess it takes quite a few encounters with "60 seconds of poking around at reset buttons frantically for what should have been a 1 second operation" before that $6 is worth it. GDB on your microcontroller code is also occasionally useful. I think hobbyists should just give up on stuff designed to "make it easy" (but only works half the time) and use the tools that people use for their day jobs, especially when it's only a few dollars investment.
With all these UF2 first boards the first thing I do is solder on the SWD header and figure out what magic sequence of memory read/writes I need to make over jlink to unlock the flash and remove the damn bootloader.
Sometimes I wonder if anyone actually uses a debugger anymore :(
My experience as a hobbyist with an STM32F401CE dev board echoes "DFU doesn't work reliably". For some reason the success rate of getting the integrated DFU bootloader to work varied for the exact same board with different computers. But, given that flashing over SWD worked all the time, it's just easier to use that.
Micropython supported writing python programs as plaintext files to the flash-drive on the device. This was super convenient for hobbyist prototyping.
Yup, exactly. I don't know how they made it so flaky, but it's flaky every single time. (To some extent, I think it's bootloader-related issues; not a hardware or protocol problem, but a quirk of the bootloaders floating around.)
Once you get Micropython or Circuit Python loaded, it is pretty great. I think if I were teaching someone programming for the first time, that's the platform I'd use. (But every time I try, they say they want to learn React, try doing so for a week, and then give up on programming for good. You've gotta crawl before you can walk!)
Can second this. Having JTAG/SWD access is so much better than any of these ad-hoc stuff combined. When even SWD doesn't work, you know with certainty that your board/chip is in deep trouble anyway. Also for most of Cortex-M you buy the dongle only once.
For the small connector you may need to buy something for a few dollars, and for the big one you almost certainly already have everything on your desk. The small one is smaller, and despite the picture you can also put it in the middle of your board - just make sure to keep taller components our of the yellow area.
There's also the poor man's version of this where you pull your debugging symbols out to a card edge. Have done that on several design and it worked well. You get to play with what you want on the connector for the design typically, so have thrown ethernet MII on there in addition JTAG and UART.
I'm firmly in the "why not both?" camp: scrappy, low-barrier-to-entry UF2 et al for a simple on-ramp that gets people hooked with a single purchase (like a microbit a kid gets given, or someone's Christmas present that they might not have had any input into), then graduating to better tools as it becomes clear that the time investment is worthwhile.
That's the main cost here, it's not the purchase price that matters. It's the uncertainty of "have I bought the right thing? Will it work with tools I already know how to use, or am I going to need to learn a whole bunch more stuff? Do I need to figure out a new docs ecosystem?" and all that jazz.
There's one point I'm unsure of, though, and that's how to make it clear that when people see failures with the simple-onramp system, that those failures would be fixed by moving to different tooling, and not just replaced with new problems to occupy one's brain with.
That's fair. To me, the reliability exploits the hobbyist's inexperience; they don't know how short a edit/test cycle should be, so they aren't upset by how long it is. "Hardware is hard," they're told.
As other comments mention, the real innovation is not making them flash firmware at all -- things like Circuit Python have worked very well for me, and you can point your editor at a Python file right on the device itself and it starts running from the top when you save. That is probably the ideal situation; nevermind how inefficient it is compared to C++ (people can learn C++ once they understand the basics of programming; no need to start there).
I'll also point out that Amazon has STM32 kits; $18 gets you 2 STM32F103s and a programmer. I have used those and they are probably my favorite microcontroller platform and the price sure is good. There is no doubt about which programmer to use because it's in the box, and the programmer is so cheap that buying one (and a backup microcontroller) is cheaper than most hobbyist MCU boards. ("Made in Italy" ends up being quite a bit pricier than "made in China probably from a grey-market chip".)
The downside is that it requires $6 in hardware (or $20 if you splurge on a J-LINK EDU) and so I guess it takes quite a few encounters with "60 seconds of poking around at reset buttons frantically for what should have been a 1 second operation" before that $6 is worth it. GDB on your microcontroller code is also occasionally useful. I think hobbyists should just give up on stuff designed to "make it easy" (but only works half the time) and use the tools that people use for their day jobs, especially when it's only a few dollars investment.