Optiboot version 8.0 release

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 4

Optiboot version 8 is available.

The major points relevant to Arduino users include:

  1. Cleanup of the MCUSR (reset reason) behavior.
  2. Ability to jump to the bootloader "as a service" to reload new code (with a bit of care.)
  3. an available do_spm() function that allows an application to write to flash memory by calling code withing the bootloader.
     

Other changes:

  1. update switches for more recent compiler versions (as consequence is that it no longer quite works with WinAVR or the IDE1.0.3 compiler.)
  2. Add options and "help" target to makefiles.
  3. Fold in Hans's (MCUDude's) miniCore, megaCore, mightyCore, and majorCore to support a very large number of ATmega targets.
  4. Fold in DrAzzy's ATtinyCore, to support a bunch of the more capable ATtiny targets.
  5. On targets with 1k bootloaders, include text info about the build in the binar
  6. Make sure the "Virtual Boot Partition" targets work (needed for (4), but... other platforms too!)
  7. Add and update test tools and sketches.
  8. with a bit of luck, you COULD compile an ATmega328 Optiboot that includes EEPROM read and write capability that still fits in 512bytes (but you have to turn off the do_spm feature, and removing the startup LED blinking.)
  9. Various internal cleanups and generalizations.
     

Most of this work has been available for a long time now, from MCUDude, DrAzzy, and/or Majekw.  I've just finally gotten around to including it in the "master" Optiboot tree.

 

There is a .json package for the board manager on the release sub-page, but it's become quite minimal compared to the targets and options that are supported.  Unless you want to mess with the source code or build a bootloader with a particularly strange combination of features, it is a much better alternative to use one of the "board" definitions from MCUDude or DrAzzy that include a wide variety of .hex files of the bootloader, AND "core" code to support the processors.  (MCUDude's cores contain several thousand permutations of optiboot*.hex files for different baud rate, processor clock rates, and uart choice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Mar 7, 2019 - 01:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally I don't like this:

 

https://github.com/Optiboot/opti...

 

The reader looking at "pre_main" has no indication (except perhaps the name?) of knowing the special address handling for this function. You have to look elsewhere to:

 

https://github.com/Optiboot/opti...

 

to know that it is in .init8

 

But how does that work anyway? The app user who wants to call do_spm cannot easily find it. Surely a better solution is to put it as the second entry in .vectors (I'm assuming no IVSEL?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But how does that work anyway? The app user who wants to call do_spm cannot easily find it. Surely a better solution is to put it as the second entry in .vectors (I'm assuming no IVSEL?)

Standard vectors are suppressed at link time by -nostartfiles, so effectively that's what you get - jump to main at the very beginning, jump to do_spm at the next location.  (Not counting the short-lived bug in the BIGBOOT version that put some PROGMEM text there.)  I'm not wonderfully happy about how do_spm() works (I would have put the vector at the end of memory, I think, so that the start was always at the start, but... it escaped in the wild while I was hemming and hawing about implementing it at all, and I didn't think it was worth fighting over.)

 

 

Is there a better way to indicate the absolute structure at the beginning of the program?  I could use a custom linker script, but I think that would have the effect of obfuscating the startup even worse than it is now...

 

Maybe get rid of "main"-like names entirely?  Without startup files, "main" doesn't really have any special status anymore, does it?

 

 

Last Edited: Thu. Mar 7, 2019 - 07:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
3. Fold in Hans's (MCUDude's) miniCore, megaCore, mightyCore, and majorCore to support a very large number of ATmega targets.

Release 1.15.0 · platformio/platform-atmelavr · GitHub

...

  • Added support for MCUDude/MiniCore (Arduino hardware package for ATmega8, ATmega48, ATmega88, ATmega168, ATmega328 and ATmega328PB)
  • Added support for MCUDude/MightyCore (Arduino hardware package for ATmega1284, ATmega644, ATmega324, ATmega324PB, ATmega164, ATmega32, ATmega16 and ATmega8535)
  • Added support for MCUDude/MegaCore (Arduino hardware package for ATmega64, ATmega128, ATmega640, ATmega1280, ATmega1281, ATmega2560, ATmega2561, AT90CAN32, AT90CAN64 and AT90CAN128]
  • Documentation how to configure MiniCore, MightyCore, and MegaCore

...

 

"Dare to be naïve." - Buckminster Fuller