Can we condense the number of options on the boards menu?

[SpenceKonde]

The menu is already getting kinda long, the entries are almost identical, and the DD series is still on the way.... I'm pretty sure it can be shrunk waaaay down.... (and no, I didn't add all those entries manually. Hurray for regex find + replace)

[MCUdude]

Well, I've been very restrictive on adding extra sub menus to my cores, because the list gets so long with a bunch of options I rarely need to touch anyways.

• Do we reeeealy need a total of three submenus just to set BOD? Why not just have one submenu that would be more than enough for 99.9% of the users?
• Is it really necessary to prove a millis/micros timer option? Can't the user just accept that TCB2 is used for this, period? No MegaCoreX user has ever complained about this.
• And the ADC workaround? Why not just always enable this? Is it really that much of a performance hog?

You can't make everyone happy 😉

[SpenceKonde]

• Not a bad point - it seems particularly silly to have a menu for voltage when they aren't even enabled.... Yeah, the number of options in that menu would be looooong, but if the normal options were at the top, that'd be fine. The one thing that makes it more complicated though.... I'll bet there are actually more BOD options, just like how the tinyAVR 0/1 series has a bunch of secret "unqualified" BOD options that microchip pulled from the datasheet and io headers....

Two reasons the time menu is staying: We can't get rid of it entirely, because disable millis option is a key feature. And secondly, there is a VIP user who relies on it. : ME! As for MegaCoreX were I not familiar with your feelings on this menu, I would have complained! Frankly, I don't know how you can get by without it. On the classic parts, Timer0 is very similar across all the AVRs,, and not good enough for most other purposes anyway.

• Good point on the ADC workaround; When I added that, I thought that changing the mux position would throw off the next ADC reading - it doesn't (IIRC on classic AVRs it did - or could - but I couldn't make it do anything weird here) That is also one of the most poorly written errata items I've ever read - it sounded FAR worse than it is! "Workaround: None" - None? What do you call pointing the mux away except when actually making a measurement? When I got the automated reminder that I hadn't responded to a support ticket in almost 2 weeks (well yeah, the last thing they said is that they would let me know when more information became available, 2 weel

I'm going to drop the workaround submenu - if REVID says it's there, it will get the workaround, else not.

What's kind of funny though? I recently had someone complain about the fact that there were no menu options for SUT and the BOD sampling frequency in megaTinyCore! There still aren't

In any event, I actually wasn't talking about submenus - I don't think we need so many menus for different pincounts - why DID I think they needed to be their own item?

[MCUdude]

Two reasons the time menu is staying: We can't get rid of it entirely, because disable millis option is a key feature. And secondly, there is a VIP user who relies on it. : ME! As for MegaCoreX were I not familiar with your feelings on this menu, I would have complained! Frankly, I don't know how you can get by without it. On the classic parts, Timer0 is very similar across all the AVRs,, and not good enough for most other purposes anyway.

I do don't provide it on my classic Arduino core because, as you've pointed out, timer0 is an 8-bit timer and thus limited. If users need a timer for periodic interrupts, they can either use the WDT, timer1, timer2 and even timer3 if their hardware supports it. If it is a problem that timer0 is running in the background, it's very easy to stop it.

Why is it so important to stop millis/micros? And can't you do that by writing to the registers to stop it (or set ut up for a different purpose) rather than having a dedicated menu option for it? All DxCore targets have plenty of timers you can use if that's the problem.

What's kind of funny though? I recently had someone complain about the fact that there were no menu options for SUT and the BOD sampling frequency in megaTinyCore! There still aren't

Edge case. Tell him to use Atmel Studio, MPLABX, or fork your repo.

BTW is there a good reason why you have separate separated with and without bootloader? Why not provide this as a submenu option as I've done with MegaCoreX? And is it necessary to have the option to use the bootloader with and without auto-reset (PF6 as RST instead of GPIO)? Remember that the DA/DB has way more pins that the ATtinys and this scenario is pretty much non-existent, I'm sure.

These would be my rules: Tight on pins? use UPDI. Want to use Optiboot? You'll have to use RX, TX, and the RST line.

[SpenceKonde]

I enable and disable millis often enough during development that the menu is uh... really kinda nice. Do you not routinely do things where you're trying to understand some fiddly timing issue, and want to turn off millis?

I've been looking at the separate board for optiboot and wondering if I should give it the axe too. The Dx-series optiboot vs non-optiboot, and DA vs DB are both sort of teasing me... they're aaaaalmost close enough that I would be like, okay throw them in together... almost.

Of course, on the third hand, EEPROM on the Dx-series is ACADEMIC because it is totally hosed right now!

[SpenceKonde]

I think what I'm going to do.... is change the top level "boards" to AVR DA-series, AVR DB-series, and the optiboot versions of those two (and in the future, AVR DD-series and whatever other letters they put after the D).

Then the chip option will have the 11 options for the different pincounts and memory sizes...

Then the only part-specific caveats I need to include are with the millis timing source for timers that aren't on all parts, and the bootloader UART... am I forgetting something?

[MCUdude]

Do you not routinely do things where you're trying to understand some fiddly timing issue, and want to turn off millis?

Yup, I do. I either stop the timer manually, or simply throw in a cli(). Works every time.

I think what I'm going to do.... is change the top level "boards" to AVR DA-series, AVR DB-series, and the optiboot versions of those two

The problem with this is that some of the lower pin targets only have a few serial ports. You'll end up having several bootloader options that wouldn't work for the lower pin targets.

Wouldn't it be better to sort them based on the pin count? Then all grouped targets have pretty much the same features.

And why would you have separate boards menu options for with and without Optiboot? It's perfectly possible to move the bootloader menu option and get it together with all the other chip options. Look at MegaCoreX, It works perfectly and doesn't feel weird at all. Any good reason why not to do this?

[SpenceKonde]

Yeah - there are two menus with notes next to some options saying 64-pin only, 48/64-pin only... The problem really was that you can't have a value depend on two different menu options.... because available flash for user code depends on whether they're using Optiboot AND what chip they're using....

And the DB-series parts have a menu for the MVIO fuse, which we want to default on since it's like, the headline feature of those parts and in many cases they may be wired up such that they could be damaged if it wasn't turned on, so those have to get a separate group (I try not to have totally meaningless submenus - they bother me more than (64-pin only) and optiboot has I think two menus that only have meaning with optiboot. I also feel that optiboot vs UPDI is a rather different experience/mindset? It certainly seems like there are a lot of users who will prefer to use UPDI only once to bootload, and then use optiboot every time (maybe they don't have a nano dedicated to use as JTAG2UPDI? Heh, I have at least 2 (one of my recent purchases was neon cable braid and UV flashlight so when I lose all my programmers, I can turn out the lights and play the flashlight around my room to locate them), or who would never in a million years use optiboot. People who pick and choose based on the use case seem to be in the minority.

The other big thing was that I wanted to reduce the amount of duplication between them; there is still a significant amount, but we're down to 4 options (and 6 when DD comes out), which appears to, like the tinies, allow reconfiguring UPDI as a GPIO pin (I wonder which pin you apply the HV pulse to in order to turn it back? My guess is the input-only reset, and that that may even be why they made that pin input only - there's this super-time-sensitive PCHV programming method needed for that on the tinies, and I think they want to avoid that mess here.

[MCUdude]

The problem really was that you can't have a value depend on two different menu options.... because available flash for user code depends on whether they're using Optiboot AND what chip they're using....

I don't see the problem with having a dedicated menu option for every target. After all, since IDE 1.8.13 all DxCore targets (and all other cores for that matter) have their own sub-menu) so a long list won't "pollute" the boards menu like it did on older IDE versions. By going for this option you'll IMO get the sleekest tools menu with little or no caveats.

The downside is that the boards.txt file gets incredibly long...

[SpenceKonde]

Well, the issue with the long boards.txt file is... megaTinyCore 2.1 had three emergency fix releases.... every one of them due to an error in one boards.txt entry or another.... Even with just 10 board menu options, it got unmaintainable. So having tons of entries isn't practical until I have a script to generate the boards.txt file for me. At least on ATTinyCore, the different parts have significant differences; each change only needs to be propagated to a few other boards. With the modern AVR parts, there are very few changes that don't apply to all of the boards, or all of the optiboot or non-optiboot boards, or all the DA or DB boards. Hence the current approach of 4 entries, for the 4 combinations of optiboot vs non-optiboot, DA vs DB. Change is in with 1.2.0.