bootloader questions

[gogol]

I start here a new thread for discussing technical points around the bootloader.

Thinking through a possible project, I came up with the question, if the bootloader could be expanded, to access the eeprom of the attiny like avrdude.

AVRDUDE reads, stores (and verifies, which is than easy) *.eep files from/to the attiny.

-U wwprom:r|w|v:<filename.eep>:i:

That would be very handy in several cases:

• You could use the EEMEM keyword, like PROGMEM in your code, to store larger data structures in the EEPROM
• You could use the core bootloader, to exchange data from/to the eeprom without the need for additional USB libraries
  That could be very handy for applications like data-loggers, or control like applications, where you wish to upload different profiles to.

Especially for end-users of the project, which have usually no experience with program-environments, you can provide a project-specific application, just exchanging eeprom data, when the digispark is plugged in.

regards

  gogol

[Bluebie]

Being able to upload eeprom via eemem keyword would be neat, but we could actually do this a sneaky way, without adding any extra code to the bootloader: the upload utility on the computer could scan the .hex file for eeprom segments, and if it finds any it could instead package them in to an eeprom upload program, write that, run it, then automatically boot back in to the bootloader and upload the user's program. This way you could have the extra functionality without having to store the eeprom writing code and extra usb interface stuff in the bootloader on the chip permanently - reducing how much space is available for programs.


That's really the core of the issue - adding eeprom support right in to the bootloader doesn't really make sense from a space saving perspective because it would make the bootloader fatter, so you would be trading flash for programmable eeprom, but most people wouldn't even use the eeprom anyway, and it's still fairly straight forward to write a program which sets stuff in eeprom to do your initial setup.


As for eeprom as a communications medium, I've thought a bit about that too but it seems not so useful, since it only works for a few seconds after you plug the device in to the USB port.


Still, it's an interesting idea. Maybe it'd be smarter to add a flash read function - then it could fully verify uploads, and if you need to do eeprom stuff only, it could download the current one, upload eeprom utilities program, run it, and when done automatically load back in the program from before then.