I’m still working on some supplemental material as and when I have time, including (hopefully) a simplified explanation of what’s what.
The Doxygen documentation is the most important part because it has to be provided alongside the code and is a prerequisite for the API implementation being included in the library.
For the benefit of anyone else reading, the full note says:
This function exists to support devices that do not have native EEPROM. On devices that do have native EEPROM, such as the Arduboy, this function is technically unneccessary and performs no work, thus allowing it to be optimised away by the compiler.
I designed this API with the intent that the API itself would be a kind of cross-platform standard that could have different back-ends.
The ‘does nothing’ note only applies to devices that have ‘native’ EEPROM (i.e. actual, genuine hardware EEPROM, or hardware that provides the same qualities as EEPROM). The Arduboy’s version does nothing, but implementations provided by devices that don’t actually have hardware EEPROM are more or less guaranteed to so ‘something’.
That note exists almost entirely to placate the “Is using this going to waste my precious progmem?” people.
I’m expecting that rather than trying to provide flash-simulated on the FX chip as a backend to
Arduboy2EEPROM, there would be an
FX::EEPROM class that provides the same API and could act as a drop-in replacement. At which point it would be a case of either a simple find-and-replace or, for the people savvy enough to create a type alias, replacing the type alias (
using Storage = Arduboy2EEPROM; →
using Storage = FX::EEPROM;).
I did contact @Mr.Blinky for comment, but received no reply, so rather than wait for one, I decided to presume my assumptions were all fine and announce the current revision.
I also contacted @ESPboy to make sure that
commit would be enough to support the ESPBoy, and together we concluded that they would be. (The names
commit are actually taken from Arduino’s ESP8266 implementation of
You do if you care about making life easier for people porting games to other devices.
Much of the documentation is written under the assumption that you do care and want to write code that will behave properly on any device.
It’s theoretically likely to save at least some.
At the moment I haven’t actually attempted to compile the code because I’ve been too busy writing the documentation, responding to GitHub messages and dealing with those other pesky responsibilities that life thrusts upon me.
It might be, but it’s going to mean an extra template function for every function that excepts an
address parameter, and another heap of documentation to go along with it.
I could replace all the functions that take
address parameters (except for
writeByte) with versions that accept the address as a template, but I’m sure someone would complain somewhere along the line. (For some strange reason people tend to start screwing their faces up when they have to use angle brackets in addition to round brackets.)
Nope. As mentioned above, I was too busy writing documentation.
But the actual code is really simple, so if I’ve buggered up anything it’s more likely to be a typo than a logic error. (Or if it is a logic error, I’ve probably got the forwarding wrong - trying to improvise perfect forwarding without implementing
std::remove_reference is a nuisance.)
I’ll look into it later when I’m done scraping together some lunch and trying to figure out what an “invert the colours of this image” icon is supposed to look like.
That is, unless someone else wants to ‘brave’ it.