Strategies for persistent storage of calibration data.

Phil Pilgrim (PhiPi)

I've designed a Propeller PCB that has two channels of sigma-delta A-to-D. Because their accuracy depends on the digital threshold of the Propeller's inputs, it's necessary to calibrate each channel, based on inputs of 0V and 3.3V. The response is very linear in between, as the following graph shows:



Once the endpoints are determined, it would be nice to store them in EEPROM persistently, so that programs that use A/D can access them. Unlike the BASIC Stamps, though, when a program is loaded to the Propeller's EEPROM, the entire EEPROM is written, not just the portion containing code or allocated variables. This makes the persistent storage of calibration settings impossible with a 32K EEPROM.

Aside from using a larger EEPROM, what strategies have you concocted for overcoming the lack of EEPROM persistence between downloads?

Thanks,
-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!

Erik Friesen

I like running a second cog that updates a fram on demand or every second starting at a given point in memory like this.

long cal1,cal2,cal3,cal4

then use a
12c.readlong(@cal1,4)
on startup.

When your calibration changes you update like this
12c.writelong(@cal1,4)

It makes it pretty seamless.

JasonDorie

I needed to do this to store user settings for the PID loops on my quad-copter thing. I just put initial values in the DAT section and read them into local vars on startup. To make them persist, when the user changes them, I take the hub address of the DAT values, then use the Basic I2C object to write them back into the EEPROM at the hub address. Since the EEPROM is loaded on startup, the values 'automatically' persist.

Pseudo code:

PUB Main | LocalVar
· LocalVar := DatVar
· repeat
··· PIDFunction( LocalVar )

PUB WriteGlobalToEEPROM
·· I2C.Write( @DatVar, DatVar)·· 'this MIGHT be @@, but I think it was just @

DAT
· DatVar··· long·· 10


Edit:
I just re-read your post, and you're talking about multiple programs accessing the same data after reloading the EEPROM with new code, which this code certainly doesn't address.· Ignore me.· [noparse]:)[/noparse]


Post Edited (JasonDorie) : 10/27/2008 11:27:27 PM GMT

agodwin

Phil Pilgrim (PhiPi) said...

Aside from using a larger EEPROM,

I used exactly that. Is there some reason to avoid it ?

BTX

Once I used another eeprom in parallel with the first one, and with another address.
I leave the last one, to store the initial config data.
And I provided to the customer, more software programed eeproms for reserves.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.

Alberto.

Phil Pilgrim (PhiPi)

The board is laid out for an 8-pin TSSOP EEPROM. As it turns out, I've been laboring under the mistaken notion that these are available with capacities only up to 32KB. While this may be true of the low-power 24LC family, Atmel makes a 24C512 in this package. Current consumption is about five times that of the LC variety, but it's still pretty low. If these work — and if there's a reliable supply of them — it could solve my problem. If not, I'm still interested in strategies that do not involve extra memory.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!

Paul Baker

If your design calls for a timekeeping chip, get one with persistent storage. Alternatively you could use a very small serial eeprom (like the 24LC00 which has 16 bytes of storage). Though devices that small don't have the address select pins, which makes it difficult to sshare the bus with a larger chip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

hippy

How about a dedicated downloader which won't overwrite the top end of Eeprom ? It's not perfect, adds awkwardness but doesn't require additional hardware.

Not programming/clearing all of Ram/Eeprom would be something useful to have built into the Prop II on-chip downloader.

Beau Schwabe

agodwin,
·
"Aside from using a larger EEPROM,...·· ...I used exactly that. Is there some reason to avoid it ?" - There is no danger in using a larger EEPROM as long as it is backwards compatible with the current 24LC256.· In fact that's how I would probably approach Phil's dilemma.
·
If you don't go with a larger EEPROM (<--stay within the 24LC256) and your program writes to an unused memory address for storage this is perfectly acceptable.· The problem however arises when you download or update the·program... The Propeller IDE will overwrite and clear out the "unused" (<- as far as the IDE is concerned) memory address that you were using for storage from within the program.· A normal Propeller reboot should retain any self modified·memory, it's just the·IDE that will wipe it out during a re-program.
·
Using a larger memory, and writing to an area beyond the 24LC256 boundary for your program storage is the safest way that will not be affected by the Propeller IDE updating a program.
·
There is a thread here that discusses larger memory alternatives that are compatible with the Propeller.·

http://forums.parallax.com/showthread.php?p=625799

·

Note: Adding a larger EEPROM·does not increase program space, but only scratch pad memory available for your propeller program to use.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 10/28/2008 2:51:24 AM GMT

Phil Pilgrim (PhiPi)

I'm going to try the Atmel AT24C512, but I'm a little leery of supply issues with this chip.

Another idea that came to mind was to do the calibration under control of a PC host program that writes the calibration data to a special Spin object containing just constants and a null Start routine. This object would be referenced by the ADC object, so the constants would be loaded into the EEPROM every time a new program using the ADC is loaded. The downside, of course, is that it will work with only one board. If a person is using multiples of the board, they would all get the same calibration data — not the desired outcome.

Hippy's special loader idea has merit and, in fact, I've written a bootloader for this board that can load programs via a BASIC Stamp. This EEPROM-resident loader could easily be modified to include room for some additional constants. But the board also includes a header for a Prop Plug, so it would be easy for the bootloader to get wiped out, taking the calibration data with it.

-Phil

Addendum: For those who, unlike me, have just a little extra room on their boards, Microchip has introduced their UNI/O serial EEPROMs, available in an SOT-23 package. (For my board, one of these would be the equivalent of the "wafer-thin mint" from Monty Python's The Meaning of Life.)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!

Post Edited (Phil Pilgrim (PhiPi)) : 10/28/2008 6:28:06 AM GMT

Ken Peterson

The Protoboard has the AT24C512. What kind of supply issues are we talking about?

The Microchip product sounds interesting. Has anyone done an object to use the UNI/O bus?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."

- Bjarne Stroustrup

Javalin

Put another 32k EEPROM on top of the main one. Solder the pins to the same existing pins, except for one address pin. Put a wire over the top to pull one of the address pins to VDD. Then use the new EEPROM to store your data

James

simonl

IO guess you could always provide an object for the user to include? This object would contain a DAT section with your calibrations. User would just have to remember to reference it

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon

---

www.norfolkhelicopterclub.com

You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style

Phil Pilgrim (PhiPi)

Ken,

Thanks for the heads-up regarding the Protoboard. I hadn't realized that Parallax was using the Atmel part. That gives me some reassurance that there's an adequate supply in the pipeline, which is always a concern with single-source components.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!

Post Edited (Phil Pilgrim (PhiPi)) : 10/28/2008 5:17:05 PM GMT

Bill Henning

Hi Phil,

For the application I am working on, I am using an SPI 8Mbit flash - uses 4 I/O's, but MUCH faster & bigger than the eeprom.

Best Regards,

Bill

Phil Pilgrim (PhiPi) said...
Ken,

Thanks for the heads-up regarding the Protoboard. I hadn't realized that Parallax was using the Atmel part. That gives me some reassurance that there's an adequate supply in the pipeline, which is always a concern with single-source components.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

agodwin

Phil Pilgrim (PhiPi) said...
Ken,

Thanks for the heads-up regarding the Protoboard. I hadn't realized that Parallax was using the Atmel part. That gives me some reassurance that there's an adequate supply in the pipeline, which is always a concern with single-source components.

-Phil

They're not single-source : Microchip do one too.
Not in the same package options as the Atmel one, might be a problem if you're committed to TSSOP.

Phil Pilgrim (PhiPi)

Yeah, it has to be TSSOP-8, due to board size. Microchip's 24LC512 comes in a TSSOP-14, but not in the smaller 8-pin TSSOP.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!