Writing on board flash library while keeping similarity to current EEPROM library

Status
Not open for further replies.

hak8or

New member
Hello all!

I am currently working on making a flash library for the teensy 3.1 which is meant to mimic the current EEPROM library in terms of simplicity of usage via two simple function calls, read and write. I have gotten to the stage where I can successfully write and read from the flash, but I am having some issues with how the EEPROM library is structured, specifically the OO aspect of it. Right now my flash library is in the form of a class called Flash, and usage is via making a new Flash object in a global scope. I would have left that as is but I want to make it as similar to the EEPROM library as possible so there would be less confusion for users, but I haven't got the faintest clue how the current EEPROM library handles it's OO aspect. Once I get this down as well as dealing with writing to flash working only via 32 bit data compared to EEPROM writing just via a byte, I am hoping to put it up here in the forums and seeing if Paul deems it worthy to put on the teensy libraries page so others can use it.

I am assuming this is the repo showing the current state of the teensy 3.0/3.1: https://github.com/PaulStoffregen/cores

Specifically, where or when is void eeprom_initialize(void) called? I would assume in the EEPROM constructor or an EEPROM.init() function somewhere but I can't seem to find it.
The EEPROM.Read and .Write usage seems to imply that there is an EEPROM class somewhere, but I can't find it. Where is this class, and if there isn't one, then how does EEPROM.Read or .Write work, or what does EEPROM.Read call and where can I find it?
The best I can find is this but it seems to be only C style with no OO via C++ anywhere.
Is EEPROM an object in the global scope or is something else going on here?

Basically, in short, how does doing EEPROM.Read and EEPROM.Write work when I don't see an EEPROM object made anywhere or a class definition anywhere and how can I replicate this capability for my own libraries?
 
That EEPROM code is structured as C code because it emulates both the Arduino EEPROM library and also the avr-libc library. Many sketches on Arduino use the avr-libc functions directly, rather than the EEPROM library, so this dual API approach is needed for good compatibility.

For a new library, you obviously don't need to emulate the avr-libc functions.
 
Status
Not open for further replies.
Back
Top