The list of chips that are nominally supposed to be supported by Optiboot seems to be growing quite long; much larger than I'm able to test myself.
I'd like to build a network of people who are willing to test new Optiboot commits, especially on the less common chips and/or under less common circumstances. If you're able to do that, add a comment to this github issue (yes, you'd need to get a github account), along with which chips you'd be able to test, and any special requirements or features that hold particular interest (MCUSR pass-through, write-to-flash, etc.)
Here's a list of chips I'd like to have "covered":
ATmega8
ATmega88, ATmega88p
ATmega168, ATmega168p, ATmega168pb
ATmega328, ATmega328p
ATmega328pb
ATmega1280
ATmega2560
ATmega32, ATmega16
ATmega644p
ATmega1284p (specific implementations thereof including Bobuino, Wildfire, etc)
ATmega16m1, 32m1, 64m1
ATtiny84, 44, 24
ATtiny85
ATtiny1634
ATtiny861
ATtiny87, 167
ATtiny88
ATtiny162
Note that I need people who are in the "I already use that chip" (either without a bootloader, with a non-root branch of optiboot, or with some other bootloader.) "I might be interested in using that chip, sometime, if only the arduino environment supported it better" isn't good enough!
I'd like to see 2561 there too. I have a pins_arduino.h from 2560 that I modified to reflect the fewer ports available.
If there were more hours in a day, I'd volunteer. I have a couple of perfboards wired up with 28 pin and 40 pin ZIF sockets for the 328 family and the 1284 family and other similar 28/40 pin DIPs. Could add a couple of headers to allow power/Gnd to be jumpered to different pins as well.
Would be simple enough to wire one up for the 8-pin DIP components (Attiny 24//44/84 & 25/45/85)
I recently got a 32-TQFP socket, so it'd be easy to wire up a perfboard for those parts, assuming they have same pinouts for power/gnd/crystal as the 328s.
Attiny861 looks similar to Attiny2313/4313?
Some of the other Attiny don't seem to come in DIP or TQFP, would need to get at TSOP or something SMD parallel pin socket.
ATtiny162, doesn't seem to be a valid #.
" ATmega1284p (specific implementations thereof including Bobuino, Wildfire, etc)"
The specific implementations are really just variations in pins_ardiuno.h, no? For software pin-name mapping?
Unless Optiboot has an impact on Mighty-core for selecting crystal speed, BOD, etc.
I just got some new boards, am waiting on stencils, for a '1284P + uSD logger design, I designed it so one could put in 16, 20, 24, maybe even 32 MHz crystals in HC49 package. 16 & 20 MHz are supported, GoForSmoke has sent me info on 24, and I've read that overclocking at 32 MHz works, I'd like to give that a try, maybe those could be added to Optiboot or Mightycore at some point.
(The important thing would be more along the lines of "yes, it still works" after making changes that supposedly don't affect specific platforms. For example, I'd like to change the default definition of RAMSTART from 0x100 to 0x200, so that I won't need the per-chip conditionals for 1280/2560/etc (which don't have RAMSTART defined by io.h, in some versions of the toolchain. Or perhaps to (RAMEND-(SPM_PAGESIZE+STACKSIZE+SAFETY)). But I'm not quite sure that it would work on everything...)
I've signed up for the ones that my core currently supports optiboot on. If there's a version of Optiboot that works on the attiny's without hardware serial, that would be awesome and I should include that in my core and would take up testing them.
ATTiny861 isn't much like the 4313 - it's better thought of as a tiny85 with more pins. 4313 has a normal timer and a UART that the 861 doesn't have. The 861 has the wacky high speed timer and PLL like the 85, and an otherwise normal suite of ATTiny functions. I suspect there's no difference other than pin assignments (and maybe pagesize) between what's needed for 85, 84, 88, and 861. 861 definitely comes in DIP, too - which is pretty nice; most of the exciting tinies are SMD only.
I think an automated testing system could be thrown together - ie, assume a USBAsp is connected, and call the appropriate AVRdude commands on the ASP to write the bootloader, then upload blink through the bootloader, dump the flash over ICSP, upload a test sketch, wait for successful test completion to be reported on serial (or give up waiting) and then dump the contents of flash one final time. Those flash dumps could then be checked for evidence of problems... And the same script could be used with any part, just spec'ing different files to upload...\
Optiboot was supposed to work on the Luminet (ATtiny84-based), which was an Arduino derivative gaining some interest at about the same time that Uno came out (~2010?) So in theory it has bit-banged UART code, and "makes sense" for any tiny with enough flash that throwing away ~1k isn't too painful.
But in truth, I wasn't fully aware that my list of desirable test platforms included a bunch whose current "burn bootloader" command only burns fuses...
I think the effort required to make an automated test system would definitely pay off. I think it would make sense to do a blink in the test sketch to verify that the uploaded code is running. I suspect a >64 kB or >128 kB upload test would be a good idea. There are already the chaucer sketches included in the repository for that.
It would be easy enough to verify correct value of MCUSR after WDT or power on reset but I guess BOD would require lowering the power supply voltage to trigger it. I suppose if the first two are working the BOD should be fine.
Ideally the test system would work on any OS but having any system at all would be better than none. I usually use Windows but I could do Linux if that was required.
If not an automated system at least we should have a description of the process the testers should follow.
It seems like now that we have people committed to ATmega328PB and ATmega64M1 the testing coverage is reasonably good. What do you see as the next step to move this forward westfw? It sounds like there is some interest from people to submit pull requests for the changes they have made in their forks but maybe it would be better to deal with the high-priority existing pull requests (MCUSR, flash write, ATmega2560) first.