Using EEFS on an 8 bit AVR ATmega, with 16 bit pointer arithmetic. about eefs HOT 4 CLOSED

Ok, so I changed the code to support 16bit pointers in an gcc-avr libc-avr environment for ATmega devices. Individual devices are addressed by the most significant Byte of the 4 Byte address. 24 bits remain for addressing within the SRAM / FRAM / EEPROM device.

Result can be found here. https://sourceforge.net/projects/avrfreertos/files/freeRTOS/lib_eefs/

from eefs.

Nice work!
Sorry I could not help with the 16 bit pointers, we have only used the EEFS on 32 bit CPUs so far.
( I have the same FRAM board for my raspberry Pi.. I will have to try that )
Alan

from eefs.

Thanks Alan,

I need to do some more testing and prove I've not broken your code, and then I'll create a "16 bit pointer" fork for you.

The background is that I'm building an Arduino derivative board using an ATmega1284p with two SRAM / FRAM / EEPROM SPI slots. The intent is to use these devices to feed the dual channel MCP4822 DAC. The largest 5V SPI RAM device seems to be only 1Mbit and so 17 address bits are needed. That means I could use the high address byte (of 32 bits) to address each device.
http://feilipu.me/2014/12/06/goldilocks-analogue-part-6/

I've built a tool to take the geneepromfs output file from a FatFS uSD card, and then write it to the (S/F)RAM at any Base Address.

The footprint of the two SPI (S/F)RAM devices can be seen next to the MCU. FRAM devices are only 8kByte at 5V, and that is not many samples. So, I'll probably use SRAM or EEPROM in practice, as they're available in 128kByte versions.

from eefs.

Finally finished the testing, and adjusted the AVR ATmega code to reduce the overhead from returning 32 bit error values.

Made no changes to the on FRAM/SRAM/EEPROM file structure so the standard FRAM image generating tools will work as expected.

https://github.com/feilipu/eefs

Note that this fork uses some elements from freeRTOS for semaphore locks etc.
The hardware interface is the AVR ATmega SPI bus.

from eefs.