basic question (eeprom)
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
·
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
·
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
·· 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
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
Parallax Tech Support
csavage@parallax.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
·· 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
thanks a much
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.
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
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?
···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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Post Edited (Chris Savage (Parallax)) : 4/27/2006 5:00:26 PM GMT
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
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
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support
RClarke@Parallax.com
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.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
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.
·· 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
When your program starts, it can display a menu and prompt for user input, something like this:
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
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
www.emesystems.com
i dont understand the line
IF address//512 =0 THEN DEBUG "*"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows