Closed aster94 closed 6 years ago
SpenceKonde
commented
7 years ago Differences are considerable due to the lack of hardware serial. Can someone convince me that offering a necessarily bloated bootloader that uses software serial is a good use of resources, ie, that it will offer a decent value for the users?
sleemanj
commented
7 years ago For reference it requires 582 bytes (or at least that's what I reserve for it in my fork which does support the x4 for bootloading).
https://github.com/sleemanj/optiboot/blob/master/optiboot/bootloaders/optiboot/Makefile.attinyx4
aster94
commented
7 years ago I will try it! Anyway if sleemanj is ok with this maybe dr Azzy could add the support using your code and referring to your repo
I am just saying i don t know if it could be a problem for any
SpenceKonde
commented
7 years ago If this goes into the core:
I will not have any time to devote to development or test of this in the near future, as there are far more pressing concerns - #116 is the only outstanding issue that will be addressed by me for the next version, beyond a bit more testing of the I2C stuff - of course, as always I would welcome pull requests to add this stuff in (just not for 1.1.3, which I want to get out the door ASAP). I think documentation is probably the bigger hurdle than just making Optiboot work - as I noted above, a new feature that produces shitloads of support inquiries due to inadequate documentation or reliability issues is the last thing I need.
SpenceKonde
commented
7 years ago Also - I do not feel that a bootloader for the smaller versions of the x4, x5, x61 series makes sense for the user. The 4k chips are already extremely cramped for space when used with the Arduino IDE; the 2k ones are out of the question. Anyone care to convince me otherwise, go ahead.
aster94
commented
7 years ago Ok i understand, never mind
anyway (maybe there is a reason but i m not aware of it) i would suggest you to move the choosing of the bootloader to a menu entry after the user already choose the mcu
If i am not been enough clear i would suggest you to have a look to the stm32duino repo: There you select the mcu, than you choose the upload method and type of bootloader
SpenceKonde
commented
6 years ago I don't think it's possible to make a submenu selection change the available options on another submenu - this would be a better way if it were possible, but I don't think it is.
cellularmitosis
commented
6 years ago Hello,
First, thanks so much for working on this! Lots of great improvements recently.
After some sleuthing I have figured out how to enable the unsupported bootloader for the attiny85. However, it appears to get stuck in a loop. It looks like it was meant to run TinyTuner once on the first boot, but it appears to run it on every boot:
Entering Tiny Tuner
Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...
Current Calibration = N
Lets see if we can do better
Current Cal = E
Current Cal = H
Current Cal = I
Current Cal = H
Current Cal = H
Current Cal = G
Current Cal = G
Current Cal = G
Current Cal = I
Current Cal = I
Current Cal = G
Final Cal = G
Saving Calibration to Program Memory...
Removing call to TinyTuner to reduce bootloader size by 2.3kbytes
Calibration saved and TinyTuner Deleted
Enabling Bootloader and Rebooting
Entering Tiny Tuner
Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...
Current Calibration = G
Lets see if we can do better
Current Cal = H
Current Cal = I
Current Cal = H
Current Cal = H
Current Cal = G
Current Cal = G
Current Cal = G
Current Cal = I
Current Cal = I
Current Cal = G
Final Cal = G
Saving Calibration to Program Memory...
Removing call to TinyTuner to reduce bootloader size by 2.3kbytes
Calibration saved and TinyTuner Deleted
Enabling Bootloader and Rebooting
Entering Tiny Tuner
Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...
Current Calibration = G
Lets see if we can do better
Current Cal = H
Current Cal = I
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = G
Current Cal = G
Current Cal = G
Current Cal = I
Current Cal = I
Current Cal = G
Final Cal = G
Saving Calibration to Program Memory...
Removing call to TinyTuner to reduce bootloader size by 2.3kbytes
Calibration saved and TinyTuner Deleted
Enabling Bootloader and Rebooting
Entering Tiny Tuner
Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...
Current Calibration = G
Lets see if we can do better
and so on.
It appears it is not successfully deleting TinyTuner. Does anything come to mind which might prevent the bootloader from deleting TinyTuner? Perhaps some fuse bit is not set correctly?
Also, I'm not sure I understand the argument of not offering a bootloader for e.g. attiny85. If you offer the bootloader, people who need it can use it, and people who think it requires too much space will continue to ignore it. Maybe I don't understand the situation, but it seems like offering the bootloader has no down-side at all.
In fact, I would argue quite the opposite -- disabling the booloader represents anti-value to the user. It took me several evenings of "internet research" just to figure out how to re-enable the unsupported bootloader. It was very confusing and frustrating to have an option in the IDE labelled "Burn Bootloader", but it actually uploaded "empty.hex", which appears to do nothing at all.
If you need some help with testing out support for the x5 chips, I'd be happy to lend a hand!
Thanks, Jason
cellularmitosis
commented
6 years ago I compiled a bunch of bootloaders for the attinyx5 series using the @sleemanj fork of optiboot linked in his comment above.
hex files here:
https://github.com/cellularmitosis/attiny85-bootloaders
It looks like the bootloader is working (it reads the hex file over serial), but I'm getting a checksum error when the IDE reads the hex back from the bootloader:
avrdude: Device signature = 0x1e930b (probably t85)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex"
avrdude: writing flash (1340 bytes):
Writing | ################################################## | 100% 0.87s
avrdude: 1340 bytes of flash written
avrdude: verifying flash memory against /var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex:
avrdude: load data flash data from input file /var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex:
avrdude: input file /var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex contains 1340 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.84s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0002
0xff != 0x33
avrdude: verification error; content mismatch
avrdude done. Thank you.It looks like it is happening very early on (byte 2?), so something fundamental might be wrong.
Which programmer protocol does the optiboot bootloader use? arduino?
cellularmitosis
commented
6 years ago I got it to work!
It turns out the fused were wrong in boards.txt. Specifically, the extended fuses prevented the attiny from being able to write to flash, so it was never able to write the hex file which was sent to it.
Changing the extended fuses from 0xFF to 0xFE in boards.txt fixes the issue:
attinyx5.bootloader.extended_fuses=0xFEI'll submit a pull request shortly.
SpenceKonde
commented
6 years ago Looks like you haven't adjusted the fuses to permit self programming? LSB in the EFuse needs to be set to 0 to use self programming (ie, a bootloader)
The bootloaders for these parts predate my work on this project, and last time I tried I was unable to figure out how to make them work. They were pulled from the core at that time, since they were a low priority. It seems that you have gotten further than I ever did. Leaving code that I know or expect to not work is unprofessional and would result in support inquiries from people who expect it to work (I field a lot of support inquiries that are not publically viewable) - that is why I had no choice but to remove the old bootloaders.
I am pretty sure that there is a bug in the virtualboot implementation, at least the one in bootloaders-unsupported. Symptom of this would be a successful write (possible failed validation, possibly not), but either the application not starting, or the bootloader never running again, or both - flash contents would need to be dumped via ISP and examined after a write, with particular attention to the interrupt vectors (virtualboot is used to provide bootloader functionality on parts without a BOOTRST fuse - it works by rewriting the reset and wdt interrupt vectors while the flash is being written and read).
Re: "Burn Bootloader" - like the default arduino core "Burn Bootloader" means to write fuses, and write any bootloader to the flash. I would love it if I could change this to read "Write Fuses" on parts that didn't have a bootloader or where a bootloader was not selected. But there unfortunately does not appear to be any way to change what it displays.
The empty hex file (which isn't quite empty - it's got 2 bytes in it, because avrdude will reject the command if you pass it a truly empty hex file) is a workaround; the issue is how to support parts with and without a bootloader with the same recipes in platform.txt . I have an idea of how to get rid of the empty hex files, but 1.1.5 release is a much higher priority currently.
If you'd like to take on this project, I'd appreciate the contribution. I am still convinced it would require a separate board def (for x4, x5, x61, and x8 - the boards that don't have a hardware serial port) , and it would need to handle all the reasonable clock rates, and include tinytuner when the board is set to use internal oscillator. We would also need to document use of tinytuner.
cellularmitosis
commented
6 years ago Sure, I'd love to lend a hand for the attiny's. I can at least support the x5 and x4's.
Sorry for giving you a hard time about empty.hex -- I didn't realize the complications with the IDE there.
cellularmitosis
commented
6 years ago Hello,
I reverted my Arduino installation back to the stock ATTinyCore 1.1.4, then edited boards.txt, changing the attiny85 entry to use optiboot_unsupported/optiboot_attiny85.hex, and changed the extended_fuses to 0xFE, and I have verified that it worked. It runs TinyTuner once, then erases itself. Fantastic! The bootloader then operates as expected at 19200.
SpenceKonde
commented
6 years ago Woah; great news! And you can load code onto it more than once?
cellularmitosis
commented
6 years ago Yup! I just loaded 2 more programs.
pepasflo
commented
6 years ago Looking deeper into this, I'm realizing that @sleemanj has really done a lot of work on supporting the attiny's. I'm not sure if I should focus on continuing to test the existing unsupported bootloaders (and seeing if a simple extended_fuse fix will make the rest of them work as well), or if I should focus on trying to get sleemanj's fork merged in here.
Maybe a first step would be to find out how small the existing unsupported bootloaders become after they run and purge TinyTuner, and compare that to how small sleemanj's bootloaders are (which I believe do no include a TinyTune).
SpenceKonde
commented
6 years ago Huh - I didn't realize he has been working on this. Maybe we should try to rope him into this too; maybe try to gather for a discussion of interested parties on gitter or some other real-time chat platform to discuss this?
We need to include the tuner IMO - most people want to use the internal oscillator on attinys, particularly on the x5 and x61 where people are going to want to use the PLL clock option.
sleemanj
commented
6 years ago It's true that my optiboot do not support tinytuner, for a couple of reasons
To just see the changes I did to optiboot (which really wasn't much in the scheme of things) https://github.com/sleemanj/optiboot/commits/master/optiboot
I have not merged in changes from @SpenceKonde ATTinyCore into my fork ( https://github.com/sleemanj/ATTinyCore ) for a few months, I should really get around to that. Note that for, reasons, I don't use my ATTinyCore as a distribution so it's boards.txt etc isn't necessarily tested, I use some packaging scripts which assembles parts of my ATTInyCore, optiboot, and various other things into the distribution which lives here https://github.com/sleemanj/optiboot/tree/master/dists
SpenceKonde
commented
6 years ago IMO nuking tinytuner is correct behavior - once the tuning constant is set, if you need to tune it again, you have changed the operating conditions, so man up and burn the bootloader again. A tuner sketch takes too much space to leave after tuning the chip. IMO, without tinytuner, it's not worth making a tinyx5 bootloader - nobody uses a crystal with the t85, and without the crystal, it's a die-roll whether your chip will be able to do serial without tuning.
I haven't touched the bootloaders in ages - but you're starting from a codebase that parted ways with the one that became this one years ago.
Anyone interested in trying to plan a time to all get on gitter or something and talk about this? Or is that just me?
sleemanj
commented
6 years ago IMO, without tinytuner, it's not worth
You are probably right that tuning is a necessity (through fortune more than planning I have never actually had a problem with it except for bit-banging serial on the t13), I just think it leads to a lot of complexity in the bootloader.
Which makes me think, if a standalone tinytuner were compiled which could write it's cal value and a "set" flag to some known flash address (ie the two bytes immediately before the 2 version bytes as is presently the case in optiboot_unsupported) that the optiboot can pickup, then that tinytuner and optiboot were merged ( in the style of ...with_bootloader.hex style ) and that used as the bootloader, then you'd have the best of both worlds, you could tune it on the "first boot" after bootloading, and then when you uploaded your next sketch the tuner goes away just like any other upload would, and the complexity added to optiboot is just reading those two bytes and setting OSCCAL from one of them if required.
Further, you could try and do an upload (immediately after bootloading) and if it worked, great, no need to tune and the tuner is gone, if it didn't, no problem it wouldn't have managed to write anything so tinytuner should still be there, just do the tuning routine and then good to go.
It seems so obvious that it makes me wonder why it wasn't done like this. Perhaps there is an issue with fitting a discrete tinytuner into the available space after a discrete optiboot is burnt. But I can't really imagine that would be the case.
gitter or something
ticket/email works better for me
Anyway, you are always welcome to cherry-pick stuff from my AtinyCore, or Optiboot forks as desired.
cellularmitosis
commented
6 years ago Great to see this discussion going.
James, your idea makes a lot of sense to me.
I need to learn more of what’s possible with boards.txt. It would be great if there were a “boot loader” menu with “just fuses”, “boot loader” and “with tuner” as options.
Sent from my iPhone
On Mar 2, 2018, at 9:38 PM, James Sleeman notifications@github.com wrote:
IMO, without tinytuner, it's not worth
You are probably right that tuning is a necessity (through fortune more than planning I have never actually had a problem with it except for bit-banging serial on the t13), I just think it leads to a lot of complexity in the bootloader.
Which makes me think, if a standalone tinytuner were compiled which could write it's cal value and a "set" flag to some known flash address (ie the two bytes immediately before the 2 version bytes as is presently the case in optiboot_unsupported) that the optiboot can pickup, then that tinytuner and optiboot were merged ( in the style of ...with_bootloader.hex style ) and that used as the bootloader, then you'd have the best of both worlds, you could tune it on the "first boot" after bootloading, and then when you uploaded your next sketch the tuner goes away just like any other upload would, and the complexity added to optiboot is just reading those two bytes and setting OSCCAL from one of them if required.
Further, you could try and do an upload (immediately after bootloading) and if it worked, great, no need to tune and the tuner is gone, if it didn't, no problem it wouldn't have managed to write anything so tinytuner should still be there, just do the tuning routine and then good to go.
It seems so obvious that it makes me wonder why it wasn't done like this. Perhaps there is an issue with fitting a discrete tinytuner into the available space after a discrete optiboot is burnt. But I can't really imagine that would be the case.
gitter or something
ticket/email works better for me
Anyway, you are always welcome to cherry-pick stuff from my AtinyCore, or Optiboot forks as desired.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
sleemanj
commented
6 years ago I found that @matthijskooijman had previously submitted a pull request ( https://github.com/Optiboot/optiboot/pull/183 ) to Optiboot:optiboot for the ability to set the osccal in flash (originally eeprom), since it looked like it would be a pretty clean merge with my modest optiboot changes I've gone ahead and merged in the current Optiboot:optiboot changes and those matthijskooijman:optiboot changes into https://github.com/sleemanj/optiboot/tree/tinytuner and just done a compile test to see how things looked for size increase...
Building attiny24 with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)
Building attiny24a with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)
Building attiny25 with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)
Building attiny44 with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)
Building attiny44a with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)
Building attiny45 with CPU 8000000L and 57600 BAUD ... OK, SIZE: 577 (was 564)
Building attiny84 with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)
Building attiny84a with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)
Building attiny85 with CPU 8000000L and 57600 BAUD ... OK, SIZE: 579 (was 566)The was figures are what it is without the osccal code. Note that this is with LED flashing off as I don't use that in my builds. Interesting the 45 is a couple bytes smaller than the others, no idea why. These are all untested, just compiled.
The cal value is stored in a single byte, immediately prior the two version bytes, a value of 255 is "don't set", anything else is set. A quick check of the TinyX5 datasheet indicates this is OK as the cal value is only apparently valid for 0..127, I'd guess other AVRs are the same probably.
So to be clear that's just for optiboot, it would be necessary to make tinytuner standalone (or get one that already is) have it push the cal value into the flash at that location (3 bytes down from the end of the flash space), compile it for each target and then concatenate the hex's and use the result as the "bootloader hex".
NB: I don't know why the optiboot version is put at the end of the flash space in a known location in the first place, I can't think of any particular reason it must be unless maybe somebody wanted to identify a compiled version from a hex file or something. If it wasn't I'd have put the cal byte as the last byte of flash and just had the version bytes wherever the compiler wants to put them like any other values.
sleemanj
commented
6 years ago I need to learn more of what’s possible with boards.txt. It would be great if there were a “boot loader” menu with “just fuses”, “boot loader” and “with tuner” as options.
You can see how i handle that here... https://github.com/sleemanj/optiboot/blob/master/dists/diy_attiny/avr/boards.txt#L118
Making different bootloaders available would be trivial by adding more entries
attiny25_diy.menu.boot.optiboot_tuner=Tunable Optiboot
attiny25_diy.menu.boot.optiboot_tuner.upload.protocol=arduino
attiny25_diy.menu.boot.optiboot_tuner.upload.maximum_size=1456
attiny25_diy.menu.boot.optiboot_tuner.bootloader.extended_fuses=0xFE
attiny25_diy.menu.boot.optiboot_tuner.bootloader.file=tunable_optiboot_{build.mcu}_{build.f_cpu}_{upload.speed}.hexAnd the "just fuses" you mention is what I call "No (ISP Programmer Upload)". Note that it uses a different "bootloader.tool" which does not try uploading the non-existent bootloader ( https://github.com/sleemanj/optiboot/blob/master/dists/diy_attiny/avr/platform.local.txt#L67 ) but the fuses should still get set if you do a "Burn Bootloader" with that option selected.
(note that ATTinycore doesn't structure it's boards.txt like this - this is how I do it in my distribution)
sleemanj
commented
6 years ago Ok so I have been fiddling about with that idea and have I believe managed to get it working, I have only done the most cursory of tests using a Tiny85, I havn't even actually verified that it affects the cal, I need to get some freezer spray or something to push the oscillator around a bit as the factory cal works for me anyway.
So in a branch of my optiboot, here https://github.com/sleemanj/optiboot/tree/tinytuner I have merged the current optiboot stuff, plus @matthijskooijman pull request ( https://github.com/Optiboot/optiboot/pull/183 ), plus @aweatherguy pull request ( https://github.com/Optiboot/optiboot/pull/218 ), and then I took tinyTuner.c and made it stand-alone and set it up to be able to combine the compiled tinytuner (hex) and a compiled optiboot (hex), just as they would be if they were any other sketch uploaded using optiboot.
This merging of the two hex files requires a bit of a fiddle rewrite the reset vector and poke it into the appropriate vector for optiboot's virtual boot so a tool was written to do that (pretty rough but it works for at least these small tinys).
Long story short, if you want to compile yourself (on a suitably equipped linux-type box with bash and grep and make and such)...
git clone https://github.com/sleemanj/optiboot.git
cd optiboot
git checkout tinytuner
cd optiboot/optiboot/bootloaders/optiboot
USINGMAKEFILES=Makefile.attinyx5 ./makeall
avrdude -c usbasp -p t85 -U flash:w:tunable_attiny85_8000000L_57600.hexI've attached that tiny85 example hex also
tunable_attiny85_8000000L_57600.zip
Notice that 57600 is the baud rate for uploading via the bootloader, for tuning it's fixed at 9600.
Essentially burning this as the bootloader (as the avrdude command line above does) means that if your oscillator is factory-ok, you can just upload straight away and the tinytuner will be nuked like any other previously uploaded sketch, while if your oscillator is screwey you can open a terminal (serial monitor) at 9600 and send x's to tune it in, you can pretty much just send a stream of x's, the tinytuner will sync up and then reboot (since there's no other sketch the bootloader will load tinytuner again, which is fine).
Currently the combined optiboot+tinytuner hex weighs in at about 2.5kB (once the tuner is nuked via an upload it drops of course to that 570 odd bytes for optiboot itself) which means that the 25 and 24 are out of luck at the moment. 2.5kb seems quite heavy for tinyTuner so maybe there is some saving to be had there, I didn't look very hard, although 500 bytes is a lot of weight to lose.
sleemanj
commented
6 years ago So I hacked up tinyTuner and made veryTinyTuner in order that it should be able to work with 2k chips if necessary.
https://github.com/sleemanj/optiboot/blob/tinytuner/optiboot/bootloaders/optiboot/veryTinyTuner.c
tunable_attiny85_8000000L_57600.zip
It is a little simpler than the original, it assumes that the factory/existing cal will be close, and starts a search around there. First at a distance, if the error is worse, it looks closer and closer in a few steps, if it find a lower error, it re-centers on that point, narrows the search range to exclude where it came from and starts again. It tends to home-in within a dozen or so tests (sends of x), this may be a few more key presses for the user than the original, but it's a lot slimmer and it seems to produce decent results.
Here's an example on a tiny85 starting from the factory value of 151 and homing in to 147 (< means the ideal value is probably less than this, > means it should be greater than this, and ~ means it might be this).
Send x repeatedly to tune...
OSCCAL=151
Initial Error: 135/7500 with OSCCAL= 151
<181
>121
<166
>136
<156
~146
>141
<149
>143
~147
<148
Final Error: 5/7500 with OSCCAL= 147
Tuning complete, saving...
OSCCAL=147
Calibration savedHere is an example starting from a (forced) OSCCAL of 10, naturally you don't get to see the informational text to start with since the oscillator is so far out at that...
[garbage here]100
<130
<115
>85
~105
<110
<108
>102
<106
~104
>103
Final Error: 15/7500 with OSCCAL= 104Notice how it settles on a different value for the calibration, that's fine, there is more than one possible cal value especially if they are around the middle.
sleemanj
commented
6 years ago FWIW I have released a new version of my distribution which includes Tunable bootloaders for the 8MHz and 1Mhz options,
Supported chips for tuning are 25/45/85, 24/44/84 and variants there of (and also the Mega328/48/168... series but that's beside the point). 4/5/9/10 and 13 I don't provide bootloader support for but they are supported for ISP upload.
Burn the bootloader, open a serial monitor at 9600 Baud and send the letter x a few times ( x<enter>x<enter>x<enter>... eventually (12-20 x's usually, maybe more, maybe less, as few as 1 if it's already close-enough ) and it will tune the oscillator, tell you it's done, and you can upload using the bootloader thereafter (and do serial comms etc).
@SpenceKonde if you want to look at just the optiboot stuff from my fork, see the README.md https://github.com/sleemanj/optiboot/blob/master/optiboot/bootloaders/optiboot/README.md to build you will need a decent Linux-like environment as I made significant changes to the build process to make it a bit nicer. I doubt my build process will work on Cygwin etc, maybe on a mac if it's suitably equipped with bash, sed, grep and bc (and make).
SpenceKonde
commented
6 years ago Thanks for all the help everyone...
What I'm partial to is creating a Optiboot + TinyTuner for the 44, 84, 45, 85, 48, 88, 461, and 861 at 1 and 8mhz, at 16mhz for 45, 85, 461, 861, and Optiboot without TinyTuner for all those parts for all the other clock speeds I support.
I will put the bootloaders into a different folder (name TBD) than the current bootloaders/optiboot folder, rather than attempting to merge my changes to that branch (which aren't relevant to the other builds) with whatever fork of optiboot + tinytuner that will be used for this.
The next challenge will be to set up an AVR build environment on my linux system so that I can build @sleemanj's bootloaders.
nerdralph
commented
6 years ago You may be interested in my picoboot bootloaders. By making a custom protocol (which I patched avrdude to support), I got it down to 66 bytes. I also made a stk500 compatible version in asm that is <256 bytes. It's for atmega only, but with a few changes it could be made to work on Attiny. https://github.com/nerdralph/picoboot
Despite having developed bootloaders, I rarely use them now. As already mentioned in this thread, for 2K devices, the bootloader takes up a good chunk of flash. I use the Attiny13a for some projects, and even the 66-byte picoboot is relatively large. Also the internal RC oscillator on the t13a tends to be off spec much more than the tinyX4 and tinyX5. So until this year I used a USBasp to program tiny AVRs.
This year I started using debugWire. It not only gives you debugging, it's like a UART-based booloader in ROM. I've had to write some of my own tools, but now I can autodetect the baud rate (and therefore clock) of a target AVR. With the clock known, instead of mucking with OSCCAL, I hook up an AVR, run config.sh, which generates a make.defs:
dWbaud=70889
F_CPU=9073792
MCU=attiny13I can then build a target binary and flash it using dW. I wouldn't say it's ready yet to be used by your average 'duino user, but for anyone with more than intermediate AVR skills I highly recommend it.
SpenceKonde
commented
6 years ago Bootloaders (maybe without tinytuning for initial release?) for 44/84/45/85/461/861 will be added with 1.2.0 (which replaces 1.1.6 release)
SpenceKonde
commented
6 years ago I've got it working on the attiny85. This may be ready before the end of the long weekend.
SpenceKonde
commented
6 years ago Works on 88, 84. Didn't bring the 861 to check with.
Interestingly, I've yet to find a chip that needed calibration at room temperature and 3.3 or 5v
It would be helpful to have the bootloader also on the x4, it exist for the x41, so maybe it could be added without too much effort even if the x4 lacks of serial