NVRAM and where hardware features should be specified programmatically

@Gordon - I wanted to ask about this but didn't want to take over that other thread...

Is it better to add on-chip low-level features to jshardware.c or as modules? For something like NVRAM I think that basic read/write, or at least the address would be great to have built in.

Also, I did not know about process.env, it looks quite handy.

Well, I guess it depends whether it's going to be used a lot.

If it's some part of the chip that's going to be used loads, needs to be fast, or needs deep integration with the interpreter (SPI, I2C, etc) then it'd be built-in, otherwise it could be a module.

The NVRAM falls inbetween I guess - it may not get used that much and doesn't need to be fast, and especially on the classic board we're running low on available flash so I don't want to add things unless they're absolutely required.

As it stands there's currently a bug in Espruino classic (forgetting the 'high word' of the RTC time if it's restarted) that could be fixed by using some of the NVRAM, so it may well be that I end up adding support internally.

Okay, thanks, good to know. I suppose that once implemented, features can be ported to internal functions if they prove popular.

Btw, NVRAM/EEPROM is handy for storing things like network addresses for when you're running the same code on multiple devices. But I suppose with Espruino you can just set it into a variable and hit save(). :)

But I suppose with Espruino you can just set it into a variable and hit save(). :)

Yes - there's also the STM32F1Flash module if you want to use some of the left-over space in Espruino's flash (but you have to be careful with that!).

I should implement a module that uses it to 'fake' an EEPROM - I think it's something that Arduino does on the ARM chips that don't have a real EEPROM

That would be great! I don't think there would be massive demand for it, but it would be really handy for some people and great for when porting libraries from arduino.