Krupski:
There are reasons for wanting to load EEPROM directly at upload time... like this for example:
// Sony camera shutter release code 0x000B4B8F (focus and shoot)
// Header + 20 bit (5 byte) command.
// high bit (0x8000) set = LED on
static const uint16_t shutter1 EEMEM = {
// header
0x8060, 0x0018,
// data
0x8030, 0x0018, 0x8018, 0x0018, 0x8030, 0x0018, 0x8030, 0x0018, // B
0x8018, 0x0018, 0x8030, 0x0018, 0x8018, 0x0018, 0x8018, 0x0018, // 4
0x8030, 0x0018, 0x8018, 0x0018, 0x8030, 0x0018, 0x8030, 0x0018, // B
0x8030, 0x0018, 0x8018, 0x0018, 0x8018, 0x0018, 0x8018, 0x0018, // 8
0x8030, 0x0018, 0x8030, 0x0018, 0x8030, 0x0018, 0x8030, 0x01c8, // F
0x0000,
};
Is that really something that needs to be changeable by the application software? Seems like it's more appropriate for PROGMEM.
If the designers of the Arduino system (especially the IDE) didn't go out of their way to dumb down C++ to reach the lowest common denominator, we wouldn't have most of the problems that we have.
So far, the only thing I've seen in the AVR core that I actually consider to be really stupid is the decision to mask out all but the lower 3 bits of the channel number from the analogRead input. That makes it impossible to set the bandgap reference (channel 14) as an input, even if you try and be smart and do analogRead(0xE + A0) to get around the subtraction it does.
printf may be one thing, but even if you don't disable FP in the compiler, if you don't use anything FP the linker should throw it all out. The only use for that option then would be to alert you that you've inadvertently used FP.
Users are encouraged to use the EEPROM library and EEPROM memory as discrete locations (thereby forcing them to remember how many bytes their variable uses and where the next var should go) rather than using EEMEM like it's supposed to be.
I did it like this:
// ***************************************************
// EEPROM indexes and pointers
// ***************************************************
// Ring counter method from Atmel App Note 101
// High Endurance EEPROM Storage
#define EEPROM_START_ADDRESS 10
const uint8_t max_EEPROM_items = 150;
int16_t ring_index = 0;
uint8_t ring_counter;
uint8_t* status_buffer = (uint8_t*) EEPROM_START_ADDRESS;
config_t* parameter_buffer = (config_t*) (status_buffer + (sizeof(status_buffer[0])*max_EEPROM_items));
I converted them to pointers to use the avr/eeprom functions, but the basic idea is still the same: use the compiler to generate the EEPROM addresses using sizeof and the number of items I wanted in the array.
We have people who care how many extra nanoseconds "doing it right" will take. Sheesh... if that bothers you than stick in a faster crystal (or use a Core i7 processor instead).
I'm pretty sure none of the AVRs can even go much faster. I think they all max out at 20 MHz. I think the tiny85 (and maybe some others) can be clocked off the internal frequency multiplier, but then you only have 5 GPIO to work with. You'd need to bump up to an ARM chip or an ESP to have an appreciable speed boost.
