Newbie Question: Clearing the EEPROM
WNed
Posts: 157
Hello,
I just received a Propeller board and am starting the tutorials. After running it from RAM, the first tutorial tells you to load the
program up to the EEPROM. The manual also says that it's more efficient to run things from RAM during development.
That's all well and good, but now I have Output.spin sitting in EEPROM, and I can't get rid of it!
I'm embarassed to have to ask this, but I haven't found any reference to "parallax +propeller +clear +eeprom"
that does me any good. How do I clear the EEPROM?
Thanks,
wned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
I just received a Propeller board and am starting the tutorials. After running it from RAM, the first tutorial tells you to load the
program up to the EEPROM. The manual also says that it's more efficient to run things from RAM during development.
That's all well and good, but now I have Output.spin sitting in EEPROM, and I can't get rid of it!
I'm embarassed to have to ask this, but I haven't found any reference to "parallax +propeller +clear +eeprom"
that does me any good. How do I clear the EEPROM?
Thanks,
wned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
Comments
-Phil
If you really want to erase the EEPROM, you can load a program into RAM that will do it. The easiest way is to load FemtoBasic or BoeBotBasic into RAM and write a simple FOR loop that stores some value in all 32K EEPROM locations using the EEPROM statement (see the documentation).
The documentation tells you to do your development work in RAM.
The first tutorial tells you to load Output.spin into EEPROM, therefore, I cannot do development in RAM because the propeller will always see Output.spin first. Likewise, if I load a null program to EEPROM, that will be seen first.
Do I have to learn how to write a program into EEPROM that will redirect operations to RAM before I can finish the tutorials?
That's a rhetorical question. I suppose the correct thing to do is to use the F10 Compile and Run in RAM option in the Propeller Tool
during development. I don't like the idea that this option leaves a program lurking in EEPROM that will run first every time I restart
the Propeller... I suppose what I need to do is learn enough to write something interesting, but harmless that I can leave in EEPROM
until I want to put something permanent in there.
Thanks, Phil and Mike, for your input.
wned
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
If you have a program in EEProm you can still send code to run in ram (F10) - and it runs as normal - It's just when you reset your prop that the program·stored in the EEprom will load and run by default..
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 9/27/2007 7:01:54 PM GMT
1) The Propeller Tool resets the Propeller as part of the identification or download/run process. The Propeller Tool then goes through a verification process to make sure the Propeller is functioning. If you asked the Propeller Tool to download and run from RAM, it downloads the program and the Propeller's boot loader will run it from RAM. If you asked to download and run from EEPROM, it downloads the program to RAM, the Propeller's boot loader will then copy the program to EEPROM and run the program.
2) If you reset the Propeller somehow other than with the Propeller Tool, the Propeller's boot loader will attempt to communicate with the Propeller Tool using I/O pins 30/31. Once that times out, the boot loader will attempt to load the program in the 1st 32K of the EEPROM attached to I/O pins 28/29. If that load process fails, the Propeller boot loader will halt.
By using Load RAM, you can always download and run a program in RAM.
-Phil
Phil Pilgrim (PhiPi) => Work Around
QuattroRS4 => Brief Explanation
Mike Green => Technical Explanation
Phil Pilgrim (PhiPi) => Possible Ramifications
... All in all a well sorted issue ! lol
Regards,
John
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Obviously it goes with some fluentness now
I like the null program approach, especially if you have a bunch of hardware permanently connected to the Prop that could result in hardware damage.
Just curious: Do you need the "repeat"? Doesn't the cog just halt if it runs out of SPIN to execute?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Post Edited (Ken Peterson) : 9/29/2007 2:30:47 PM GMT
"Sorry, Ned, we didn't think that purging the EEPROM would be important
enough to include a command or procedure for doing that."
Fine and dandy. Now would someone from Parallax please post the code for the power-up program that's
loaded on the Propeller Demo board when it ships. I'd like to be able to re-install that as the default in EEPROM
when I don't need something else in there. And unless you've seen the source for that particular code,
please don't tell me it's just a simple LED strobe widget that I could easily write myself; I'd prefer to hear that
from someone who knows it for a fact. If it's Not a simple stroby-thing, and actually verifies functionality,
it would be a good thing to have around.
Thanks All.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
But I think we should think about something for the many new posters. As the popularity of the Propeller grows, more and more wil ask the same questions.
It does not help much that there are books... I often lamented that very few read Andre LaMothe's excellent Hydra book, where nearly everthing is explained. But maybe people do. They just will have no need to ask questions in this forum
Yes, you do not need it.
And at least you shoul have it:
_clkmode = RCSLOW PUB main REPEAT WAITCNT(CNT)@deSilva:· Are you saying that your code suggestion is necessary?· Should one need to change the clock setting and go into a waitcnt loop?· I see the question here as if the "main" function does absolutely nothing, what happens in the chip?· Does the cog shut down, or what?
You say that you don't need it, and then say that at least you should have it.· Somewhat confusing.
The null program mentioned by PhiPi is nice and simple and the default behavior of the Prop is to use RC timing.· Power use is·not really a·consideration in a do-nothing program.· This would never be implemented, it's just a safety precaution for default behavior while one works with the Prop during development.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Post Edited (Ken Peterson) : 9/29/2007 6:27:15 PM GMT
1) When a cog is started using a Spin program and the COGNEW/COGINIT statement, a return address is provided which essentially points to a COGID, then COGSTOP which halts that cog. If the main method of a cog exits, including if it "falls off the end" of the method, it returns to the caller which is this statement sequence. That cog is stopped which resets everything in the cog and shuts it down. The registers are all cleared to zero and the cog goes into a minimal power mode.
deSilva,
When you change the system clock setting, you change it for all the cogs. You may not want that, particularly if there are other cogs running that assume that the system clock is still 80MHz.
WNed,
I believe the demo program you're talking about is in the Object Exchange under the name "Graphics". There's no specific "test" program for the Propeller, so really anything that uses some of the interfaces on the Demo Board should work for your needs.
Now, here is a summary:
(a) This whole thread is about what to put into the EEPROM for the case it comes out unintentionally and is run by a SPIN interpreter. There is no other COG, there is just this one.
(b) PhiPi gave a nice suggestion what to load into the EEPROM for this case.
(c) However there are more possibilities
(c1) Just return from "main": Mike has elaborated on the behaviour (=COGSTOP)
(c2) IF you want to loop, than I gave a more interesting loop.
So if what you're saying is true, PhiPi's example of a null program does not need the "repeat" statement, right? Can you get by with nothing other than "PUB main"?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Post Edited (Ken Peterson) : 9/29/2007 6:47:17 PM GMT
If what you want to do is simply to have a program that only stops itself and leaves the Propeller halted, just a "PUB main" will do. The boot loader normally uses the RCFAST clock. By including a "_clkmode = rcslow" as deSilva suggested, the Propeller's power consumption will be reduced slightly since the system clock will be running slower than the default.
On the other hand, if you wanted to halt the propeller after it performs some function of limited duration, then using "_clkmode = rcslow" makes sense as there is apparently no statement in SPIN or assembly that will shut down the entire chip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Post Edited (Ken Peterson) : 9/29/2007 7:11:29 PM GMT
PUB stopIt|myId,id myId := COGID FOR id FROM 0 TO 7 IF id<>myId COGSTOP(id) COGSTOP(myId).. not tested!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
The RC_Slow approach would make more since, but just a quick question on this.
My routine has been:
Pub Do_Nothing
If I :
_clkmode := RCSlow
Pub Do_Nothing
The Program would terminate, but the clock would default back to RCFast? I'll have to check the current on this. Anything to keep from re-charging these batteries so much would be nice.
However, there are four sources of current consumption only:
(1) Processor activity: None, as all COGs down
(2) I/O pin driver: None, as all pins in input mode
(3) The HUB wheel: Unclear. most likely stopped.
(4) Basic uphold of logic and static memory state: Unclear, but generally VERY low
It is easy the measure the current. Diagram 9 in the datasheet insinuates something of 4 uA for idle. This is below the self dis-charge of a typical NiMH rechargeable; 2,500 mAh cells (and alkaline batteries have a similar capacity) could provide this current for 500,000 h which would be around 70 years
Post Edited (deSilva) : 9/30/2007 11:52:53 AM GMT
The reset process is fairly slow (and power hungry) because the boot loader has to run, reload the program from EEPROM, and start a cog with the Spin interpreter. It would be much better to run the whole Propeller with the RCSLOW clock and sit in a WAITCNT loop for as long as possible (roughly 1.5 days). If you need more speed or need to run off a crystal for communications, you can always change the clock mode, then change it back to RCSLOW for the next sleep.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
·· I thought the purpose was to save the EEPROM and not·write to it everytime you power up the prop as the EEPROM has a limited amount of write cycles over it's lifetime.······· Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ D Rat
Dave Ratcliff· N6YEE
The original question in this thread was about how to clear the EEPROM to gain control over its behavior upon reset during development. When you're doing development, typically you will load RAM and test it that way. If you forget what's in EEPROM and the the chip gets reset for some reason, it would run whatever is in EEPROM and that might cause confusion, or worse, damage to any hardware you have connected. Since the Propeller does not have a convenient way to completely wipe out the EEPROM using the Tool, the suggested alternative was to load a "null program" into the EEPROM, consisting of the following:
PUB main
This program basically does nothing, which is what you want. Although the chip might not be completely shut down, it practically is. There have also been several posts about how to reduce power consumption or how to completely shut down the chip. For the purposes of the original question, none of that is necessary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?