Espeasy: Add support for FM24CLXX FRAM to store data to survive power loss

[TD-er]

See FM24CLXX FRAM datasheet and dev board

Possible use-cases:

• data points
• current state of rules
• current state of pins/tasks
• etc.

Should not be a plugin I guess, but integrated in ESPeasy to be used for all.

[uzi18]

I2C addresses: 0x50-0x57
FM24CL16 is 2kB FRAM, cost about 2 EUR
FM24V01A (16kB) 7 EUR

[beicnet]

24C02, 24C04, 24C08, 24C16, 24C32 and 24C64, 10pcs of each cost $2.70 USD

[TD-er]

@beicnet Those are not FRAM, but EEPROM.

[beicnet]

@TD-er Yes, I know, but they are also I2C too, can use for the same porpuse and cost much, much less...

[TD-er]

That's true.
How often can they be written?

[beicnet]

@TD-er It's about 1 million write cycles and 40 years of data retention, and look at this beautiful cheap finished module (Atmel AT24C256 documentation), module prices are from $0.70 USD to $3.60 USD on Ali.

[TD-er]

Since the type numbers are also the same, maybe implementation of both is the same?
But still could be wise to distinguish both to use some caching to reduce write cycles.
It can be used to create some historical log data, for example to show charts on the OLED display (issue #809 )

[beicnet]

@TD-er Yes, true, also the AT24Cxxx series has a little advatage in power supply aspect, they can work in range of 1.8V to 5.5V, the FM24CLxxx can only work in 2.7V - 3.65V.

And I think the AT24Cxxx are much popular in the IoT world (most widely used).

[beicnet]

... and they are actually pin compatible, but the FM24CL16 don't have i2c address selector pins....

[TD-er]

huh? On the Ali-express boards are 4 jumpers to select the I2C address.
Or is that a specific one you mention that hasn't got them?

[uzi18]

These jumpers are to bypass i2c bus on the other side of board, to next socket

[beicnet]

@TD-er On that module (AT24C256), the jumpers are for i2c address selection (3x jumper, A0, A1 and A2) and for the write protection (1x jumper, WP).

If I'm correct then the i2c addresses are form 0x50 to 0x57.

I was talking about the FM24CL16 (your first post, doesn't have any address slector pins only one i2c address , predefined - just a note).

@uzi18 You are wrong about that...

[uzi18]

Looks like this board is compatible with more chips and jumpers are realy for A0-A2 and WP if chip supports it.

[beicnet]

Yes, and they (the Atmel EEPROM family generally) are sooo cheap that is ridiculous!

If you look at this bundled product on Ali (50pcs AT24C256 DIP) cost $15.00 USD and the SOP like $9.00 USD

[M0ebiu5]

I vote to implement this as a plugin, cause i guess only 1 of 100 would use it.

[uzi18]

FRAM is different target than EEPROM, but I2C is realy slow.
@TD-er maybe consider to use FRAM with SPI interface?

[TD-er]

Well I think we should go easy on the SPI devices, since there are also quite a few SPI sensors/displays we should/could support in the future.
And may as first step @M0ebiu5 ' idea of using it as a plugin is also useful. Just to see how it could be used.
I guess log/buffer will be the main usecase.
And given the 400 kHz I2C bus, it shouldn't take too long to read/write an entire 16 - 64k?
Given its primary use of only storing a value every now and then, speed isn't that important I guess?
It's not like we're going to use it as a memory upgrade?

[giig1967g]

Hi,
Very interesting.
Just purchased 2x AT24C256 dev boards with I2C for 0,58$ each.
So will be able to test whenever the plugin will be ready.

[Budman1758]

I have some of these just waiting to be fired up!
https://websites.godaddy.com/blob/d0f1813f-418c-4780-8b0e-f456f226885c/downloads/1bi7bfs29_602842.pdf

[TD-er]

Pfiew, just a link to a datasheet... posting links to direct buy stuff is always a lot more dangerous ;)

[Budman1758]

LOL. I can change the link if you want me to. :)

[amkrk]

Any of these chips will likely serve the purpose...

Variables (32bit if possible) surviving a power loss (with a help of either EEPROM or FRAM) - it opens a strong use case for implementing persistent pulse counters (elecricity / water / gas meters) w/o a use of additional controllers (performing a sophisticated algorithms, or loosing a data in corner cases).

The same 32 bit variable would need to be send-able directly into the external controller, and setable by http (even through easyesp's webpage).

What would need to happen in order to have it implemented ?

[uzi18]

@amkrk isn't cheaper to connect sdcard to espeasy ?

[TD-er]

It just happens that someone I know from several MeetUp meetings is asking me for a while already about looking at this library he wrote for these chips.
And I am working on something which needs to keep some data even when the power is lost (thus RTC memory cannot be used)

Thing is, I have been quite busy with other things lately so I can't put a timeframe on it.

[amkrk]

isn't cheaper to connect sdcard to espeasy ?
As far as I know (?) sdcard is not supported at the moment by espeasy (?), and using it for storing just a few bytes would probably bring unnecesary complexity as well as extra points of failure (like a power loss during a write, reletively long response time from sdcard, code size growth, etc). I think using pure eeproms would be not only cheeper, but also simpler so more relaible.

[TD-er]

SD cards not only may suffer from wear due to writing and take a number of pins to operate.
All of the SD cards I had that stopped working, did stop at once. Either not able to write anymore (still able to read) or became unusable since they were no longer recognized.

[uzi18]

@TD-er yes and sometimes become readonly, but in facts communication is faster and they are cheaper. Old ones with capacity <=1GB are more reliable.
One can store data on sdcard directly inside blocks and store pointer to these data in RTC, so wear is not a big deal.

[TD-er]

But they do need quite a lot of GPIO pins, right?
It is some implementation of SPI if I'm not mistaken.
So you'll need Clock, MISO, MOSI and chip-select.
Not sure how many of these pins can be shared with the internal flash.

I think both serve their own use cases.
FRAM/EEPROM can be connected to any existing I2C bus and depending on the number of pages in the chip they will occupy one or more I2C device IDs on the bus.
FRAM chips are available upto 1 Mbit, so you can store upto 128kByte in them.
They are quite slow (on I2C bus), so don't use them as extra RAM :)
Speed is about 800 bytes/sec, but I guess that can be tweaked a bit ;)

[uzi18]

we can check it, but i think we use for uSD card haspi interface with one additional gpio for chip select.
Prefs: Hardware->SPI Interface -> SD CARD - CS gpio

[TD-er]

OK, that would be an option then I guess. Also this does show I never did anything with the SD cards on ESP nodes ;)

[uzi18]

@TD-er Adafruit MB85RS64V - 8kB fram with spi interface - 5.95$

[TD-er]

I2C FRAM chips start at 1,40 euro for 16 kbit.
8k x 8 (64 kbit) costs 2,45 euro (just checked at Mouser)

I think addressing them is not really the issue, but more how to integrate it in ESPeasy.
Should it be part of the core, like storing volatile information such as:

• last values of plugins
• state of GPIO pins
• Last entered function (seen from the scheduler)
• State of rules execution
• Cache of rules entries

But it could also be very useful for caching data which has not been sent by a controller.
Or stored variables in rules.
Stored samples to aggregate data.
Generic statistics.

How should that be made available?
I guess part should be accessible via some controller (or generic controller cache for any controller).
Also a plugin to aggregate data. A bit like the dummy plugin but then able to perform actions on sequences of data.
Or should that something any plugin should be able to do? (a bit like the formula option)
Storing historic data to show a chart on a display?

I think that's really the hard part here, how to incorporate this into the current framework of ESPeasy.

[amkrk]

Maybe it will be mode doable if the bigger vision is split into smaller pieces arranged into functional drops.
For example:

1. A support for a generic EEPROM/FRAM (I2C memory) device with its I2C bus address as a param, which may address a bigger family of chips (so data capacity demands) may be a start point.

2. Then connecting its API into espeasy's rules, so the rules script can read/write from/to its traditional variables into it. With this many user cases are enabled already.

And then 3. a support for data series (as a structure/object), and then 4. sending these series out, statistical functions (allowing to compact the data) or 5. their visualization on espeasy www's charts.

?

[TD-er]

Thing is, bigger FRAM chips (well not really depending on the size but on the number of pages) will have multiple I2C addresses.
So either we just set its base address and continue there, or just any address in the range of that chip to select just the chip and then set some range of data to use in the plugin.

Or maybe first start implement it as a core function (stuff to restore state after reboot) and include it in the cache controller plugin. (great new feature I am developing the last half year)

[uzi18]

it is possible to have collision here with known adresses of other i2c plugins/chips

[TD-er]

Yep, but that's possible with any I2C device.
There are simply more I2C devices on the market than available addresses.

[uzi18]

@TD-er another idea: 23LC1024 SPI RAM :)
Standby Current: 4uA at +85°C
RAM Data Retention Voltage 1V.

[TD-er]

Hmm that's an option, but then you really have to make sure the chip-select pin is connected to a pin that's not being toggled at boot and also that it is being toggled when the SPI flash chip is being accessed.
So maybe it needs also a logic circuit to invert the CS pin of the SPI flash or else it is really hard to not interfere with the SPI flash.
Other option is making a SPI bus yourself, but that takes at least 3 GPIO pins.

[uzi18]

just choose pin witch is internally pulled high durring boot like gpio 0/2/15

[TD-er]

Nope, that's not enough.
For example you don't know when the SPI-flash is being accessed, so you really have to make sure it is not set when the SPI flash is being accessed. That's near impossible to do in software since its access will be mainly done by the core libraries.

Also GPIO-0 will be pulled down when writing a sketch to the node.

[uzi18]

gpio2 looks promising here and we only copy data from ram into sram so maybe we need to. mark copy function as IRAM...

[JeeCee1]

Hi team,
is there any update on this?

[TD-er]

Nope not yet.