Bad Atmel Behaviour

[Muirium]

An annoying barrier to entry for new users is QMK Toolbox's behaviour with Atmel chips. I know unlike other MCUs they must be selected manually, but this is quite a typical event when dealing with IBM Model F controllers:

Note:

• QMK Toolbox correctly identifies the device as 32u2
• But tries to flash it as a 32u4 because that's the default value in the non-obvious MCU pulldown menu up at the top right
• QMK Toolbox reports the error and gives up

The user is left baffled.

May I suggest two ideas:

• If the MCU identifies itself, as this one did—I believe most or perhaps all Xwhatsit-based 32u2 controllers include the text 32u2 in this string—try flashing as that MCU
• Exhaustively try the various Atmel MCUs in the pulldown, until one works, as an "Auto" mode which should be the default; unless overridden manually by an advanced user

Sure, a failure like the screenshot above is no surprise to an experienced user, but it's a poor experience and in this common case an easily avoided failure.

[Muirium]

Another idea:

• When QMK Toolbox determines it's flashing an AVR: prompt the user to select the MCU.

I've run QMK Toolbox to flash keyboard controllers and converters about a hundred times, myself. I really like the app, and recommend it to everyone over the dfu-programmer commandline utility / HID listen we had to use before. Every single use of mine was an AVR: a mix of 32u2 and 32u4. So I don't actually know what QMK Toolbox is like when it doesn't rely on that little menu! 8-bit AVR stuff is where most vintage keyboard work is done, like Pandrew's capacitative sensing QMK port in this example. Many of us are still flashing AVR.

[Muirium]

Here's another pair of Atmel MCUs which QMK Toolbox ID's correctly: 32u4 in this case.

That's my pair of Hasu's TMK powered HHKBs. The controllers look like this:

I’m going through all my QMK Toolbox compatible keyboards at the moment, anyway, so let's see if any of them don't report their MCU.

[tzarc]

I'd say your best bet at this point is to make a PR -- I'd imagine most of the team would view this as low priority as it's a nice-to-have rather than a necessity, and there are lots of other things in flight, mostly on qmk_firmware.

I agree that it'd simplify the workflow -- I'm sure there's even a way to get avrdude and the like to query which chip is present, given the ID field.

[fauxpark]

I already have some thoughts on how to improve detection. In terms of Atmel DFU, this is much easier (and actually feasible, for Windows reasons) than parsing the device name - the USB PID directly corresponds to the MCU. For certain other bootloaders, we can reasonably assume a particular MCU (Caterina is basically always 32U4). Everything else will require you either know what you're doing, or will not need an MCU input at all.

The other problem is that multiple bootloaders can be connected at once, to allow for flashing en masse, and the MCU dropdown will apply to all of them, so we cannot just lock it to a particular value unless all of the bootloaders are the same. Most likely I will simply rip this functionality out since most of the flashing tools assume only one device is connected anyway, and of the ones that don't, getting the Toolbox to automatically identify a specific device is more trouble than it's worth.

[Muirium]

Any time I've had the wrong MCU selected in the drop down menu, the firmware has refused to flash anyway. I've never corrupted a keyboard or converter with the wrong selection.

Wouldn't an automatic try-fail, try-fail, try-succeed through the MCU list work? They're very quick to fail, and I could see this working well even for a mass flashing scenario.

[fauxpark]

Any time I've had the wrong MCU selected in the drop down menu, the firmware has refused to flash anyway.

And this is part of what confuses users.

Wouldn't an automatic try-fail, try-fail, try-succeed through the MCU list work?

It would work, yes, but if you can't see why that's a gross solution I don't know what to tell you.

[Muirium]

Gross is better than downright failing. ;)

I get slapped by that mistake quite often enough myself—ohhh… this board isn't 32u4!—and I know exactly how to fix it. The experience for everyone new at this is as cryptic as running dfu-programmer directly and pasting their resulting errors on a forum. Clean perhaps but awful.