Flash-memory

Kernel
1

Hello there,

i’ve got FreeRTOS working, my only problem is my lost temperature-curves. My controller crashed randomly, probably because of unshielded wires to the roof. One evenening when i came home, all my recorded temperature values were lost.

To be honest, i don’t think there is a solution for my little problem right now. I’m working on it in free time. What i really need is a flash-memory that is working with power-loss, and i’m almost there.

I’ve implemented a memory-manager and tested it in memory. My next step is to transport it to flash-memory. It is not really difficult for me anymore, i’m sure it is working. Because i’m not comfortable with the current API of FreeRTOS You may have to do these steps on Your own.

Here is the goal:

auto list=flash_list_open(“buf_temp”);
flash_list_set_at(list, time, temp);

You can transport my heap one by one to flash-memory. The first interesting field in the header is the ‘used’-value. It is rapidly changing when filling memory and takes the first two blocks in flash-memory itself. Whenever changed, the new value is appended in both blocks until both blocks are full. Then the blocks are erased one after another, so there is always a reliable value.

When creating the maps of used and free blocks, the fastest option is to only store a group of 10 items in one block, and to append changes. There are two functions:

flash_alloc() and flash_free()

Because the created blocks need to be mapped, the only way is to overwrite existing entries. So there is the need of third function, and now it is getting funny somehow:

flash_flush()

Overwriting causes an update to be created in memory first. As soon as You call flash_flush() the update is stored in free space. I use a simple formula to move it around in free space and save the flash-chip. If there is power-loss, an update is found or not. Overwriting is repeated on power-loss, all data is reliable.

If You follow this simple concept, Your customers don’t need to buy batteries for backup anymore.

Best regards,

Sven

2

Another option, should you want to throw hardware at it, is to use an I2C flash chip such as the 24C256 (32K * 8). The advantage is that while odd things may happen in the processor, it’s more difficult to get through the I2C interface to corrupt the I2C memory. You’re looking at an 8 pin SOIC for size.

1 Like
4

That’s true, but not 100%. How many trees have You seen? If You could choose a tree, wouldn’t You take the smallest? I only know btrees and mine.

I’m not thinking big, but my floppy-disk had 1.44MB.

If You would need two trees, wouldn’t You choose the smallest tree twice?

What if the smallest tree doesn’t even look like a natural tree and more like a top-down pyramid? You’ve chosen it twice.

Our first directory, the root, is the third tree.
You may guess three times which one it was. I’ve chosen my tree three times.

For insurance, how much is two times three?
You can insert an item left, right and in between on the first level. And You can insert an item on all higher levels left, right and in between. Removal hasn’t been any problem, too.

5

Thanks for posting your solution to data persistence! Flash is a viable mechanism for data logging especially when physically accessible like in your case. I applaud you for creating your own solution.

1 Like
6

You can emulate files then for compatibility and power off Your system. :face_with_hand_over_mouth:

Thank You very much AWS.

1 Like