basic question (eeprom)

roberto · 2006-04-26 18:11

Lets say if i use the write command to log data to the eeprom while a program is running.

DO i have to write a separate program to retrieve the DATA stored using read commad?

when i retrive the data the initial program will be lost?

So i have to rerun the main program once again? so my logging continues?

I cant seem to get the answers to these questions in anything i read....

i know its basic but have to figure this out before i continue thanks

·

SSteve · 2006-04-26 18:46

If you're storing the data in the Stamp's onboard EEPROM then, yes, it will get erased when you upload a new program. You would either need to make your retrieval routine part of the same program as the logger or store the data on an external EEPROM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

Chris Savage · 2006-04-26 18:56

If the data is at the lower memory addresses and your new program doesn't over-write that part of the EEPROM then you should have no problem getting that data from the BASIC Stamp EEPROM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

SSteve · 2006-04-26 19:05

Oops. Sorry. I thought the entire EEPROM was erased every time a new program was downloaded. My apologies for the bad info.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

Chris Savage · 2006-04-26 19:19

Steve,

·· It's possible...I just wanted to confirm that the areas not used by the program are still intact.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

Tracy Allen · 2006-04-26 20:13

Your ealier "real time clock" post said you are using a BS2pe, and if that is the case you have 32kbytes total memory for your program and data. If you use the first 2k slot for the program, sans data, then there won't be any worries about over writing.

To store a byte in a location from 2048 up to 32767, you need to use the STORE command to select the bank.

writeByte: 'enter with addressPointer from 0 to 30720
STORE addressPointer + 2048 / 2048
WRITE addressPointer // 2048, myByte
RETURN

and the same to read

readByte: 'enter with addressPointer from 0 to 30720
STORE addressPointer + 2048 / 2048
READ addressPointer // 2048, myByte
RETURN

Within one program bank, the editor writes out code tokens in blocks of 16 bytes. There are 128 blocks of 16 bytes in each slot, total=2048 bytes per slot. If you have a program that occupies 525 bytes, the editor will send out 33 blocks, that will overwrite locations 1520 to 2047 in the Stamp memory (528 bytes). And ithe editor will leave bytes 0 to 1519 just as they were. Unnless you have also defined specific DATA in the program. Then that data too will over write data that was already there, in blocks of 16 bytes. While that is a bigger issue with the BS2, which only has one single slot, it is not much of an issue with the BS2pe, which has 16 slots.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Chris Savage · 2006-04-26 23:55

I didn't even catch that originally Tracy...This message probably should've been in his original thread instead of starting a new one.· This way we'd have more information.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

Chris Savage · 2006-04-27 00:14

It was already mentioned above that the new program will only over-write the area it uses...The data can be in other slots and won't be affected.· Or you could just write your program so that changing a jumper and hitting reset starts dumping what was logged back into the computer without having to re-program it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

roberto · 2006-04-27 00:19

is there examples on how to do that?

Chris Savage · 2006-04-27 00:25

roberto,

·· I think you better take smaller chunks.· Tracy has provided an excellent example of how to store data across banks on your BS2pe...I would start with some simple data logging and learn how to read data back from the EEPROM before trying to make a full-blown project since you are still having trouble grasping some of the simpler tasks.· There are a few Nuts & Volts articles that might help you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

roberto · 2006-04-27 00:28

true
thanks a much

allanlane5 · 2006-04-27 13:17

1. Yes, when you re-program your BS2, ALL EEPROM IS ERASED, before your new program is downloaded.

2. When you 'RESET' your BS2, it leaves the eeprom entirely alone.

3. So yes, if you are storing stuff in the BS2 eeprom, you must also program in a way for the BS2 to output that data.

Typically this is done by putting a time-outed SERIN command at the start of your program. During the time period (like one second) you can enter a character on some attached PC. This should trigger a routine to output the 'saved' data from the EEPROM.

If the SERIN time-outs (because you DON'T have an attached PC, because the BS2 is in the field TAKING data) then the data collection part of your program runs.

So, when you're ready to get the data from your BS2, you connect it (on a BOE board or whatever) to the PC, do a RESET on the BS2, and enter a character before the time-out expires. Then the PC should capture the data from the BS2.

Paul Sr. · 2006-04-27 13:49

allanlane5 said...
1. Yes, when you re-program your BS2, ALL EEPROM IS ERASED, before your new program is downloaded.

Quote:

If the data is at the lower memory addresses and your new program doesn't over-write that part of the EEPROM then you should have no problem getting that data from the BASIC Stamp EEPROM.

Chris Savage
Parallax Tech Support
csavage@parallax.com

allanlane5 · 2006-04-27 13:55

So, what you are saying Chris, is that if you HAD a program, that used the "WRITE 0, someval" statement, and THEN you re-programmed the BS2 with another program, then that program could do READ 0, myval:SEROUT 16, baudmode, [noparse][[/noparse]dec myval], and you'd actually output what had been written before?

That sounds awfully risky. But I'll take your word for it. Why couldn't people use this to write a tiny little 'dump' program, and use that to 'dump' the rest of programmed eeprom?

Chris Savage · 2006-04-27 14:04

Allan,
···The area of the EEPROM over-written when you download a new program is only that space actually used by the program.· If your data exists at the lower memory addresses and the new program doesn't over-write those then there is no problem.· If you don't believe this, run the following program to store 4 values in EEPROM, then run the second program to dispaly them all back.

' {$STAMP BS2}
' {$PBASIC 2.5}
WRITE 0, 123
WRITE 1, 4
WRITE 2, 27
WRITE 3, 6

' {$STAMP BS2}
' {$PBASIC 2.5}
ioByte    VAR   Byte
READ 0, ioByte
DEBUG DEC iobyte, CR
READ 1, ioByte
DEBUG DEC ioByte, CR
READ 2, ioByte
DEBUG DEC ioByte, CR
READ 3, ioByte
DEBUG DEC ioByte, CR

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

Post Edited (Chris Savage (Parallax)) : 4/27/2006 5:00:26 PM GMT

Bruce Bates · 2006-04-27 14:16

Chris -

I think the crux of the problem may lie here:

"a new program is only that space actually used by the program. If your data exists at the lower memory addresses"

The comparative term "lower" can be very deceiving based on how you're used to thinking about Stamp program memory, Stamp EEPROM memory, or reading a Stamp Memory Map. I KNOW it was confusing for me at first.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chris Savage · 2006-04-27 14:19

Okay, I think what's missing here is in a thread (perhaps not this one) I mentioned checking the memory map to see how large the program is to determine how much data you could store.· From the memory map you can see that the program starts at the highest addresses and builds downward.· Data is typically stored at lower addresses building upward.· So, if your main program is larger than your data reading program there is no change of your data getting over-written.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

Tom Walker · 2006-04-27 15:13

Chris,
I think allanlane5 is actually thinking that your explanation would seem to make the Stamp less secure. In the situation that a tiny EEPROM dump program is loaded over a larger program, a user could conceivably dump the majority of the tokens from the larger program and reverse Parallax's intellectual property.

If I am incorrect in my interpretation of your concern allanlane5, I apologize. I don't intend to put words in your mouth...(I apparently just have too many of my own today...)

:^)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

Post Edited (Tom Walker) : 4/27/2006 3:18:51 PM GMT

Ryan Clarke · 2006-04-27 15:21

Tom,

You can see tokenized code with much less effort. This does not make the interpreter any more/less reverse engineerable.

Ryan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support

RClarke@Parallax.com

allanlane5 · 2006-04-27 15:22

Nope, that's my concern alright. I don't want to "argue" with Chris over this point. The only reason I mentioned it at all was that I thought I had a very complete understanding of this aspect of the BS2 -- and what Chris was saying contradicted that understanding. Not Chris's fault, but when that happens I like to have it confirmed two or three times.

Also, if some person moved forward on that information, without testing it, and it turns out that their hard-logged data got erased when they programmed the BS2 with their 'download' program, well that would be a shame.

But his point is completely valid. A comparatively simple test, implementing the scenario I outlined above, should provide a quick verification. And that 'some person' mentioned above absolutely should bench-test this scenario before depending on it. So there's no real reason to argue about it. I don't have a BS2 handy at the moment, or I'd do it now.

Ryan Clarke · 2006-04-27 15:25

Consider that if stored data was completely erased upon the load of a new program, then the ability to store 'calibrations' would not be possible.

Ryan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support

RClarke@Parallax.com

roberto · 2006-04-27 15:44

thanks much guys eventhough its kind off confusing what your discussing i am trying not move very fast,

yesterday was able for the first time to log my data to the eeprom while the program was running and then retrive it using chris method was wondering allanlane if you have any links on where the dump to the debug screen using the the reset button has been in use. because it seems the way to go for my type off program it will be much help to me
thanks ahead

Thanks Chiris for slowing me down little bit off reading and was able to do it.

Bruce Bates · 2006-04-27 15:52

Gents -

Just one more caveat or observation which caused some of my initial confusion. I spent more than 30 years troubleshooting problems based on memory maps and system dumps. Let me just say that old habits die HARD, and this is just such a recitation!

Before I "met" the PBASIC Stamp Memory Map, every memory map or system dump I'd ever encountered began with the lowest address in the dump or map, at the top right of the listing or display, and ended with the highest address at the lower right of the listing or display. The PBASIC Stamp Memory Map displays all of the Stamp Memory in exactly the same way, or so it would seem at first glance.

So too, in general, the earlier user and system programs were loaded into the lowest memory location(s) available to them, unless there was some over-riding condition. Thus, to my earlier way of thinking, the memory map or system dump was in some sort of ascending, logical sequence throughout memory. Here's where the rub comes in.

The PBASIC Stamp has two basic types of defined memory. The two types are RAM and user EEPROM memory. Within the PBASIC Program Memory Map, both are shown. However, user EEPROM is shown at the top left (the lowest memory location) and proceeds towards higher memory addresses, as the display proceeds down and to the right. RAM, which contains your program, is shown at the OPPOSITE end of this Memory Map, at the HIGHEST memory location. The program is loaded from the highest location in memory, down towards the lowest that it requires. It is loaded in memory RIGHT to LEFT as well. All of this latter memory format takes a bit of getting used to, or it did for me.

If the thought comes to mind that these separate memory areas might ... meet in the middle, that is entirely possible and is a condition to be avoided. Checking the Memory Map from time to time, while you are programming, is an important part of the programming process.

Last is the matter of what memory can get over-written, and what can not, along with when it may happen. The PBASIC Manual says it best as follows:

"An important distinction between RAM and EEPROM is this:

· RAM loses its contents when the BASIC Stamp loses power; when power returns, all RAM locations are cleared to 0's.

· EEPROM retains the contents of memory, with or without power, until it is overwritten (such as during the program-downloading process or with a WRITE instruction.)"

I hope that helps to clear things up, and doesn't confuse them more.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

allanlane5 · 2006-04-27 16:46

Bruce has it right. All I can add is that the BS2 doesn't really have any "RAM", as such. What it USES for "RAM" are internal data registers on the PIC 16C57 chip inside the BS2. Since that chip has 26 bytes of register space, that's why a BS2 only has 26 bytes of "RAM".

Now, the "Program EEPROM" is loaded just as Bruce says. In the "Memory Map", the part you first see (address zero) is where the stuff you define in your program with DATA statements is stored, from address zero on up. If you scroll all the way down to the bottom (address 7F0) that's where your program tokens are loaded, from address $7FF on down.

Chris Savage · 2006-04-27 16:49

Bruce Bates said...(trimmed)
The PBASIC Stamp has two basic types of defined memory. The two types are RAM and user EEPROM memory. Within the PBASIC Program Memory Map, both are shown. However, user EEPROM is shown at the top left (the lowest memory location) and proceeds towards higher memory addresses, as the display proceeds down and to the right. RAM, which contains your program, is shown at the OPPOSITE end of this Memory Map, at the HIGHEST memory location. The program is loaded from the highest location in memory, down towards the lowest that it requires. It is loaded in memory RIGHT to LEFT as well. All of this latter memory format takes a bit of getting used to, or it did for me.

RAM loses its contents when the BASIC Stamp loses power; when power returns, all RAM locations are cleared to 0's.

Bruce,

·· I think you have the RAM and EEPROM backward.· By that explanation the last sentence would indicate that your program is lost when you power off the Stamp.· Just a slip I know, but I thought I would mention it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

Paul Sr. · 2006-04-27 17:09

Affirmation of an incorrect assumption does not make it correct......

Tracy Allen · 2006-04-27 17:40

Roberto,

When your program starts, it can display a menu and prompt for user input, something like this:

top:
DEBUG "1) Log data    2) Offload data   3) Erase data  3) Set clock",CR,LF,"enter 1,2,3,4> " 
DEBUGIN DEC1 response
DEBUG CR,LF
ON response GOTO top, datalogging, dataoffloading, dataErasing, clocksetting
GOTO top

dataLogging:
  DO
    GOSUB whatever2acquireData   ' by time or by event
    gosub getRecordPointer
    GOSUB writeData
    recordPointer=recordPointer+1 MAX 32720  ' using slots 1 to 15 in BS2pe
    GOSUB saveRecordPointer
  LOOP

dataOffLoading:
  GOSUB getRecordPointer
  IF recordPointer=0 THEN top   ' no data
  FOR idx = 0 to recordPointer-1
     GOSUB readData
     GOSUB showDecimalData
  NEXT
  GOTO top

The first thing you have to ask is, "where do I store the recordPointer"? The answer to that is, if you have the DS1302 real time clock, you store the address pointer in the extra battery backed memory that it provides. To "erase" the data, you reset recordPointer to zero. Where does the menu appear? You can use the Stamp Debug screen, or you can use a program like Hyperterminal or StampPlot to capture the data. There is no need to reload the program, because the program itself provides all the functionality. Thre are a lot of refinements you can make, but that is BASICally it.

In the separate thread on the real time clock, I pointed to URLs that take the above approach.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

roberto · 2006-04-28 14:53

first thanks for all the support i get in this thread its much appreciated

i have been playing much with the eeprom at home would like to make sure·to restart from a clean stamp
how do i go about clearing the entire eprom from any data logged
would this work?

address var·word
eeprom_data var byte

for address = 0 to 2048
eeprom_data = $00
write address, eeprom_data
next

How do i go about erasing total eeprom for the bs2pe?

P.S Thanks tracy

Post Edited (roberto) : 4/28/2006 3:54:40 PM GMT

Tracy Allen · 2006-04-28 15:27

The program idea is correct. The address needs to be a WORD variable, not a BYTE, in order to hold addresses up to 2047. "data" is a key word, so you have to use a different name. Your program will overwrite itself and crash. But that is not a big deal, because your objective is to zap the memory anyway. For the whole BS2pe:

address VAR WORD
char VAR BYTE
char = $00
DEBUG REP "_"\64,CR  ' progress bar
FOR address = 32767 TO  0 ' entire BS2pe, start at the top
  STORE address/2048     ' select slot
  WRITE 2047- (address//2048), char  ' address within slot (from 0 up to 2047)
  IF address//512 =0 THEN DEBUG "*"  ' progress indicator
NEXT

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

roberto · 2006-04-28 16:07

i am at work right now tracy
i dont understand the line

IF address//512 =0 THEN DEBUG "*"

SSteve · 2006-04-28 16:51

// is the mod operator. It's the remainder that's left after the division. address//512 will be zero whenever address is evenly divisible by 512. So that line will print a "*" in your debug window after every 512th address is cleared.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

basic question (eeprom)

Comments