Major micronucleus size reduction, bringing it below 2.0k goal

[Embedded-Creations]

 I was able to take 224 bytes off the size of the firmware, bringing it well below 2.0k. 


First, some background on the changes.  When I made USBasploader-tiny85, one of the goals was to use existing software on the PC to interact with the boot loader, with very little PC software modifications.  This meant putting a lot of intelligence into the boot loader.  After I saw the result was a huge 2.6k boot loader, and later saw micronucleus close but not quite at 2.0k with a much simpler protocol, I realized that for this project the firmware should be made as simple as possible.  I stepped back and looked at what the firmware was doing, and thought about moving as much as possible to the PC side.


The main things moved to the PC side are the calculation of the vectors stored in flash, and intelligence on when to use the Page Erase and Page Write SPM instructions.  The firmware no longer knows how to erase the application or even erase a page, it just knows how to execute a generic SPM programming sequence.  The PC software sends it commands with details on how use SPM to erase a page and to write a page to flash while running.


These changes brought the firmware below 2.0k, and I was able to make the page loading code a little more space efficient too, at the cost of speed.  Instead of sending a full page of data at once to load into the buffer, a shorter message with just a word at a time is sent instead, saving about 50 bytes of flash.  Transferring data this way is slower, and it takes about a second longer to program, but the code is small enough to give another page of flash back to the application.  After these changes the boot loader can start at address 0x1880, two pages (128 bytes) smaller than the 2.0k goal.


I originally did all my work using the latest version of AVR CrossPack, but used the old 20100115 version which compiles a smaller binary for the final commits.  It's only 8 bytes more efficient with this new firmware, but that's enough to move the boot loader across a page boundary, so it's still worth releasing code with the old toolchain.


Pull request on github here:
https://github.com/Bluebie/micronucleus-t85/pull/21


I'm working on a version of the boot loader that uses the HID interface so no windows drivers are needed, and communication can be done through native libraries instead of libusb.  Adding HID takes a firmware size hit, it's about 200 bytes larger, so I doubt it will be of interest here, but just in case, here's the branch where I have some initial working code:
https://github.com/embedded-creations/micronucleus-t85/tree/HID


Thanks to Bluebie for the great ongoing work on micronucleus and ihsan for the commandline utility!

[digistump]

This is really awesome - I can't wait to try it out!


I think the HID idea is really cool too, and while many would kill for 200 bytes - I actually feel the ease of use of having it work over native HID might be worth eating up 200 bytes, especially in an education setting.


Let me know if I can send a few more digisparks your way for testing/messing with.


Thanks,
Erik

[Bluebie]

I'm optimistic and fairly excited about these changes, but I have some reservations which are being discussed over on the github pull request. If technically minded folks want to contribute their thoughts, that is the best venue for it.

[peter]

Hi, Any progress with HID bootloader? Binary version or win32 commandline? Thanks verrry much !

[Embedded-Creations]

No updates from my last GitHub post unfortunately.  I'm not sure if the product I'm designing will have a tiny85 in it or not, so I've put the boot loader changes on hold for now.  I'll post back if I make any major progress.

[peter]

Please can you describe how to create hex file for digispark and comandline tool under windows enviroment. thanks

[Embedded-Creations]

OK, I'm back on this project.  I spent a good amount of time replacing the default oscillator calibration with an alternate version that saves over two pages of flash, bringing the total size just under 2.0k.  I thought it would be easy, as there was sample code provided by V-USB, but it became more complicated to come up with something that will work with a starting oscillator calibration far off from 8.25MHz, and to make it work with the ATtiny's pin-change interrupts instead of external Int0.


I've only tested it with my machine and the single ATtiny85 I have with me right now.  I think the code is ready for some testing by more people, but please don't use my version and burn the reset fuse, there could be some bugs in it that would brick your micro.


Discussion here:
https://github.com/Bluebie/micronucleus-t85/issues/26


Code here:
https://github.com/embedded-creations/micronucleus-t85/

[Embedded-Creations]

Another update, this time on the HID branch to micronucleus.  I was able to add HID support requiring only an additional 140 bytes of Flash.  I found an efficient way to set a flag when the device receives an HID poll, which saved a good amount of Flash.  The rest of the changes were made to send data in a way that was supported by HID reports (the existing way micronucleus embeds an address in the USB header isn't supported by HID, the address needs to be with any other data in the payload).


I modified the micronucleus protocol to use a common 4-byte payload for commands that need to send data to the boot loader, 2 bytes for address, 2 bytes for data (data is only used by the PAGELOAD command).  Now the commandline utility sends addresses for all actions to the boot loader, and erasing is done page by page (with a safety check when erasing the first page to avoid losing the vector table).  I made separate commands for PAGELOAD and WRITE. 


I was hoping all this refactoring would result in some efficiencies that could be applied to the non-HID version of micronucleus, but after compiling a version with no HID support built it, it actually just added 10 bytes to flash. 


It's up on github.  I haven't done a ton of testing on it, but did verify that it can load an application, erase and load a new application successfully.  Comments are a bit sparse and there are leftover comments from the older code.
https://github.com/embedded-creations/micronucleus-t85/tree/HID2

[bobricius]

I am really excited HID versions, good luck in further work!

[CBcracker]

That sounds good.  If you're offloading work to the PC driver, you could also pre encode the data so that it's already xor'd, and thereby remove that step from the usb code (saving 1 cycle).
I think some big code savings could be made by using optiboot code http://code.google.com/p/optiboot/
With optiboot as small as 512 bytes, and the soft usb code ~1KB, maybe we could have a 1.5K bootloader.

[Bluebie]

V-USB is not around 1kb on attiny85 running without a crystal. It is more like 1.5kb.

[CBcracker]

V-USB is not around 1kb on attiny85 running without a crystal. It is more like 1.5kb.

The V-USB site says "Only about 1150 to 1400 bytes code size.", so even taking 1400 bytes + 512 for optiboot, we're at 1912 bytes.  That's well under the 2K target, and that's assuming no redundancy between the optiboot and V-USB code.

[Bluebie]

There is already a variant of micronucleus (this thread is about it!!) which moves most of the logic in to the host computer to make the code in the chip as small as possible, but unfortunately this means two things: The host software becomes very firmly tied to the specific chip used in the device, and the things which keep the chip safe from bricking are implemented in the host computer software. The first thing is a matter of preference - I like things I make to be very interoperable and reusable. The second thing is dangerous, because an error in the usb connection or a bug in the upload software can cause the chip to brick!!


So that's why micronucleus isn't 1.8kb big.


And please, optiboot isn't doing any magic. Optiboot is a serial bootloader. There is probably nothing at all in it relevant to micronucleus.

[CBcracker]

[...]
So that's why micronucleus isn't 1.8kb big.

I've been working on a tiny (<=1K) usb bootloader for the tiny85 (& other pin-limited devices).  I started with the USBaspLoader code, writing code for 8Mhz.  Although I haven't finished that, lately I've been working on the bootloader (self-program) code.  I decided to start a separate project for it: http://code.google.com/p/picoboot/  I think I can get a smaller bootloader by writing new code from scratch than I can by paring down existing bootloaders.

One surprise I got when reading the micronucleus code was the following comment in main.c:
"Because flash can be erased once and programmed several times, we can write the bootloader..."
Where did you find this out?  I can't find anything about it in the datasheet.  Is there a limit to the number of writes per erase?

[Embedded-Creations]

I'm not sure it's in the ATtiny85 datasheet.  It's a property of flash memory that I've seen in the past, and probably just tried on the AVR without checking for confirmation in the datasheet.  Here's some info from Wikipedia:
http://en.wikipedia.org/wiki/Flash_memory#Block_erasure


I don't think there's a limit to number of writes per erase.  I guess you could say the limit is when everything is set to 0's. :-)