`eeprom_driver.c` will not compile for xmega E devices

[fake-name]

Basically, it seems like Atmel is trying to depreciate 'NVM_CMD_READ_EEPROM_gc', 'NVM_CMD_LOAD_EEPROM_BUFFER_gc', 'NVM_CMD_READ_EEPROM_gc' and 'NVM_CMD_LOAD_EEPROM_BUFFER_gc'.

In any event, they've removed them from the available commands for the NVM controller on xmega E devices.

Is there any reason xboot is using it's own EEPROM driver, rather then the EEPROM functions in <avr/eeprom.h>? The functions in <avr/eeprom.h> seem to be written in assembly (assuming I'm looking at the correct source files).

Is it a code-size issue?

[alexforencich]

The included EEPROM driver can probably be replaced with eeprom.h. The only reason I used those was because I had to include the file in order to access the flash memory so I went ahead and used the EEPROM as well.

[fake-name]

eeprom_driver.c is used for flash access?

Where? I don't see it being included anywhere except xboot.c, and only for EEPROM access there.

[alexforencich]

No, the sp_driver.S is needed for flash access. I went ahead and used it for EEPROM access as well when I wrote xboot. It may be possible to replace the EEPROM portion of that with eeprom.c.

[nickdademo]

Also running into this issue with the XMEGA 32E5.

@fake-name : Did you end up just using the AVR EEPROM header (avr/eeprom.h)?

[fake-name]

@nickdademo - I wound up just flat-out not using xboot at all.

[nickdademo]

Thanks for the reply - did you end up rolling your own then?

[fake-name]

No, I just reworked the mechanical design so I could expose the programming interface in a way that let me update it that way.

It was for a one-off project anyways.

Sorry!

[nickdademo]

Added XMEGA E5 support in this PR: https://github.com/alexforencich/xboot/pull/17

Tested and working with XMEGA32E5 (including XBoot API).

[fake-name]

I'll close this if/when #17 gets merged.

[alexforencich]

17 has been tested and merged.