search

micronucleus / micronucleus

ATTiny usb bootloader with a strong emphasis on bootloader compactness.
Other
1.68k stars 384 forks source link

Reading and Writing to the EEPROM #139

Closed AHorneffer closed 4 years ago

AHorneffer commented 5 years ago

In my fork on the eeprom branch I implemented reading from and writing to the EEPROM of the MC: https://github.com/AHorneffer/micronucleus/tree/eeprom (This was already discussed 2.5 years ago in #76, but not solved back then.)

This goes squarely against the original intention of micronucleus, in particular the "micro" part as it increases the bootloader size by about 250 bytes. So as useful as I think it is, I'm hesitant to suggest to include it in the general micronucleus repository. But I would appreciate feedback and additional testing! Some known issues:

P.S. Before you ask: it is still smaller than USBaspLoader (not in the least because that one needs to be at the start of the bootloader section and thus effectively requires 4 KByte on an ATmega328) and more flexible than that (because it isn't tied to the INT0 pin).

cpldcpu commented 5 years ago

Maybe you can make it smaller? :)

Well, it could make sense to add this as an option that is normally disabled?? On the other hand, I wonder if there are many situations where you would have to write something to the EEPROM that cannot be written to flash instead?

AHorneffer commented 5 years ago

Maybe you can make it smaller? :)

;) One could maybe shave a few bytes off here and there, but I don't think major gains are possible.

Well, it could make sense to add this as an option that is normally disabled??

It's already set up like that. The only things to change are setting the INCLUDE_EEPROM_IO compile option and adjusting the BOOTLOADER_ADDRESS in the makefile. Without that you'll get the regular version.

But at some point the code will get so cluttered with compile options that it will be hard to read.

On the other hand, I wonder if there are many situations where you would have to write something to the EEPROM that cannot be written to flash instead?

If your device collects data in the EEPROM and you want to get the data out of there, or want to write some default values into the EEPROM, or want to transfer the values from one device to another, then that is useful. Of course there are many ways to skin a cat, but for me this was / is the most convenient way.

cpldcpu commented 5 years ago

One could maybe shave a few bytes off here and there, but I don't think major gains are possible.

Well, the reading kills it, since all the code to assemble USB messages from RAM has to be included. Certainly there would be some ugly hack by "refactoring" V-USB even more, but that would just get more messy.

Hm, I also don't have any idea how to integrate it in a cleaner way.

If your device collects data in the EEPROM and you want to get the data out of there,

Ok, I see the point.

AHorneffer commented 5 years ago

Well, the reading kills it, since all the code to assemble USB messages from RAM has to be included.

Hmmm... Good point. I could change it that you can choose between writing only, reading only, or both.