Basic 32k EEPROM question from someone new

iQuit

Basic question from someone just starting with the Propeller--I love this thing.

I know that the Propeller loads everything from the EEPROM during boot up or after reset. If I were to load a small program that doesn't take all
of the EEPROM's space, can I use the rest of the EEPROM for some data storage?

And if I do, will that data exist after a reset/reboot? (Baring any funny business during a read/write sequence.) Basically, I simply want to use the
EEPROM to store system settings for the device that the Prop is controlling. Nothing vary large, just a few bytes.

If this does work, or is allowed, where should I store my data?

This brings up another question... where is a source for learning about memory storage? FAT 32 and all of that is all a bit confusing. Do I simply
address the memory locations starting at zero and go all the way to the end -1 of the device?

Thanks from the start

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

hover1

If you were to to do an F11 (Load to EEPROM) it would load the program into the area that is needed and load everthing else up to 32K with zeros. If you were to use a 64K device, then you could use anything over 32K for your storage.

Jim

Peter Jakacki

Obviously it doesn't matter what you do with memory that is not being used. There have been quite a few threads where it has been shown that you can use a EEPROM object and simply write the value of your normally volatile variable back into the variable's image in EEPROM.
Assuming you have the object referenced as I2C and the write long method is EEWR then you could say:
i2c.eewr(@myvariable,myvariable)
Where myvariable is written to the address pointed to (same in both RAM and EEPROM) using the @ symbol to the EEPROM as a long. On boot ALL the 32K of RAM is written to from ALL the first 32K of EEPROM and so too the contents of myvariable.

I will have to check the obex for an exact object and method but this is what I do.

Mike Green's Basic_I2C_Driver should work obex.parallax.com/objects/26/
Use this method:

WriteLong(SCL, devSel, addrReg, data)

like this (assuming object = I2C )

i2c.WriteLong(SCL,$A0,@myvariable,myvariable)

Where SCL is actually 28 for the boot EEPROM.

Anytime you update a variable or when you want to lock it in you just simply call it like this. You may need a few milliseconds delay before writing any new variables to allow the EEPROM time to burn it in. Some other objects poll the EEPROM correctly before trying to write this but I am trying to keep it simple for you at present.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

Post Edited (Peter Jakacki) : 4/16/2010 2:12:56 AM GMT

iQuit

Hover1,
The EEPROM is only written to during F11, right? So, if I don't reload EEPROM, I don't have to worry about over-writing my data, right? Load it once, and go!
What is the difference between locations of a CON and a VAR; EEPROM vs RAM? Or are they both put into RAM at loading?

Peter,
I'm a little new at all of this Propeller stuff, so most of what you said went over my head. But I will get this stuff, eventually, even if it kills me.

I'm looking for a way to store a couple of bytes that won't get lost during a brown out, or power loss. My program is going to be small, so I thought
that I might sneak the bytes near the end of the EEPROM when no one was looking.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

Peter Jakacki

See my amended previous post for some more details. Yes, if you F11 then you wipe it all out (which you may want to anyway) but this way keeps it simple.

CONs are simply for the compiler itself and the run-time image only uses the actual value of the constant so it is not referenced as a symbol that can be changed globally at run-time.

VARs are of course your variables in RAM, the address of which is assigned and allocated at compile time. Usually you don't need to know the actual address. The EEPROM image that is loaded normally has zeros in the allocated locations that are copied into RAM so that all variables are in fact initialized at reset. There is no facility that I am aware of that allows you to specify the initial contents of the variable at compile time which could be handy sometimes.

P.S. no need to sneak

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

iQuit

Thanks Peter, that helps.

Looks like I can use the object to write to the Propeller's EEPROM. Is $A0 the device address for the boot EEPROM? How does one use more than one
EEPROM? Can I use a larger one in my design and use the extra space beyond 32k?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

Peter Jakacki

Here is some advice, don't complicate things, at least just yet. You only needed to backup a few variables and the method outlined can backup ALL you variables so what more could you want for most programs? The first 32K of EEPROM is always loaded into RAM so it is very easy to deal with but more than 32K requires special "variables" and methods to read/write from EEPROM each time they are referenced.

But yes, of course you can use a larger EEPROM, the devices normally have a base I2C address of $A0 which can be hardware modified through three external "address" pins so that you can have $A0, $A2, $A4, $A6, $A8 ,$AA, $AC, $AE. The lsb of the address field indicates an I2C read or write operation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

HollyMinkowski

There is a chip that can replace the eeprom chip and which has
more and faster non-volatile memory, a real time clock and the ability
to protect your code from snoops. I can't think of the name of this chip
or who makes it. Perhaps someone will add that info if they see this post.

Peter Jakacki

Not sure what you are saying Holly, you know that it can't be secure if it's I2C access, anything can talk to it just as the Prop does at boot, it needs free and unsecured access. I suppose it is possible to secure another area of the EEPROM though but that's only part of the security solution.

I hope you don't tell jokes and leave the punchline for someone else to fill in too

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

MagIO2

My understanding is that you have a config-file that you want to store in EEPROM. So, why not use the import instruction - is it called file? Never used it myself. It loads the file into a dat-section during compile. This way the data is not deleted by F11. No need to use basic_i2c as long as those configurations don't change during runtime.

But to be honest ... all parameters of the device that you really need, have to be somehow present in the code. So, why not put it there? Common way to do that is use CONSTANTS to define the settings and later on have code that uses these CONSTANTS.

For example:
CON
' definition of IC xy constants and strings
xy_BASE_PIN = 8 ' the device is connected to pins 8 - 12
xy_IO_MASK = %11001 ' the I/O mask defines which pins are input and which are output
xy_MAX_FREQ = 10_000 ' this is used to calculate the variables for the timing
xy_WHATEVER = 42

' another sort of constants can be build by the already defined constants
xy_DIRA = xy_IO_MASK << xy_BASE_PIN

DAT
xy_ACK_STRING byte "ACK",0

VAR
long pulse_clocks, pause_clocks

PUB Init_xy
pulse_clocks := _clkfreq / constant ( xy_MAX_FREQ << 1 ) ' <<1 multiplies the freq by 2, so pulse_clocks + pause_clocks sum up to the needed clock frequency
pause_clocks := _clkfreq / constant ( xy_MAX_FREQ << 1 ) ' with different calculation you could also have other pulse/pause ratios
' with the constant() the calculation of this part is done during compile-time and does not waste runtime and memory

HollyMinkowski

Here is info on that chip....looks interesting, I have not used one yet but I'm going to get around to it.
www.ramtron.com/products/integrated/processor-companion-product.aspx?id=29

High Integration Device Replaces Multiple Parts
• Serial Nonvolatile Memory
• Real-time Clock (RTC)
• Low Voltage Reset
• Watchdog Timer
• Early Power-Fail Warning/NMI
• Two 16-bit Event Counters
• Serial Number with Write-lock for Security

Ferroelectric Nonvolatile RAM
• 256Kb
• Unlimited Read/Write Endurance
• 10 year Data Retention
• NoDelay™ Writes

Real-time Clock/Calendar
• Backup Current under 1 µA
• Seconds through Centuries in BCD format
• Tracks Leap Years through 2099
• Uses Standard 32.768 kHz Crystal (12.5pF)
• Software Calibration
• Supports Battery or Capacitor Backup
• Underwriters Laboratories (UL) Certification

Processor Companion
• Active-low Reset Output for VDD and Watchdog
• Programmable VDD Reset Trip Point
• Manual Reset Filtered and Debounced
• Programmable Watchdog Timer
• Dual Battery-backed Event Counter Tracks System Intrusions or other Events
• Comparator for Early Power-Fail Interrupt
• 64-bit Programmable Serial Number with Lock

Fast Two-wire Serial Interface
• Up to 1 MHz Maximum Bus Frequency
• Supports Legacy Timing for 100 kHz & 400 kHz
• Device Select Pins for up to 4 Memory Devices
• RTC, Supervisor Controlled via 2-wire Interface


Easy to Use Configurations
• Operates from 2.7 to 3.6V
• 14-pin “Green”/RoHS SOIC package (-G)
• Low Operating Current
• -40°C to +85°C Operation

Post Edited (HollyMinkowski) : 4/16/2010 8:32:08 AM GMT

KPR

Darco posted code in the obex Settings to do this, but they will get overwritten when you apply a new code to the eeprom.. or at least in the first 32k block

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New ICON coming, gotta wait for the INK to heal, now we have colour!

Post Edited (KPR) : 4/16/2010 1:46:14 PM GMT

Oldbitcollector (Jeff)

@Holly,

Those ARE pretty cool.. Any chance you've seen a source for a DIP version?

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered? PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.

iQuit

@ KPR
Settings looks promising, but much more than I need. I only need to store a couple of bytes that will hold up to power cycles. Once the device is up and
running, I won't be re-loading EEPROM, but power may get cycled now and again. The main program is small, so there should be plenty of room available
in the existing EEPROM. I think. I'm still quite new at this propeller thing.

Thanks for the reply.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

Peter Jakacki

OBC, those chips are only in smd as far as I know (RAMTRON only seem to make smd) and they are about 3 times the price of an RTC+EEPROM combo. They are also single-source, have a long lead-time and are very low in stock.

Here is one source though that has a little stock www.onlinecomponents.com/buy/RAMTRON/FM31L278-G/

If they were cheaper, more plentiful and second sourced I would probably use them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

KPR

iQuit.. then if all you need is a few bytes.. just do direct reads and writes to the eeprom starting at the 32k and working backwards... any i2c library in the obex will do that for you, and you should be fine..

k.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New ICON coming, gotta wait for the INK to heal, now we have colour!

Peter Jakacki

I have quite a few products that save settings and they all use the i2c.write(@myvariable,myvariable) method. This is the simplest and most elegant solution for most systems. I am very surprised that these other kludgy suggestions have been made. Why bother with complicated methods or explicitly reading from the EEPROM as well? There is just no need for it.

Just remember iQuit, the "Dope-slap! Doh!" Don't complicate it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

iQuit

Yes, I'm trying very hard to keep it simple--that's all I know right now. As I said, I'm new to the Prop. Had some Basic Stamp experience.
Any suggestions on which I2C object to use? Keeping in mind that we want to keep it simple.

Thanks again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

parts-man73

One thing to remember, which may or may not be an issue in your situation. But you can only write to EEPROMs have a finite number of times before it may fail. At first you may think this is not possible because that most have an "endurance" of over a million write cycles. But if you have a loop in your program, and it writes a value on every iteration of the loop, that could easily surpass a million writes in a very short time.

There are various ways of avoiding this. I once made a thermostat to replace a defective control on a walk-in freezer. I wrote the current thermostat setting to EEPROM so that if power was interrupted, the setting would be remembered when it was powered up again. I simply did an EEPROM read, and compared the saving setting to the current setting, then only write the value to the EEPROM if there is a change in the value.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian

uController.com - home of SpinStudio - the modular Development system for the Propeller

PropNIC - Add ethernet ability to your Propeller! PropJoy - Plug in a joystick and play some games!

SD card Adapter - mass storage for the masses Audio/Video adapter add composite video and sound to your Proto Board

Peter Jakacki

One million cycles (minimum) ......let's see. Write to it 100 times a day every day and that's over 27 years before you get to the minimum endurance. Once you have a figure always do your maths.

Settings don't change by themselves and most settings are operated initiated. Unless it's a design for Spacely Sprockets and you've got George Jetson there pressing the button every two seconds I don't think it will ever be an issue. Anyway, the EEPROM has greater endurance than George's button finger.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

iQuit

Yeah, I'm not worried about wearing out a $2 item. And it's not system critical anyway.
The values won't be over-written very often, so I'm guessing 50+.

@ parts-man73: The situation is very similar to your thermostat. Mostly, the value won't change. When it does, I'll write to EEPROM and that way when
the power cycles, I have the last saved value.

I'm currently looking into this memory thing; cog RAM vs SYSTEM RAM vs EEPROM. It kind 'a gives me a headache. But, I will persist, for I will never Quit!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

Peter Jakacki

No headache, just break it down like this:

Hub RAM is shared RAM which any cog can access but slowly as it's shared. There is also hub ROM as well.

Cog RAM is each cog's memory, it's total memory really. Imagine 8 separate CPUs each with 512x32 of RAM being it's total memory. All registers excluding the PC are part of this memory, all instructions, all data, are part of this memory. Now join all these CPUs together through a special address/data bus into one common hub memory, both RAM and ROM, that's the Propeller.

Now the EEPROM is not really processor memory, it's more like a peripheral or more like what a disk drive is to a PC. The PC can run a small boot program and load it's main program from the disk just as the Prop runs a small boot program to read in from a more convenient EEPROM chip. The EEPROM is not actually required once the Prop has booted but it can be used for storage just like a disk drive.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

iQuit

Cogs have 496 x 32 each. I'm looking in the manual. Special purpose registers make up the remaining longs.
I've been studying!
Something I'm not quite clear on... I know the program is loaded into a cog, and run from the cog, so VARs and CONs also reside here? Or, do those get
put into main RAM? No, 'cause it would take too long to read/write to those locations each time code used it; something about cog-hub interaction.

So I assume the only time you use main RAM is when two separate cogs need to share the same variable? Is this where you use the @ or @@ symbol?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

Peter Jakacki

Actually it is 512 x 32 but the registers shadow the last 16 locations, it's a technicality.

You keep saying CONs reside somewhere, they don't, they are symbols for the compiler which runs on your PC. They compile the actual value into the code at compile time, they don't exist as a symbol in Prop memory anywhere. For instance if I say in the CON section that CR = 13 and then I say tx(CR) the compiler will compile tx(13), do you get it?

Variables only exist in HUB RAM because this is SPIN code which is interpreted from a COG that gets loaded up automatically at boot with a SPIN code interpreter from the ROM. It is actually creating a virtual machine that understands SPIN byte code from which other cogs can be launch either as PASM cogs or as SPIN cogs. Every-time you might say cognew(MySpinMethod,@MyStack) it is actually loading the next free cog with a SPIN byte code interpreter and telling it to start executing MySpinMethod using an area of HUB RAM for it's high-level stack.

So the Prop chip is not only 8 cogs in one chip it is also a virtual machine (VM) built on this architecture. At boot time each cog is brain dead, no program, no nothing, it is up to a hardware "boot sequencer" (not the same as the software boot sequence) as part of the central hub logic to make things happen by loading up cog 0 with some code from the ROM and letting it do it's thing. This bit of hardware is not described anywhere that I know of but I know more than enough about digital logic and CPU architecture to know that this bit of hidden special-purpose hardware is necessary. Chip could enlighten us on this if he chooses to.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

iQuit

Thank you Peter,
You've been so helpful.

So, variables are not part of the cog RAM? Once the cog is loaded and the program is running, it must wait its turn at the hub to change a variable?
Do I have that right? I thought that I read somewhere that growing variables in a cog's RAM can cause strange behavior; or rather, additional variable
expanding beyond the cog's RAM size. Still trying to wrap my head around this stuff. It's been 10 years since I took all of those classes.

And I do remember reading about a CON being configured during compile time. Should have remembered that.

What about those @ symbols?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

gopalsvs

need to keep up watching one variable which is incremented by some logicin program

so me taken a varible and incrementing it

as it is a varible and it will store ram it is volatile but i want that variable as non-volatile i mean
how to declare a varible in rom permenetly when the device is powerd on/off multiple times the varible count should not start with zero it should start with its previous incremeant
please help me regarding this

lardom

iQuit, I am finishing an app which saves a few bytes. I learned from Peter that a variable address is the same in ram and rom. The simplest object I've seen that does this is BS2_Functions. I think I found it in the obex. If, for example, I have a variable named "distance" (which I do) I can simply write
BS2.Write_CodeMem(@distance,distance). Pretty simple. I'm finding other ways to use it. I don't worry about wearing out my eeprom because I write a statement before the 'write' command that says "if distance <> distance...· it stops unnecessary writes.

iQuit

BS2 functions? Is there a way to do it with spin? Trying to ween myself off of BS2. Just kidding.
In that example, BS2.write_codemem(@distance, distance), what do you put in place of distance. Or, is that the name of your variable?
And I'm still confused about that at symbol (@). Once I've used it I'll get it, I'm sure.
Maybe with more info about your app and how you are using the Write command, I would understand more.

Thanks lardom

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"She may not be very pretty now, but she was somebody's baby once." Bugs Bunny

lardom

Yeah, it's spin. It's late in NY where I am so I'll post it after I wake up. Don't let "BS2" put you off. It uses Mike Green's i2c object. I just just think it has a simple interface. Before I read a post by Peter Jakacki, who is one of the more knowledgeable people in this forum,·I was using hex addresses which·I also learned from him. (I learned both ways from him) I use a 4x4 keypad in my project and I've coded it so that the values are saved when I press the "A" key.

Peter Jakacki

iQuit, I mentioned Mike Green's object in an earlier post, it's there.

When you want to read or write or perform an operation on a variable's contents you simply invoke it's name. Now if you want to tell some other function about a variable you need to pass the address of the variable rather than the variable's contents. This is what the @ operator does. Say if I wanted to print out a byte array or in other words a string I would need to point to the start address of the array rather than simply reading the first element of it. Here's a Hello World demo assume a tx function to display the characters.

DAT
MyString  byte  "Hello World",0

pub demo
   type(@MyString)

pub type(address_of_string)
  repeat while byte[noparse][[/noparse]address_of_string) <> 0     ' a null terminates a string so continue while it's not a null
     tx(byte[noparse][[/noparse]address_of_string++]                   ' send out string a byte at a time to tx method and post increment the pointer

' OR in the more usual fashion

pub type(stringptr)
'' Send string                    
  repeat strsize(stringptr)
    tx(byte[noparse][[/noparse]stringptr++])

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

lardom

iQuit, I attached the program I used to test the eeprom method. I noticed you have another post about LCDs. I hope you also have a 4x4 keypad. If you like portability this should help. When I first considered adding a settings feature to my project I bought an SD card adapter. Peter explained that you could write directly to the eeprom as well as how to do it. I listened and learned. He is very advanced and very willing to share his knowledge. I am proof.

Post Edited (lardom) : 4/17/2010 4:47:50 PM GMT