EEPROM Memory mapping

Basil · 2007-09-25 01:54

Hi All,

Quick question, just need to check im on the right track [noparse]:)[/noparse]

I wish to duplicate a section of variables (declared in the VAR section) to another location in the EEPROM (After $8000)

How do I determine where to start and end the copy from? I assume its using pointers (which I have no experience with just yet).

Eg, say I wish to copy from 'flighttime' through to the 3rd value in 'Pyrosuccess' in the followinhg list of variables, do I copy from '@flighttime' through '@pyrosuccess + 4'?

VAR
  long  Stack[noparse][[/noparse]100]
  byte  Cog
  word  Pyro_Test         

  long  flighttime             
  long  bGround                
  long  bAltMax                
  long  bVelMax             
  long  iGsMax                
  long  iAccMax              
  long  iVelMax               
  long  iAltMax               

  long  StageIgnitionTime  
  long  StageBurnoutTime    
  long  Apogee               
  long  PyroFire           
  long  PyroSuccess

Thanks for the help!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

deSilva · 2007-09-25 01:59

Generally correct.
But note that the variables will not always be in the order you have writen them dewn. The SPIN compiler re-orders them according to the following rule:
- LONGs first
- then WORDs
- last BYTEs

Basil · 2007-09-25 02:25

Thanks deSilva, thats what I was looking for [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Chad George · 2007-09-25 17:04

I've run into that on more that one occasion.

I understand the memory savings, but I do wish there was a way to mark a section of
variables so they aren't moved around.

Whenever I'm sharing variables between cogs (especially spin to assembly) or
trying to match a set of variables with a "C" struct for communications routines
this feature becomes a real headache.

Andy Lindsay (Parallax) · 2007-09-25 18:21

Hi Alec,

Try this demo application (Test Propeller Eeprom v0.677....zip) with HyperTerminal at·57600 8N1.· It demonstrates various ways to use the Propeller Eeprom object.· Here's its menu.· The two feature's that will do the job you are asking for are T and F.

· MENU
· C = Clear Array
· D = Display array
· M = Modify array elements
· B = Backup array to EEPROM
· L = Load array from EEPROM
· T = Copy array elements To EEPROM address
· F = Copy From EEPROM address to array elements
· W = Write individual values to EEPROM
· R = Read individual values from EEPROM
· >

Note in the Test Propeller Eeprom...spin object that the T and F menu items result in calls to ArrayToEe and ArrayFromEe.· These methods provide the indexing examples for your particular task.

I still have some work to do on the documentation, so please check back for a link to the "finished" demo.· (See PE Kit Lab Applications – EEPROM Datalogging and I2C.)

Andy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Post Edited (Andy Lindsay (Parallax)) : 9/26/2007 4:45:01 AM GMT

deSilva · 2007-09-25 19:18

Chad George said...
I've run into that on more that one occasion.

I understand the memory savings, but I do wish there was a way to mark a section of
variables so they aren't moved around.

Whenever I'm sharing variables between cogs (especially spin to assembly) or
trying to match a set of variables with a "C" struct for communications routines
this feature becomes a real headache.

You can also use the DAT area... It makes little difference except you use multiple objects.
- The advantage is you can preset values
-The drawback it takes a little bit more memory in the binary.

In the DAT section variables are padded rather than re-ordered.

Basil · 2007-09-25 21:46

Hi Andy,

Thanks for that [noparse]:)[/noparse] Ill try it out when I have a bit of time, looks good so far!

deSilva,

I was just thinking the same. The reason I want to copy to EEPROM is to protect from data loss during brownout.
As I understand it, storing my results in the DAT section would ssave them from dissapearing during a brown out?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

deSilva · 2007-09-25 21:51

No, no, no! It will just save them from being re-ordered by the compiler

Basil · 2007-09-25 22:29

Well that makes it worthwhile too [noparse]:)[/noparse]

SO if I store my runtime variables into a DAT variable, I will still need to back them up into the EEPROM (some location after $8000) but I can be certain the variables will always hold the same memory location if I re-complie the firmware?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Andy Lindsay (Parallax) · 2007-09-25 22:31

Alec,

The easiest way to protect your variables from brownout is to use the Propeller Eeprom object's VarBackup method. Try menu item B = Backup array to EEPROM. When you reboot, the values are automatically restored to the array.·

The Propeller Eeprom object's VarBackup method copies a range of values from·main RAM to the same addresses in EEPROM.· When the Propeller Chip gets rebooted, it automatically copies the entire EEPROM to main RAM.· You won't even have to call a method to restore the variables; whatever you copied with VarBackup automatically get restored to RAM when you reboot.· You can also programmatically restore it with the Propeller Eerpom object's VarRestore method.

Here are the relevant lines from Test Propeller Eeprom...spin

VAR

·· long value[noparse][[/noparse]32]

...

PUB Backup

·· eeprom.VarBackup(@value, @value[noparse][[/noparse]31] + 3)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Post Edited (Andy Lindsay (Parallax)) : 9/25/2007 10:42:36 PM GMT

Basil · 2007-09-25 22:39

Hi Andy,

Just took a quick look at your program and it looks perfect!

Any idea how long it would take to backup 100 bytes of data? Im hoping to be able to run this 128 time per second :P

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Andy Lindsay (Parallax) · 2007-09-25 22:44

I'll get back to you in a minute or two on the time it takes.

WARNING: EEPROMs wear out. I forget wither it's 1 or 10 million writes per page, but your application will get there quickly at 128 times per second.

If you have to back up that frequency, use an FRAM. Search this forum for FRAM and you will find some discussions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Basil · 2007-09-25 22:54

Theres a point, I have taken this into account with my dataflash but hadn't thought about it with the EEPROM...:\

I had considered using FRAM but couldn't get any soon enough for this project...I may look into it again [noparse]:)[/noparse] Or just backup less frequently :P

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

deSilva · 2007-09-25 22:56

The question is: Why do you need this backup rate? What will happen, when you update - say - once a second?

Basil · 2007-09-25 23:14

Hi deSilva,

The application is a high powered rocket altimeter. I will be sampling pressure and acceleration 128 times per second to determine velocity and altitude.
Im actually using pressure to determine altitude, which is NOT a function of time so thats good.

Acceleration, and hence velocity is critical to determine actual time of motor ignition and burnout for launch detection, staging events etc.

The most probable time a brownout will occur is at launch when the rocket experiences some huge G forces, and this is the time when loosing track of time is the leasr helpful [noparse]:)[/noparse]

I realise the prop will take a moment to reset itself and get up and running again, however this will take a known time and if I will able to factor the lost time into the velocity equations.
Even if the prop brownsout prior to sucessful launch detection, I will still have the velocity estimates prior to brownout which I can use [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Andy Lindsay (Parallax) · 2007-09-25 23:14

It took 42 ms to backup 100 bytes, which is only about 23 Hz. For those of you who are about to ask, yes, I am writing by 64 byte pages, which is much faster than writing individual bytes.

This spin object is delivering clock pulses at about 30 kHz. I may be able to speed it up a bit by removing some of the method calls and doing more code inline.

If you need a really fast backup to EEPROM, find the assembly version of I2C and use it. The Propeller Chip's EEPROM can be clocked at up to 400 kHz.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Andy Lindsay (Parallax) · 2007-09-25 23:17

Alec,

If it needs to be nonvolatile, use either FRAM or NVRAM. Either one should be fast enough.

Andy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Basil · 2007-09-25 23:17

Hi Andy,

Thanks for looking in to that [noparse]:)[/noparse]

I have been thinking over what deSilva said about 'why do I need such a fast backup'.

I don't believe I could get away with 1Hz, however 20Hz might be enough.
Im tossing up wether I can afford to loose 50ms of data and get away with it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Andy Lindsay (Parallax) · 2007-09-25 23:23

I would recommend declaring a really large array to collect the values and then backup as fast as possible in a different cog. The cog can chase after the data as fast as it can. Your data can then be at a predictable sampling interval.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Mike Green · 2007-09-25 23:29

Alec,
What Andy suggests is particularly useful since most EEPROMs have a page write mode where 64 or 128 or 256 bytes of data can be written in one write cycle (depending on the specific EEPROM device type). The data has to be on the appropriate byte address boundary, but the "backup" cog can handle that ... copying the data in appropriate size blocks and doing the write cycle timing. Most EEPROMs will notify you when they're finished writing by responding to a read request and ignore you otherwise.

Basil · 2007-09-25 23:37

Hi Andy,Mike,

This sounds similar to what Im doing with my dataflash data
ie filling up the 528byte DF buffer with 2x12bit ADC readings) before copying to the main page memory.

Only thing I can think of causing a problem is, what If my array is nearly 'full', (ie just about to copy to EEPROM) and a brownout occurs?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Mike Green · 2007-09-26 00:11

If that (a brownout) is important, use a large enough electrolytic capacitor across the regulator output to keep the Propeller functioning for a substantial part of a second and use an I/O pin to measure the unregulated input to the 3.3V regulator. Best is to use a voltage divider. If the input to the 3.3V regulator is from a 5V regulator, divide the 5V down so you get about 1.5V when the input to the 3.3V regulator is about 4.5V. Tie that to a Propeller I/O pin. It will normally be high. As the input to the 3.3V regulator drops below 5V, the I/O pin will go from high to low indicating that power loss is emminent and your backup cog can write what it has and everything else can come to an orderly halt waiting for the expected power off to occur.

You'll have to figure out how to recover when the power comes up again.

Basil · 2007-09-26 00:25

Hi Mike,

Thats a good idea about using an io pin for Brownout detection. I will have to implement it in the next PCB revision [noparse]:)[/noparse]

I have put in a 1000uf cap prevent brownout from the pyro's firing, it wasn't until after the board was made that I though about power loss during high G's [noparse]:([/noparse]

For the next version of the board I have shifted the 1000uf cap to help prevent this [noparse]:)[/noparse]
I still need to get the software backup working just incase a brownout does happen [noparse]:)[/noparse]

I have an algorithim swimming aorund in my head about recovery after brownout (thanks to Andy'd VarBackup object [noparse]:D[/noparse] )

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Sapieha · 2007-09-26 00:26

Hi Basil

http://www.panasonic.com/industrial/components/capacitive/cap_gold.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.

Sapieha

Basil · 2007-09-26 00:30

Hi Sapieha,

Thanks for the link [noparse]:)[/noparse]

I had looked at these capacitors when designing my PCB (theres actually one of my threads a while back about the harware prevntion of brownout) and unfortunatly can fit one on the board [noparse]:([/noparse]

The 1000uf SMD cap from panasonic I have used will do the trick though [noparse]:)[/noparse]

Just working on a software backup now as extra security against data loss [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Basil · 2007-09-26 04:47

Hi Andy,

Just saw your update, nice work [noparse]:)[/noparse]

So if I understand this correctly, to backup the following list of variables (a combination of longs and words) I would call the following:

eeprom.VarBackup(@flighttime, @DF_Next_Flight + 1)

The +1 being because the smallest variable I have are words. If I had only longs it would be '+3'

  long  flighttime  
  long  bGround   
  long  bAltMax    
  long  bVelMax   
  long  iGsMax     
  long  iAccMax    
  long  iVelMax    
  long  iAltMax     
  long  StageIgnitionTime [noparse][[/noparse] 3 ]  
  long  StageBurnoutTime [noparse][[/noparse] 3 ] 
  long  Apogee                  
  long  PyroFire [noparse][[/noparse] 3 ]             
  long  PyroSuccess [noparse][[/noparse] 3 ]       
  word  Pyro_Test [noparse][[/noparse] 3 ]          
  word  DF_pre_launch_start
  word  DF_next_flight

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Andy Lindsay (Parallax) · 2007-09-26 04:49

Thanks Alec,

Yes, that'll do it.· When you reboot, the values stored in the variables at the time you called eeprom.VarBackup will get loaded back into those same variables.· The trick was to declare the longs first, and then the words (and then bytes if you had some, in which case you would be adding 0 to endAddr instead of 1).

Andy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Post Edited (Andy Lindsay (Parallax)) : 9/26/2007 4:55:55 AM GMT

Basil · 2007-09-26 04:53

Cool thanks [noparse]:)[/noparse] This fits perfectly!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Basil · 2007-09-26 22:05

Hi Again [noparse]:)[/noparse]
Lets say I have the following variables and I DON'T want to backup 'cog', which is the first byte sized variable.

VAR
  long  Stack[noparse][[/noparse]100]
  byte  Cog

  long Blah1
  long Blah2
  word Blah3
  long Blah4
  byte Blah5
  word Blah6

As I understand it, they will be in RAM in the following order:

long Stack
long Stack
...
long Stack[noparse][[/noparse]100]
long Blah1
long Blah2
long Blah4
word Blah3
word Blah6
byte Cog
byte Blah5

Correct?

How do I not backup Cog? Do I have to do two separate VarBackups?

Sorry to be a pain [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Andy Lindsay (Parallax) · 2007-09-26 22:20

Alec,

Either declare them in long, word, byte order, or do separate calls. In a difficult scenario where your code is depending on objects that require variables to be declared in groups and in a particular order, you can set up a lookup table of address ranges and use a loop to backup all the ranges.

Andy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Basil · 2007-09-26 22:27

Hi Andy,

Thanks for the speedy response!

I don't have too many crazy ones, so 2 or 3 separate calls wont be too hard :P

There are not enough out of order variables to justify a lookup table...and besides, ive never done one before :P

Thanks [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

EEPROM Memory mapping

Comments