Storing and updating global variables for use between power cycles

[britch...@gmail.com]

I am in need of a global variable(s) to store encoder data on a few motors that I have attached to my beaglebone. In the event of a power down, I need to be able to recall the last encoder position (since it is not absolute) of a particular motor. I would like to find a few free memory bocks on the eMMC and send a streaming update to it as the motor moves.

Any suggestions?

Thank you!

[Dennis Lee Bieber]

On Fri, 15 Nov 2019 13:35:22 -0800 (PST), in
gmane.comp.hardware.beagleboard.user

The eMMC contains a /file system/ -- one does not access raw blocks.

Open a file in modify mode;
loop
write the set of encoder values;
flush the file;
seek(0)...

or maybe mmap with a backing file, as that would allow writing each encoder
as it is moved, rather than all encoders at once.

https://linux.die.net/man/2/mmap
https://linux.die.net/man/2/msync

Note that both (file/flush/seek and mmap/msync methods will invoke a
lot of flash memory write overhead as everytime you change a value the
flash has to allocate a new/erased block, copy unaffected data to it, write
changed data...

Also note that on unintended power-down, you risk corrupting the file
system with partial writes... With luck the journal will catch these and
allow reasonable recovery.

--
Dennis L Bieber

[gra...@flex-radio.com]

Also note that the eMMC is a device whose life is limited by the number of writes. 

If this is something that is intended to operate for multiple years, then you will need 

to limit the number of writes to the eMMC to the minimum necessary.

If you really need a lot of realtime write updates, you might want to consider something 

like a small FRAM memory peripheral for the motor/control position memory, rather

than the eMMC.  FRAMs, since they are magnetic RAMs, retain the memory without

power, with almost unlimited write cycle life.

--

[bryan.r...@gmail.com]

Something that can be stored and called upon at boot time to be used in a main python function

[gra...@flex-radio.com]

Hi Brian:

It is the number of writes, not the reads that I was concerned about.

You used the phrase "send a streaming update to it as the motor moves" in your initial email.

If you are continuously doing writes to the eMMC, then that is a long term concern.

If this is just a short term demonstrator, then no problem.

If this is a real product, then there are anecdotal reports of users killing the BeagleBone's eMMC after a few years of logging.

For a real good example, (of eMMC wearout, not a BeagleBone issue) read:

https://insideevs.com/news/376037/tesla-mcu-emmc-memory-issue/

https://www.businessinsider.com/older-teslas-reportedly-having-issues-charging-screen-not-working-memory-2019-10

If you need a small, almost unlimited write memory that remembers with the power off,

try something like an FRAM.

Example of a small development board:

https://www.adafruit.com/product/1897

Spec sheet says good for a trillion write cycles.

Beware buying a used Tesla. :-)

--- Graham

==

[britch...@gmail.com]

All,

Thank you for the suggestions. I will definitely steer clear of constant writes to the eMMC. Thank you Telsa for learning the hard way for the rest of us!

In this case, I would opt to use an SD card to accomplish this. Would mmap or msync still be the best methods to do this?

Bryan

[Robert Forsyth]

I think the serial FRAM are worth a look https://www.mouser.co.uk/ProductDetail/Cypress-Semiconductor/FM24C04B-GTR?qs=pA5MXup5wxHImxHM%2FSs%2FSw%3D%3D#.XdRK3KU7s1g.link

[britch...@gmail.com]

Robert,

Yes, definitely a good suggestion. However, not feasible to incorporate into the design at this time, we have developed a cape already and left this minor detail out (oops!). Moving forward, however, this is a great option.

[Dennis Lee Bieber]

On Tue, 19 Nov 2019 11:44:17 -0800 (PST), in
gmane.comp.hardware.beagleboard.user

britchie.ipa-Re5J...@public.gmane.org wrote:

>
>In this case, I would opt to use an SD card to accomplish this. Would mmap
>or msync still be the best methods to do this?
>

Presuming a formatted file system... mmap (and periodic msync to force
memory to device -- how much "loss" can you absorb on a restart?) should be
somewhat simpler than regular file I/O operations. The mmap'd file will be
addressed as RAM storage -- so you can readily update single values in the
"array" of memory. File I/O requires tedious seek and write operations.
--
Dennis L Bieber

[Jim F]

I think the classic way to deal with this kind of situation is to attempt to monitor input voltage and detect an impending brownout, and THEN write out your state, instead of continuously. This lets you gracefully shut down your processor as power goes away, without risking your EEPROM write cycles (though the FRAM is a nice way around). TI have a little bit of documentation about handling brownout (https://www.ti.com/lit/pdf/slva901) which are interesting reading but don't cover your exact case. But I bet the power controller IC can detect it with existing hardware, only software mods, maybe. It's worth reading the datasheet to see.

I've implemented something like this in the past by measuring voltage on both sides of an input filter feeding the micro, for lower power devices. Probably a bit too fast and lossy here. Plus you'd need more hardware.

Good luck.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/84e36ae9-91db-44fb-a320-e55781596f2d%40googlegroups.com.

[Indiaaditya Networks]

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAGS%2B2h-jxtp7N4G%2BRVQvbKAzYHD4%2Ba95aZUBM_FNnkpoUkJm5Q%40mail.gmail.com.

--

Indiaaditya Networks.... Embedded System development
For industries customised needs

[Indiaaditya Networks]

Hi all,

I think writing to the memory by monitoring voltage has it's limitations. For a small project there is a limited time available and there are only these many tests that one can have when testing the instrument developed. So writing continuously should be implemented.

In a similar situation but on a different platform, we had implemented i2c implementation of the IC PCF8583. This is an RTC with 256 bytes of RAM. Battery backup is ofcourse essential but number of writes is virtually unlimited and write time is very small.

Double advantage was we had real time as well as RAM storage. Will not work if you have larger number of bytes to store.

Kind regards,

Aditya Ayachit

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/89764a0c-2f86-45df-bd61-ad1ee8013651%40googlegroups.com.

[gra...@flex-radio.com]

Or, another simple way to get around eMMC wearout is to run from the microSD card, rather than the eMMC.

Buy an oversize, quality, microSD card, such as a Samsung, with a good internal wear leveling mechanism.

It is getting hard to find quality ones smaller than 32 GB these days.

Even though you are repetitively writing to the same "address location", the wear leveling mechanism is moving it around internally, every time you write, and remapping.

So, a 32 GB card should last about eight times longer than the 4 GB eMMC.

Go bigger if you are still worried.

--- Graham

==