Change of plans: Interim ATTinyCore, then The Big One

[SpenceKonde]

Okay, looking at how things are going made it clear that a different approach is needed. So my plan now is to:

• Make a release with current master, and the new upload tool binaries.
• That should significantly improve the UX here, and has low cost and can be done quickly.

And then, continue with the ongoing initiatives for the next major release. It is looking increasingly like this release will be a 2.0.0, as I think there is a bandaid that needs to be ripped off in the bootloader department, and a few other places.

• Optiboot gets fix for the softbrick bug.
• Optiboot baud rates w/hardware UART changed to account for which baud rates different clock speeds are capable of doing reliably, keeping an eye on impact of oscillator accuracy (additive effects of oscillator error and baud rate error are responsible for most problems experienced with optiboot uploads)
• Optiboot baud rates w/out hardware UART changed with objective of making it work well, not punishing people for using a software serial port; I do not think that the baud rates were set with a charitable attitude towards users of bootloader on parts without hardware UART. Either they were done with that bad attitude, or I was stupider than I thought back then. (not ruling out the possibility that both are contributing factors!)
• The "tinymodern" core will be flushed, everything will be done with variants
• New rationalized 1634 pinout. (what was I thinking?)
• flexible pwm on t828, and control pwm via the OE bits for the mux on 828 and 841 so if people change the mux settings, digitalWrites don't break their manually controlled timers outputting on different pins. (done - but untested and not backportable)
• Clean up all variant files (turns out this is not optional anyway for the core combining)
• support setting turning constants (done, but not tested or backportable), provide for tuning sketch with timebase of either UART or stream of 1ms pulses (mostly done - I saved a lot of time by halfassing it ("good enough is")
• Tuning constants will be saved at end of bootloader section if bootloader in use. Otherwise, at end of EEPROM.
• New micronucleus bootloader binaries for a variety of entry conditions on supported parts, add support for 861 and 1634.

[nerdralph]

Have you tried picoboot-lib yet?
https://github.com/nerdralph/picoboot-lib

It's got auto tuning that gets saved the first time the bootloader runs, and is used to init OSCCAL on reset before jumping to the user code. It also exposes pb_txbyte() and pb_rxbyte() functions so user code can call the bootloader's bit-bang serial routines.

[SpenceKonde]

I have not had a chance to try it; in any event it doesn't get us a replacement for optiboot (and the fact that it's assembly makes it difficult for me to maintain if needed) since you're not planning to support all parts) - I am planning to do that once I have the core put back together with all boards compiling and a rebuilt boards.txt, and I can start thinking about what the bootloader space will look like.

My current tuning solution involves a dedicated tuning sketch which could be uploaded alongside Optiboot; (tunes from certain charachter sent at a certain baud rate, or a 500 Hz squarewave; I'll include a tweaked version of ArduinoISP that will, after uploading, test for whether it's waiting for cal, and if so, cal it via squarewave; I'll use SPI pins for it so nothing would need to be connected or disconnected); The tuning sketch will go through the entire 0~255 range, and record the best settings for 2 or more target clock speeds (depending on board, eg, t85/861 get 8/16 and 8.25/16.5, most tinies get 8 and 12, the 841 gets 8, 12, and 16, and there's support for "user cal" of an arbitrary frequency if they really want that), and saves it before the version word in the flash (if it has a recognized bootloader) that isn't calibrated) or at the end of the EEPROM (if no bootloader) or repeatedly blinks unhappily and prints an error message if there's either an unrecognized bootloader, or if there's no bootloader and EESAVE is not set (meaning there is no way to persist the settings)..And if it's already calibrate, it would instead print a message to that effect. And some statistics for fun, of course - speed measured at OSCCAL=0, at OSCCAL=255, what factory cal was and what speed that came out to, and what the two tuned OSCCALs are and what speed they were measured at... (the question ofc is whether it is worth having it do more than that - there's the temptabion on the one hand to have it, say, save the delta at each step... and print those out (if tuned over serial, the serial turner program could also read that in, do the math on it, and print out the coefficients (on tinyAVR 0/1-series, the frequency is very closely approximated by f=ax^2 + bx + c, ex the 16 MHz osc on one of my 1614's is: f = 0.00032x^2 + 0.233x + 9.7335 in MHz - I suspect the same is true here). Now what would be really interesting would be to take samples across a wide range of voltages... so you could predict how the curve would change as V changed. Do the same for temperature. as well. If you could generalize between specimens (which one probably can to some extent) you could even say someything like "Well, at 5v and 25C I'm on target with OSCCAL of 75. But my on-board temperature sensor (which we cal'ed at the same time as the osc) indicates that I'm shivering down at around -20C, which explains why my three alkaline batteries are struggling to give me 3.4v, so i'd be closer to the target frequency if I cranked my OSCCAL iup/down by this many LSB...

I think i have all the pins_arduino.h files modernized now, and have converted the 841 to use variants instead of the idiotic way the second core used to do it;
828, 1634 need same treatment, then digitalWrite and pinMode need to get PUE support added and I need to make sure the basics work. I am expecting to be working over the boards.txt this weekend to get a usable base for development.

Then the new micronucleus builds for the new parts need to happen.

By then Im hoping y'all will have figured out which USB libraries approximate working, and which are basket cases, so I can include the working ones, and not include the non-working ones.

Need to figure out how to make the USB libraries get the pin information from a central location - this thing with a separate file for each library is a thousand flavors of fail, it is not acceptable or sustainable.

Why can't I have a pins_usb.h in each variant? Wouldn't that work? And I could even #include it when pins_arduino.h is processed if it's set to a mode with USB support so the sketch could see defines for what pin is used and stuff.....

[nerdralph]

OK, I didn't realize you want a bootloader that works on every MCU supported by ATTinyCore.

For the tuner it sounds like you've done a lot of work to come up with something that works on many different AVRs at many different speeds. I try to have a single version of code without #ifdefs so that it is easy to maintain and debug. That often means leaving out support for parts that are significantly different than others.

I've never liked the way Arduino does pin abstractions, and more than once when working on variant/pin definitions have gotten frustrated enough that I've had to leave the code and work on something else for a while.

[SpenceKonde]

Currently all parts that come in a version with at least 8k of flash have a bootloader binary for the 4k and larger sizes with references to same within boards.txt;

So if I were to replace optiboot with picoboot, I'd need to be able to do it on all of those parts - otherwise it can at best be a "bonus" for people with certain parts (and, as it happens, parts that are pretty mediocre.)

(I digress somewhat, but...) The 84 is an 841, only worse in almost every way except that it has hardware that can allow a slightly less lousy implementation of I2C master. and like, the 85 is only notable because the 8-pin parts are the red-haired-stepchildren of the AVR line - they haven't even refreshed the '85 line with the better oscillator like the 84, 861, etc got wgen the 84a/861a came out. If Amel/Microchip had more respect for 8-pin parts, and had released anything interesting in 8-pin packages in the past decade, we wouldn't be talking about the 85 constantly! The fact that they didn't give us an ATtiny812 was a real slap in the face. (especially since on of the few downsides of the new architecture is that, all else bring equal, code will be slightly larger there, because none of the peripheral registers (other than vports) are in the IO space.). If there was an 812, I guarantee you, that would be the internet's favorite 1-series tiny! Just like the 85 is the favorite classic tiny.. And, no 2-series 8-pin parts either. Is 8-pin AVR dead?

[nerdralph]

Doing versions for the t45, t44, and t48 wouldn't be a problem.
I know you like the 841, and from looking at the datasheet I see it has a lot of nice features. But if I were to do a bootloader version for the 841, I'd do it with one of the hardware USARTs instead of the bit-banged UART. That makes me wonder if it wouldn't be better to make it a variant of the mega version of picoboot, as that (256-byte) uses the hardware USART.

I think parts like the t84a are more popular than what you see from your tindie store because they are available in DIP. I just looked at Newark and they're 116c each. Although for you and I it's no problem soldering a SOIC to a breakout board. For the newbies they can take the DIP AVR, and plug it and an Arduino Nano into a breadboard for prototyping.

And since we are digressing a bit, :-), I think the older AVR parts like the m328p, the t84 and the t85 are still popular because there's a very large collection of open-source code written for them. A bit of it has been ported to newer parts like the 841, but most of it hasn't. I think it was stupid of Atmel to introduce newer AVR parts that were often cheaper and better, but never backwards compatible with the older parts. So even though the 841 has the same pinout as the 84, code has to be ported. And if your t84 code uses USI, that's going to be a big job.

Now many of the hackers that did cool things with the 8-bit AVRs have moved on to more powerful (and often cheaper) ARM Cortex-M parts. And once you start writing firmware for most ARM parts, it's hard to go back to the 8-bit AVRs. Vendors like ST have a very consistent set of peripheral register definition, instead of the monkeys and dart board method Atmel seems to have used. And all ARM Cortex-M parts regardless of manufacturer have things in common beyond the Thumb2 instruction set. For example, the stack is always initialized on reset with the value at address 0, and the reset vector is address 4. There's a basic set of interrupt vectors all parts share that includes some exception vectors and the systick timer interrupt vector. And every low-end ARM MCU has a 2-wire SWD interface for debug and programming. For someone like you that uses so many different AVR parts, it must drive you crazy needing multiple programmers for the 8-bit AVR line.

As an example of how the old t85 is still popular, I noticed the Arduboy uses it in the FX Mod chip.
https://arduboy.com/store/arduboy-fx-mod-chip/
Looking at the specs, you'd think something like the ATtiny 402 would be a better choice. It's got hardware USART, SPI, TWI, and CCL, and sells for about 40% of the cost of a t45 or t85.