EEPROM max write cycle life and variables use

Archiver

Hello. I'm new to the Basic Stamp world and I'm a little confused
about something. Is it correct that when scratchpad RAM is used
up for variables, that any remaining variables are stored in
EEPROM? If that's the case, and say some of the variables in
EEPROM were counting loops, and one had a process controller
where counts went into the millions, wouldn't the maximum
useful write cycle life of the EEPROM be exceeded quickly? ( I
appreciate that one can optimize code and variable type.) I
understand that the max write cycles for a BS1 or BS2 is 10
million and for a BS2sx is 1 million.

By way of example, say I'm using a BS2sx and I have more than
26 variables. As a thought experiment, if I had a simple loop that
just advanced the count of a variable that ended up in EEPROM,
then at 10,000 instructions per second, and two instructions for
the loop and count, that's about 5,000 loops per second and
1000000/5000=200 so it seems the EEPROM write cycle life (at
least for the involved addresses for that variable would be
exceeded in 200 seconds or less than three and a half minutes!
Could that be true? What am I not getting? If this is true, can
one add external RAM and ask the compiler/editor to place all
variables in RAM? Will the compiler/editor even accept more
than 26 variables? Thanks in advance for any help in clearing up
my confusion on this!

Archiver

Variables are NOT stored in the EEPROM -- unless YOU specifically put them
there. There is little danger of *breaking* your EEPROM under normal
programming and operation. As you point out, you can -- albeit deliberately --
exceed
the EEPROM's write-cycles in a big hurry if you want to.

As far as running out of variables ... I must be extremely lucky because in
10 years of BASIC Stamps, I've only run out once; and that was a tremendously
complicated program. This turned out NOT to be a big deal as the program,
though, had two phases of operation and I was able to preserve those I needed in

the EEPROM (was a stock BS2) while the second phase [noparse][[/noparse]a very infrequent process]
ran.

There are a lot of things you can do to conserve variable space:

-- use Bit, Nib, Byte and Word types as required
-- use aliasing to share the same memory location

Assuming you've done this, your next option is to use the Scratchpad RAM as
temporary storage (this is a better choice on any Stamp except the BS2 which
doesn't have any SPRAM). If it's one or two variables, just use PUT and GET as
required to retrieve them. Also keep in mind that the Word modifier now works
with PUT and GET (in the latest release of the PBASIC compiler).

If you want to save all of your variables, here's a quick routine to do it:

Put_All:
PUT SaveAddr, B0
FOR B0 = 1 TO 25
PUT SaveAddr + B0, B0(B0)
NEXT
RETURN

SaveAddr is a constant the determines the starting location of your saved
variables in the SPRAM. To retrieve your variables, reverse the process:

Get_All:
FOR B0 = 25 TO 1
GET SaveAddr + B0, B0(B0)
NEXT
GET SaveAddr, B0
RETURN

Notice that both routines take advantage of the inherent array structure of
the BASIC Stamp's RAM.

While I don't normally advocate the use of internal variable names (in fact,
I actively campaign against it in general programs), this is a case where
using those internal names is useful.

-- Jon Williams
-- Parallax


In a message dated 6/15/2003 2:49:22 PM Central Standard Time,
joseph123wilson@y... writes:

> Hello. I'm new to the Basic Stamp world and I'm a little confused
> about something. Is it correct that when scratchpad RAM is used
> up for variables, that any remaining variables are stored in
> EEPROM? If that's the case, and say some of the variables in
> EEPROM were counting loops, and one had a process controller
> where counts went into the millions, wouldn't the maximum
> useful write cycle life of the EEPROM be exceeded quickly? ( I
> appreciate that one can optimize code and variable type.) I
> understand that the max write cycles for a BS1 or BS2 is 10
> million and for a BS2sx is 1 million.
>
> By way of example, say I'm using a BS2sx and I have more than
> 26 variables. As a thought experiment, if I had a simple loop that
> just advanced the count of a variable that ended up in EEPROM,
> then at 10,000 instructions per second, and two instructions for
> the loop and count, that's about 5,000 loops per second and
> 1000000/5000=200 so it seems the EEPROM write cycle life (at
> least for the involved addresses for that variable would be
> exceeded in 200 seconds or less than three and a half minutes!
> Could that be true? What am I not getting? If this is true, can
> one add external RAM and ask the compiler/editor to place all
> variables in RAM? Will the compiler/editor even accept more
> than 26 variables? Thanks in advance for any help in clearing up
> my confusion on this!



[noparse][[/noparse]Non-text portions of this message have been removed]

Archiver

You ARE extremely lucky. I am bumping against the variable limits on my
first project; it looks like I'm going to have to, as you say, ALIAS
variables. I assume that there is no formal construct for doing that in
PB; equivalent to the EQUIVALENCE or COMMON statements in FORTRAN.
Otherwise, ya gotta keep a scorecard.

On Sunday, June 15, 2003, at 04:25 PM, jonwms@a... wrote:

> Variables are NOT stored in the EEPROM -- unless YOU specifically put
> them
> there. There is little danger of *breaking* your EEPROM under normal
> programming and operation. As you point out, you can -- albeit
> deliberately -- exceed
> the EEPROM's write-cycles in a big hurry if you want to.
>
> As far as running out of variables ... I must be extremely lucky
> because in
> 10 years of BASIC Stamps, I've only run out once; and that was a
> tremendously
> complicated program. This turned out NOT to be a big deal as the
> program,
> though, had two phases of operation and I was able to preserve those I
> needed in
> the EEPROM (was a stock BS2) while the second phase [noparse][[/noparse]a very infrequent
> process]
> ran.
>
> There are a lot of things you can do to conserve variable space:
>
> -- use Bit, Nib, Byte and Word types as required
> -- use aliasing to share the same memory location
>
> Assuming you've done this, your next option is to use the Scratchpad
> RAM as
> temporary storage (this is a better choice on any Stamp except the BS2
> which
> doesn't have any SPRAM). If it's one or two variables, just use PUT
> and GET as
> required to retrieve them. Also keep in mind that the Word modifier
> now works
> with PUT and GET (in the latest release of the PBASIC compiler).
>
> If you want to save all of your variables, here's a quick routine to
> do it:
>
> Put_All:
> PUT SaveAddr, B0
> FOR B0 = 1 TO 25
> PUT SaveAddr + B0, B0(B0)
> NEXT
> RETURN
>
> SaveAddr is a constant the determines the starting location of your
> saved
> variables in the SPRAM. To retrieve your variables, reverse the
> process:
>
> Get_All:
> FOR B0 = 25 TO 1
> GET SaveAddr + B0, B0(B0)
> NEXT
> GET SaveAddr, B0
> RETURN
>
> Notice that both routines take advantage of the inherent array
> structure of
> the BASIC Stamp's RAM.
>
> While I don't normally advocate the use of internal variable names (in
> fact,
> I actively campaign against it in general programs), this is a case
> where
> using those internal names is useful.
>
> -- Jon Williams
> -- Parallax
>
>
> In a message dated 6/15/2003 2:49:22 PM Central Standard Time,
> joseph123wilson@y... writes:
>
>> Hello. I'm new to the Basic Stamp world and I'm a little confused
>> about something. Is it correct that when scratchpad RAM is used
>> up for variables, that any remaining variables are stored in
>> EEPROM? If that's the case, and say some of the variables in
>> EEPROM were counting loops, and one had a process controller
>> where counts went into the millions, wouldn't the maximum
>> useful write cycle life of the EEPROM be exceeded quickly? ( I
>> appreciate that one can optimize code and variable type.) I
>> understand that the max write cycles for a BS1 or BS2 is 10
>> million and for a BS2sx is 1 million.
>>
>> By way of example, say I'm using a BS2sx and I have more than
>> 26 variables. As a thought experiment, if I had a simple loop that
>> just advanced the count of a variable that ended up in EEPROM,
>> then at 10,000 instructions per second, and two instructions for
>> the loop and count, that's about 5,000 loops per second and
>> 1000000/5000=200 so it seems the EEPROM write cycle life (at
>> least for the involved addresses for that variable would be
>> exceeded in 200 seconds or less than three and a half minutes!
>> Could that be true? What am I not getting? If this is true, can
>> one add external RAM and ask the compiler/editor to place all
>> variables in RAM? Will the compiler/editor even accept more
>> than 26 variables? Thanks in advance for any help in clearing up
>> my confusion on this!
>
>
>
> [noparse][[/noparse]Non-text portions of this message have been removed]
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject
> and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

Archiver

Thanks for your reply. How does the editor respond when varable space is
exceeded? Is it a simple error message? Thanks much.

--- In basicstamps@yahoogroups.com, jonwms@a... wrote:
> Variables are NOT stored in the EEPROM -- unless YOU specifically put them
> there. There is little danger of *breaking* your EEPROM under normal
> programming and operation. As you point out, you can -- albeit deliberately
--
exceed
> the EEPROM's write-cycles in a big hurry if you want to.
>
> As far as running out of variables ... I must be extremely lucky because in
> 10 years of BASIC Stamps, I've only run out once; and that was a tremendously
> complicated program. This turned out NOT to be a big deal as the program,
> though, had two phases of operation and I was able to preserve those I needed
in
> the EEPROM (was a stock BS2) while the second phase [noparse][[/noparse]a very infrequent
process]
> ran.
>
> There are a lot of things you can do to conserve variable space:
>
> -- use Bit, Nib, Byte and Word types as required
> -- use aliasing to share the same memory location
>
> Assuming you've done this, your next option is to use the Scratchpad RAM as
> temporary storage (this is a better choice on any Stamp except the BS2 which
> doesn't have any SPRAM). If it's one or two variables, just use PUT and GET
as
> required to retrieve them. Also keep in mind that the Word modifier now works

> with PUT and GET (in the latest release of the PBASIC compiler).
>
> If you want to save all of your variables, here's a quick routine to do it:
>
> Put_All:
> PUT SaveAddr, B0
> FOR B0 = 1 TO 25
> PUT SaveAddr + B0, B0(B0)
> NEXT
> RETURN
>
> SaveAddr is a constant the determines the starting location of your saved
> variables in the SPRAM. To retrieve your variables, reverse the process:
>
> Get_All:
> FOR B0 = 25 TO 1
> GET SaveAddr + B0, B0(B0)
> NEXT
> GET SaveAddr, B0
> RETURN
>
> Notice that both routines take advantage of the inherent array structure of
> the BASIC Stamp's RAM.
>
> While I don't normally advocate the use of internal variable names (in fact,
> I actively campaign against it in general programs), this is a case where
> using those internal names is useful.
>
> -- Jon Williams
> -- Parallax
>
>
> In a message dated 6/15/2003 2:49:22 PM Central Standard Time,
> joseph123wilson@y... writes:
>
> > Hello. I'm new to the Basic Stamp world and I'm a little confused
> > about something. Is it correct that when scratchpad RAM is used
> > up for variables, that any remaining variables are stored in
> > EEPROM? If that's the case, and say some of the variables in
> > EEPROM were counting loops, and one had a process controller
> > where counts went into the millions, wouldn't the maximum
> > useful write cycle life of the EEPROM be exceeded quickly? ( I
> > appreciate that one can optimize code and variable type.) I
> > understand that the max write cycles for a BS1 or BS2 is 10
> > million and for a BS2sx is 1 million.
> >
> > By way of example, say I'm using a BS2sx and I have more than
> > 26 variables. As a thought experiment, if I had a simple loop that
> > just advanced the count of a variable that ended up in EEPROM,
> > then at 10,000 instructions per second, and two instructions for
> > the loop and count, that's about 5,000 loops per second and
> > 1000000/5000=200 so it seems the EEPROM write cycle life (at
> > least for the involved addresses for that variable would be
> > exceeded in 200 seconds or less than three and a half minutes!
> > Could that be true? What am I not getting? If this is true, can
> > one add external RAM and ask the compiler/editor to place all
> > variables in RAM? Will the compiler/editor even accept more
> > than 26 variables? Thanks in advance for any help in clearing up
> > my confusion on this!
>
>
>
> [noparse][[/noparse]Non-text portions of this message have been removed]

Archiver

Yes -- you'll get an "Out of variable space" message.

-- Jon Williams
-- Parallax

In a message dated 6/15/2003 10:13:56 PM Central Standard Time,
joseph123wilson@y... writes:

> Thanks for your reply. How does the editor respond when varable space is
> exceeded? Is it a simple error message? Thanks much.



[noparse][[/noparse]Non-text portions of this message have been removed]

Archiver

Thank you.

--- In basicstamps@yahoogroups.com, jonwms@a... wrote:
> Yes -- you'll get an "Out of variable space" message.
>
> -- Jon Williams
> -- Parallax
>
> In a message dated 6/15/2003 10:13:56 PM Central Standard Time,
> joseph123wilson@y... writes:
>
> > Thanks for your reply. How does the editor respond when varable space is
> > exceeded? Is it a simple error message? Thanks much.
>
>
>
> [noparse][[/noparse]Non-text portions of this message have been removed]

Archiver

Yes, there's a 'formal' way of doing that with PBasic.

MyBase VAR WORD ' Assign mem to MyBase

MyOtherBase VAR MyBase ' 'alias' MyOtherBase to point
' to the same memory as MyBase


--- In basicstamps@yahoogroups.com, Mark Marpet <marpetm@s...> wrote:
> You ARE extremely lucky. I am bumping against the variable limits
on my
> first project; it looks like I'm going to have to, as you say,
ALIAS
> variables. I assume that there is no formal construct for doing
that in
> PB; equivalent to the EQUIVALENCE or COMMON statements in FORTRAN.
> Otherwise, ya gotta keep a scorecard.
>
> On Sunday, June 15, 2003, at 04:25 PM, jonwms@a... wrote:
>
> > Variables are NOT stored in the EEPROM -- unless YOU specifically
put
> > them
> > there. There is little danger of *breaking* your EEPROM under
normal
> > programming and operation. As you point out, you can -- albeit
> > deliberately -- exceed
> > the EEPROM's write-cycles in a big hurry if you want to.
> >
> > As far as running out of variables ... I must be extremely lucky
> > because in
> > 10 years of BASIC Stamps, I've only run out once; and that was a
> > tremendously
> > complicated program. This turned out NOT to be a big deal as the
> > program,
> > though, had two phases of operation and I was able to preserve
those I
> > needed in
> > the EEPROM (was a stock BS2) while the second phase [noparse][[/noparse]a very
infrequent
> > process]
> > ran.
> >
> > There are a lot of things you can do to conserve variable space:
> >
> > -- use Bit, Nib, Byte and Word types as required
> > -- use aliasing to share the same memory location
> >
> > Assuming you've done this, your next option is to use the
Scratchpad
> > RAM as
> > temporary storage (this is a better choice on any Stamp except
the BS2
> > which
> > doesn't have any SPRAM). If it's one or two variables, just use
PUT
> > and GET as
> > required to retrieve them. Also keep in mind that the Word
modifier
> > now works
> > with PUT and GET (in the latest release of the PBASIC compiler).
> >
> > If you want to save all of your variables, here's a quick routine
to
> > do it:
> >
> > Put_All:
> > PUT SaveAddr, B0
> > FOR B0 = 1 TO 25
> > PUT SaveAddr + B0, B0(B0)
> > NEXT
> > RETURN
> >
> > SaveAddr is a constant the determines the starting location of
your
> > saved
> > variables in the SPRAM. To retrieve your variables, reverse the
> > process:
> >
> > Get_All:
> > FOR B0 = 25 TO 1
> > GET SaveAddr + B0, B0(B0)
> > NEXT
> > GET SaveAddr, B0
> > RETURN
> >
> > Notice that both routines take advantage of the inherent array
> > structure of
> > the BASIC Stamp's RAM.
> >
> > While I don't normally advocate the use of internal variable
names (in
> > fact,
> > I actively campaign against it in general programs), this is a
case
> > where
> > using those internal names is useful.
> >
> > -- Jon Williams
> > -- Parallax
> >
> >
> > In a message dated 6/15/2003 2:49:22 PM Central Standard Time,
> > joseph123wilson@y... writes:
> >
> >> Hello. I'm new to the Basic Stamp world and I'm a little
confused
> >> about something. Is it correct that when scratchpad RAM is used
> >> up for variables, that any remaining variables are stored in
> >> EEPROM? If that's the case, and say some of the variables in
> >> EEPROM were counting loops, and one had a process controller
> >> where counts went into the millions, wouldn't the maximum
> >> useful write cycle life of the EEPROM be exceeded quickly? ( I
> >> appreciate that one can optimize code and variable type.) I
> >> understand that the max write cycles for a BS1 or BS2 is 10
> >> million and for a BS2sx is 1 million.
> >>
> >> By way of example, say I'm using a BS2sx and I have more than
> >> 26 variables. As a thought experiment, if I had a simple loop
that
> >> just advanced the count of a variable that ended up in EEPROM,
> >> then at 10,000 instructions per second, and two instructions for
> >> the loop and count, that's about 5,000 loops per second and
> >> 1000000/5000=200 so it seems the EEPROM write cycle life (at
> >> least for the involved addresses for that variable would be
> >> exceeded in 200 seconds or less than three and a half minutes!
> >> Could that be true? What am I not getting? If this is true, can
> >> one add external RAM and ask the compiler/editor to place all
> >> variables in RAM? Will the compiler/editor even accept more
> >> than 26 variables? Thanks in advance for any help in clearing up
> >> my confusion on this!
> >
> >
> >
> > [noparse][[/noparse]Non-text portions of this message have been removed]
> >
> >
> > To UNSUBSCRIBE, just send mail to:
> > basicstamps-unsubscribe@yahoogroups.com
> > from the same email address that you subscribed. Text in the
Subject
> > and Body of the message will be ignored.
> >
> >
> > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> >
> >
> >