Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Hello all,

I would like to have my application keep track of how many hours it
has been active.  Basically, whenever power is applied, it needs to
keep track of the total running time.  Accuracy should be something on
the order of 1/10 hour, much like a hobbs meter.  This value can be
stored in a persistent variable for use on the next power cycle.  

Currently I do this by grabbing the Timer() value at startup, and
check it every so often.  When it reaches 6 minutes, it increments the
persistent variable and restarts. 

That works fine, but I'm worried about cummulative errors.  I.E. unit
is running for 9 minutes and the power is cycled.  It then runs for
another 9 minuts and the power is cycled again.  18 minutes of run
time has elapsed, but the persistent variable shows zero.

As an aside, at the 1/10th hour resolution, the chip has a very finite
lifespan:

100,000 write cycles
10 writes per hour
10,000 hours before the eeprom hits it's design limit

Not horrible, but in reality it's only a bit over a year of continuous
use.

Any comments/ideas?

-Don
	

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Dim Hour1 as byte Dim Minute1 as byteDim Second1 as singleDim Hour2 as byte Dim
Minute2 as byteDim Second2 as single
Public Sub Main()Take Start Time
 Call GetTime(Hour1, Minute1, Second1) Second2 = Second1End sub
	Sub Timer()
'Take End Time 
Call GetTime(Hour2, Minute2, Second2)
'Make The diffrence betwen endtime an starttimeHour2 =  Hour2 - Hour1
Minute2 = Minute2 -  Minute1
Second2 = Second2 - Second1 Diff = Cstr(Hour2) & ":" & Cstr(Minute2)
& ":" & Cstr(Second2) debug.print Diff 
End Sub
_________________________________________________________________
Profitez des puissants filtres de courriels indésirables articulés sur la technologie
brevetée MicrosoftMD SmartScreen.
http://join.msn.com/?pgmarket=fr-ca&page=features/junkmail

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

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Regarding the code below: I would think it would calculate incorrectly
 when second2 < second1 which would be commonplace due to mod 60
nature of time.

You'd need to take the difference between two times in years, months,
days, hours, minutes, seconds. If you omit, say, months, in the math,
you'll get a rollover (modulo error).

One way to do this is to use a 32 bit unsigned long and calculate the
referfence and current times as the number of seconds relative to some
mark.  This gets quite complicated if you account for leap years, etc.

A simpler way is to just setup a timer task that, on first call, zeros
the "Hobbs" count. In a loop, it then increments:

dim elapsed as long ' if this is enough bits for the max duration

sub main()
   createtask "Hobbs", HobbsStack
   do ' demo
       debug.print "Hobbs Seconds:"; cstr(elapsed)
       sleep(0.5)
   loop
end sub
	sub Hobbs()
  elapsed = 0
  do
      sleep(1.0) ' one second
      elapsed = elapsed + 1
  loop
end sub

(this is ZBasic code but I think BasicX has the same)
	

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

 > ... cumulative errors.

If, as in your example, typical operation of your device includes three 
minutes' use, six-minute timekeeping resolution is grossly inadequate. 
Perhaps you can settle on a finer resolution that balances EEPROM write 
frequency and likely use.  You must, I believe, store higher resolution 
usage.

FWIW, Atmel's write endurance quotes are safely pessimistic; 10 times 
the quoted endurance is not unlikely, I'm told.  You can also spread the 
burden over any number of EEPROM locations by using two data rings, one 
that stores the variable data and one that points to the current, or 
next, element in the ring.  100 bytes can contain two 50-byte rings that 
can endure 5000000 byte writes, within spec; larger is more.  Maybe you 
can find a resolution - a write rate - that will survive within the 
EEPROM you assign to it's storage.

Here's another technique:
http://www.edn.com/contents/images/47235.pdf, a sort-of spread-spectrum 
data storage method.
	Tom

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I suppose the real problem is this:

I atually only need accuracy down to 10 hours.  In order to avoid
cummulative errors though, I need to track the time down to the
nearest minute at the least.  Obviously, I don't want to write to
eeprom every minute (or second for that matter).  

One possibility I have considered is monitoring the power supply. When
the BX detects an imminent shutdown, it writes the value to eeprom. 
On the next startup, the timer is started at that value, and continues
to count seconds.  

I'm looking for an acceptable way to do the above without the extra
hardware though, as the boards are already made.  Yes, poor planning
on my part.

If the 100K write cycle limit is really that conservative, then I
might be able to use the data ring method, and simply store the value
every minute.

Don
	--- In basicx@basi..., Tom Becker <gtbecker@...> wrote:
>
>  > ... cumulative errors.
> 
> If, as in your example, typical operation of your device includes three 
> minutes' use, six-minute timekeeping resolution is grossly inadequate. 
> Perhaps you can settle on a finer resolution that balances EEPROM write 
> frequency and likely use.  You must, I believe, store higher resolution 
> usage.
> 
> FWIW, Atmel's write endurance quotes are safely pessimistic; 10 times 
> the quoted endurance is not unlikely, I'm told.  You can also spread
the 
> burden over any number of EEPROM locations by using two data rings, one 
> that stores the variable data and one that points to the current, or 
> next, element in the ring.  100 bytes can contain two 50-byte rings
that 
> can endure 5000000 byte writes, within spec; larger is more.  Maybe you 
> can find a resolution - a write rate - that will survive within the 
> EEPROM you assign to it's storage.
> 
> Here's another technique:
> http://www.edn.com/contents/images/47235.pdf, a sort-of spread-spectrum 
> data storage method.
> 
> 
> Tom
>
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... I actually only need accuracy down to 10 hours.

Sorry, I've been in the timekeeping business too long.  I can't think
like that.  What's that mean?
	Tom
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I know, it's counterintuitive.

Here's the scenario.  

If you drive a modern car, there's that silly service engine light
that periodically lights up, usually costing you big buck to turn off.
 Sometimes though, that light is activated by a timer that's intended
to make you get your car a 'check-up'.  Not that there's anything
wrong with the car, but it's been X number of hours since the computer
was last reset by the dealer's computer.

For the sake of simplicity, let's say that X is 1000 hours.  The
computer in your car is keeping track of the time whenever the car is
running.  It needs to track that time to the nearest whatever (minute,
10 minute, hour etc...).  But the light is only activated at the 1000
hour mark.  

I would like accuracy down to the minute, but I don't really need to
do anything with that minute number.  I only need to know when it's
been 60,000 minutes.  

Using the car analogy, at 60 miles per hour, you're traveling 1 mile
per minute.  If your standard oil change is at 3000 mile intervals,
then it's 3000 minutes, or 50 hours.  In reality, I spend most of my
driving time sitting in traffic, at about 6 mph, or an oil change
every 500 hours.  

In order to reproduce the 'Check Engine' light with a BX, I do in fact
need accuracy on the order of 1 minute, but only to avoid the
cummulative error involved with multiple power cycles

-Don

--- In basicx@basi..., "Tom Becker" <gtbecker@...> wrote:
>
> 
> > ... I actually only need accuracy down to 10 hours.
> 
> Sorry, I've been in the timekeeping business too long.  I can't think
> like that.  What's that mean?
> 
> 
> Tom
>
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

OK, I understand.

Is it as simple as allocating a sizable EEPROM area to regularly write 
24 bits of accumulated time in seconds?  That's about 164 days of 
elapsed time before a wrap.  If that's too small, 32 bits of seconds is 
about 136 years.

You can do a single ring assuming, at initialization, you clear the 
entire ring to zero.  When you subsequently boot, just scan the data and 
find the largest value; that's the last one.  Start counting and writing 
from there.
	Tom

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

If you are worried about wearing out EEPROM, you could use more of it 
and less often.  Say you write to 6 different locations in rotation 
and then return to the original.  
   
You will have 6 times and many erase and write as writing to one 
EEPROM site.  And you may have extended your overall period of 
measure without 'widening' the data footprint.

You waste some here and gain some there.

--- In basicx@basi..., Tom Becker <gtbecker@...> wrote:
>
> OK, I understand.
> 
> Is it as simple as allocating a sizable EEPROM area to regularly 
write 
> 24 bits of accumulated time in seconds?  That's about 164 days of 
> elapsed time before a wrap.  If that's too small, 32 bits of 
seconds is 
> about 136 years.

> 
> Tom
>
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

G. Kramer Herzog wrote:
> ... you could use more of it and less often.  Say you write to 6 different
locations...

Brilliant!  Wish I'd suggested that.

How does he find the latest value, G?
	Tom

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Ah, the devil is in the details.

Basically this is a ring buffer: similar to FIFO, but LIFO.
So you would have to maintain a head address, a tail address, and a 
data count in RAM.

I wonder if this is stable enough?  If you have to write these things 
to EEPROM, the whole idea likely becomes pointless as these items must 
be written to each time you up data..

I suppose if there was a forced re-boot, you would loose six minutes at 
most -- not too much.  Your re-boot would have to re-intialize the ring 
and assume that the data in position one or positio six is the most 
valid.  

I suppose you could compare it to the RTC for correction, but we may be 
getting too complicated.

--- In basicx@basi..., Tom Becker <gtbecker@...> wrote:
>
> G. Kramer Herzog wrote:
> > ... you could use more of it and less often.  Say you write to 6 
different locations...
> 
> Brilliant!  Wish I'd suggested that.
> 
> How does he find the latest value, G?
> 
> 
> Tom
>
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I suppose a second way to find the latest value would to be to compare 
each for the highest.  A forced re-boot would locate the good number.

--- In basicx@basi..., Tom Becker <gtbecker@...> wrote:
>
> G. Kramer Herzog wrote:
> > ... you could use more of it and less often.  Say you write to 6 
different locations...
> 
> Brilliant!  Wish I'd suggested that.
> 
> How does he find the latest value, G?
> 
> 
> Tom
>
	

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

The head/tail pointers couldn't go in EEPROM too - as these would use up life.
If the EEPROMed data is always just an ascending date or Hobbs type of count, one could
just search the list and use the "youngest date" or "highest count".
That done, one can either retrieve that or overewrite the predecessor to that with a new
value. And thus not use head/tail pointers.

----- Original Message ----- 
From: "G. Kramer Herzog" <hwanghetw@hwan...> 
Date: Wednesday, March 22, 2006 6:50 am 
Subject: [BasicX] Re: Hobbs Meter 
To: basicx@basi... 

<span><p><span><p>
	<tt> 
Ah, the devil is in the details.<BR> 
<BR> 
Basically this is a ring buffer: similar to FIFO, but LIFO.<BR> 
So you would have to maintain a head address, a tail address, and a <BR> 
data count in RAM.<BR> 
<BR> 
I wonder if this is stable enough?&nbsp; If you have to write these things <BR> 
to EEPROM, the whole idea likely becomes pointless as these items must <BR> 
be written to each time you up data..<BR> 
<BR> 
I suppose if there was a forced re-boot, you would loose six minutes at <BR> 
most -- not too much.&nbsp; Your re-boot would have to re-intialize the ring
<BR> 
and assume that the data in position one or positio six is the most <BR> 
valid.&nbsp; <BR> 
<BR> 
I suppose you could compare it to the RTC for correction, but we may be <BR> 
getting too complicated.<BR> 
<BR> 
--- In basicx@basi..., Tom Becker &lt;gtbecker@...&gt; wrote:<BR> 
&gt;<BR> 
&gt; G. Kramer Herzog wrote:<BR> 
&gt; &gt; ... you could use more of it and less often.&nbsp; Say you write to
6 <BR> 
different locations...<BR> 
&gt; <BR> 
&gt; Brilliant!&nbsp; Wish I'd suggested that.<BR> 
&gt; <BR> 
&gt; How does he find the latest value, G?<BR> 
&gt; <BR> 
&gt; <BR> 
&gt; Tom<BR> 
&gt;<BR> 
<BR> 
<BR> 
<BR> 
<BR> 
</tt>
	<!-- |**|begin egp html banner|**| --> 

<br><br> 
<div style="width:500px; text-align:right; margin-bottom:1px;
color:#909090;"> 
<tt>SPONSORED LINKS</tt> 
</div> 
<table bgcolor=#e0ecee cellspacing="13" cellpadding="0"
width=500px> 
<tr valign=top> 
<td style="width:25%;"> 
<tt><a
href="http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ"
target="1">Microcontrollers</a></tt> 
</td> 
<td style="width:25%;"> 
<tt><a
href="http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA"
target="1">Microprocessor</a></tt> 
</td> 
<td style="width:25%;"> 
<tt><a
href="http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw"
target="1">Intel microprocessors</a></tt> 
</td> 
</tr> 
<tr valign=top> 
<td style="width:25%;"> 
<tt><a
href="http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw"
target="1">Pic microcontrollers</a></tt> 
</td> 
</tr> 
</table> 

<!-- |**|end egp html banner|**| -->
	<!-- |**|begin egp html banner|**| --> 

<br> 
<div style="text-align:center; color:#909090; width:500px;"> 
<hr style="border-bottom:1px; width:500px; text-align:left;"> 
<tt>" target="1">Yahoo! Terms of Service</a>.</tt> 
</ul> 
<br> 
<div style="text-align:center; color:#909090; width:500px;"> 
<hr style="border-bottom:1px; width:500px; text-align:left;"> 
</div> 
</br> 

<!-- |**|end egp html banner|**| -->
	</span></span>
	[Non-text portions of this message have been removed]
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

OK, so I'm using a circular buffer of 10 memory locations, tracking
the time to the nearest minute.  At startup, I check to find the
largest number and start from there.  Since the numbers are always
ascending, there's no need for a pointer.  

One write per minute X 100,000 cycles X 10 locations in the circle
yeilds 16,666 hours before the limit is reached.  

That number doesn't sound very impressive, but it actually works out
to almost 1 million miles (if my math is correct).  I think this will
work just fine.

What I should be doing here is monitoring the power supply and only
write the minute value when a shutdown is imminent.
	-Don
	--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@...> wrote:
>
> I suppose a second way to find the latest value would to be to compare 
> each for the highest.  A forced re-boot would locate the good number.
> 
> --- In basicx@basi..., Tom Becker <gtbecker@> wrote:
> >
> > G. Kramer Herzog wrote:
> > > ... you could use more of it and less often.  Say you write to 6 
> different locations...
> > 
> > Brilliant!  Wish I'd suggested that.
> > 
> > How does he find the latest value, G?
> > 
> > 
> > Tom
> >
>
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Beware the rather lengthy time to complete a write to EEPROM versus the time
left until the Vcc is in the marginal area.

And beware if a RESET pulse happens on the micro - can't catch that one.
	  _____  

From: basicx@basi... [mailto:basicx@basi...] On Behalf Of
psyclopedia
Sent: Wednesday, March 22, 2006 5:19 PM
To: basicx@basi...
Subject: [BasicX] Re: Hobbs Meter
	OK, so I'm using a circular buffer of 10 memory locations, tracking
the time to the nearest minute.  At startup, I check to find the
largest number and start from there.  Since the numbers are always
ascending, there's no need for a pointer.  

One write per minute X 100,000 cycles X 10 locations in the circle
yeilds 16,666 hours before the limit is reached.  

That number doesn't sound very impressive, but it actually works out
to almost 1 million miles (if my math is correct).  I think this will
work just fine.

What I should be doing here is monitoring the power supply and only
write the minute value when a shutdown is imminent.
	-Don
	--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@...> wrote:
>
> I suppose a second way to find the latest value would to be to compare 
> each for the highest.  A forced re-boot would locate the good number.
> 
> --- In basicx@basi..., Tom Becker <gtbecker@> wrote:
> >
> > G. Kramer Herzog wrote:
> > > ... you could use more of it and less often.  Say you write to 6 
> different locations...
> > 
> > Brilliant!  Wish I'd suggested that.
> > 
> > How does he find the latest value, G?
> > 
> > 
> > Tom
> >
>
	SPONSORED LINKS
	Microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2
=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.s
ig=mfaAujKZXA2Z_vxre9sGnQ>  

Microprocessor
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=M
icroprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig
=9jjd2D3GOLIESVQssLmLsA>  

Intel
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrolle
rs&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=
95&.sig=OMnZuqMZX95mgutt4B-tDw>  microprocessors
	Pic
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontroller
s&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=9
5&.sig=Malspbd0T4Rq3M4Q0nHrfw>  microcontrollers
	  _____  

>  Terms of Service.
	  _____
	[Non-text portions of this message have been removed]
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I suspect the write cycle in nearly the same if you return to one 
address each and every time, or rotate in a reasonably small loop.  
There is likely to be only one or two clock cycles difference.

Start up condition is a special case.  The EEPROM will either hold 
random data, have to be cleared at the first time start up, or have 
to be set up.  Which ever way, it lacks sequential data [unless you 
intially put such it].  The BasicX does have an indicator for first 
run of a program.  You may use that.  Or, you have your comparision 
routine recognize a Zero [0] as a startup condition.  Or, both if you 
are worried about glitches. 

Or, enter the numbers 1 through 10 in the EEPROM sites and just 
subtract that much time from your output. I think this is the 
cleanest.

I want to thank you as this has changed my whole perspective on using 
the persistent variables.  One can easily use 1K sites if you have 
the unused space in EEPROM. [It would slow down start up consdierably]

I would consider using 16 instead of 10 just because that is simpler 
if you get into tracking address sites in binary via PEEK and POKE.

--- In basicx@basi..., "stevech" <stevech@...> wrote:
>
> Beware the rather lengthy time to complete a write to EEPROM versus 
the time
> left until the Vcc is in the marginal area.
> 
> And beware if a RESET pulse happens on the micro - can't catch that 
one.
> 
>  
> 
>  
> 
>   _____  
> 
> From: basicx@basi... [mailto:basicx@basi...] On 
Behalf Of
> psyclopedia
> Sent: Wednesday, March 22, 2006 5:19 PM
> To: basicx@basi...
> Subject: [BasicX] Re: Hobbs Meter
> 
>  
> 
> OK, so I'm using a circular buffer of 10 memory locations, tracking
> the time to the nearest minute.  At startup, I check to find the
> largest number and start from there.  Since the numbers are always
> ascending, there's no need for a pointer.  
> 
> One write per minute X 100,000 cycles X 10 locations in the circle
> yeilds 16,666 hours before the limit is reached.  
> 
> That number doesn't sound very impressive, but it actually works out
> to almost 1 million miles (if my math is correct).  I think this 
will
> work just fine.
> 
> What I should be doing here is monitoring the power supply and only
> write the minute value when a shutdown is imminent.
> 
> 
> -Don
> 
> 
> --- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@> 
wrote:
> >
> > I suppose a second way to find the latest value would to be to 
compare 
> > each for the highest.  A forced re-boot would locate the good 
number.
> > 
> > --- In basicx@basi..., Tom Becker <gtbecker@> wrote:
> > >
> > > G. Kramer Herzog wrote:
> > > > ... you could use more of it and less often.  Say you write 
to 6 
> > different locations...
> > > 
> > > Brilliant!  Wish I'd suggested that.
> > > 
> > > How does he find the latest value, G?
> > > 
> > > 
> > > Tom
> > >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> SPONSORED LINKS 
> 
> 
> Microcontrollers
> <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microcontrollers&w2
> 
=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s
=95&.s
> ig=mfaAujKZXA2Z_vxre9sGnQ>  
> 
> Microprocessor
> <http://groups.yahoo.com/gads?
t=ms&k=Microprocessor&w1=Microcontrollers&w2=M
> 
icroprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=9
5&.sig
> =9jjd2D3GOLIESVQssLmLsA>  
> 
> Intel
> <http://groups.yahoo.com/gads?
t=ms&k=Intel+microprocessors&w1=Microcontrolle
> 
rs&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&
c=4&s=
> 95&.sig=OMnZuqMZX95mgutt4B-tDw>  microprocessors 
> 
> 
> Pic
> <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microcontroller
> 
s&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c
=4&s=9
> 5&.sig=Malspbd0T4Rq3M4Q0nHrfw>  microcontrollers 
> 
>  
> 
>  
> 
>  
> 
>   _____  
> 
> >  Terms of Service. 
> 
>  
> 
>   _____  
> 
> 
> 
> [Non-text portions of this message have been removed]
>
	

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Yes, a eeprom write takes longer than a regular memory write.  As for
monitoring the power supply, that's what I should have done, not what
I did.  I hadn't thought about the reset condition however.

-Don
	--- In basicx@basi..., "stevech" <stevech@...> wrote:
>
> Beware the rather lengthy time to complete a write to EEPROM versus
the time
> left until the Vcc is in the marginal area.
> 
> And beware if a RESET pulse happens on the micro - can't catch that one.
> 
>  
> 
>  
> 
>   _____  
> 
> From: basicx@basi... [mailto:basicx@basi...] On
Behalf Of
> psyclopedia
> Sent: Wednesday, March 22, 2006 5:19 PM
> To: basicx@basi...
> Subject: [BasicX] Re: Hobbs Meter
> 
>  
> 
> OK, so I'm using a circular buffer of 10 memory locations, tracking
> the time to the nearest minute.  At startup, I check to find the
> largest number and start from there.  Since the numbers are always
> ascending, there's no need for a pointer.  
> 
> One write per minute X 100,000 cycles X 10 locations in the circle
> yeilds 16,666 hours before the limit is reached.  
> 
> That number doesn't sound very impressive, but it actually works out
> to almost 1 million miles (if my math is correct).  I think this will
> work just fine.
> 
> What I should be doing here is monitoring the power supply and only
> write the minute value when a shutdown is imminent.
> 
> 
> -Don
> 
> 
> --- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@> wrote:
> >
> > I suppose a second way to find the latest value would to be to
compare 
> > each for the highest.  A forced re-boot would locate the good number.
> > 
> > --- In basicx@basi..., Tom Becker <gtbecker@> wrote:
> > >
> > > G. Kramer Herzog wrote:
> > > > ... you could use more of it and less often.  Say you write to 6 
> > different locations...
> > > 
> > > Brilliant!  Wish I'd suggested that.
> > > 
> > > How does he find the latest value, G?
> > > 
> > > 
> > > Tom
> > >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> SPONSORED LINKS 
> 
> 
> Microcontrollers
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2
>
=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.s
> ig=mfaAujKZXA2Z_vxre9sGnQ>  
> 
> Microprocessor
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=M
>
icroprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig
> =9jjd2D3GOLIESVQssLmLsA>  
> 
> Intel
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrolle
>
rs&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=
> 95&.sig=OMnZuqMZX95mgutt4B-tDw>  microprocessors 
> 
> 
> Pic
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontroller
>
s&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=9
> 5&.sig=Malspbd0T4Rq3M4Q0nHrfw>  microcontrollers 
> 
>  
> 
>  
> 
>  
> 
>   _____  
> 
> >  Terms of Service. 
> 
>  
> 
>   _____  
> 
> 
> 
> [Non-text portions of this message have been removed]
>
	

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I though since I get so much information from the group, that I would
share what I have put together for my hobbs meter. Below is the code
I am using, which works fine. It's not very complex, just a little
confusing, as I've never used a circular buffer before. Any comments
or advice is appreciated.

'---------------------------------------------------------------------------------
'Hobbs Meter (C)2006 Don Kirby
'Tracks time to the nearest minute using single precision persistent
variable array.
'The array uses 64 bytes of PRS to store 16 memory locations.
'The values are stored in a circular buffer to extend the EEPROM life
'for measuring time into thousands of hours
Public Hobbs(1 to 16) as New PersistentSingle 'Hobbs since last reset
Public HobbsTotal as New PersistentSingle 'Hobbs Total
Public HobbsStack(1 to 42) as Byte 'Hobbs Meter Task Stack

Sub HobbsMeter()
'Hobbs Meter Task - Call this task in Sub Main() to start counting
Dim I As Byte, X As Single, N As Byte
Do
Call Sleep(30720) 'Sleep for 1 minute
For I = 1 to 16 'Load the array data one at a time
If Hobbs(I) > X Then 'and compare it to the last loaded value
X = Hobbs(I) 'remember the highest value
N = I 'remember the counter value (array index). this allows
strict syntax
End If
Next
If N = 16 Then 'don't forget to loop around the circle
N = 0
End If
N = N + 1
Hobbs(N) = HobbsValue + 1.0 'add one to the value, and put it in the
next array location

Loop

End Sub
'-------------------------------------------------------------------------------------
Function HobbsValue() As Single 'call this function to retrieve the
current value in minutes. HobsMeter task does not have to be running
Dim I As Byte
For I = 1 to 16
If Hobbs(I) > HobbsValue Then
HobbsValue = Hobbs(I)
End If

Next
If HobbsTotal < HobbsValue Then 'Only happens before the first hobbs
reset
HobbsTotal = HobbsValue
End If

End Function
'-------------------------------------------------------------------------

Sub ResetHobbs() 'call this sub to reset the Hobbs. The running
total is not reset.
Dim I As Byte
If HobbsTotal >= HobbsValue Then 'Only happens before first hobbs reset
HobbsTotal = HobbsTotal + HobbsValue 'Add to the total
End If

For I = 1 To 16
Hobbs(I) = 0.0 'write zeros to the persistent array
Next
End Sub

-Don

Yahoo! Groups Links

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

If you use :

Public Hobbs(0 to 15) as New PersistentSingle 'Hobbs since last reset

and

I = 0 to 15 then

you can use:

N = N Mod 16

and eliminate the if N = 16 then statements which is the standard way
of forming a circular buffer.

P

psyclopedia wrote:
> I though since I get so much information from the group, that I would
> share what I have put together for my hobbs meter. Below is the code
> I am using, which works fine. It's not very complex, just a little
> confusing, as I've never used a circular buffer before. Any comments
> or advice is appreciated.
>
> '---------------------------------------------------------------------------------
> 'Hobbs Meter (C)2006 Don Kirby
> 'Tracks time to the nearest minute using single precision persistent
> variable array.
> 'The array uses 64 bytes of PRS to store 16 memory locations.
> 'The values are stored in a circular buffer to extend the EEPROM life
> 'for measuring time into thousands of hours
> Public Hobbs(1 to 16) as New PersistentSingle 'Hobbs since last reset
> Public HobbsTotal as New PersistentSingle 'Hobbs Total
> Public HobbsStack(1 to 42) as Byte 'Hobbs Meter Task Stack
>
> Sub HobbsMeter()
> 'Hobbs Meter Task - Call this task in Sub Main() to start counting
> Dim I As Byte, X As Single, N As Byte
> Do
> Call Sleep(30720) 'Sleep for 1 minute
> For I = 1 to 16 'Load the array data one at a time
> If Hobbs(I) > X Then 'and compare it to the last loaded value
> X = Hobbs(I) 'remember the highest value
> N = I 'remember the counter value (array index). this allows
> strict syntax
> End If
> Next
> If N = 16 Then 'don't forget to loop around the circle
> N = 0
> End If
> N = N + 1
> Hobbs(N) = HobbsValue + 1.0 'add one to the value, and put it in the
> next array location
>
> Loop
>
> End Sub
> '-------------------------------------------------------------------------------------
> Function HobbsValue() As Single 'call this function to retrieve the
> current value in minutes. HobsMeter task does not have to be running
> Dim I As Byte
> For I = 1 to 16
> If Hobbs(I) > HobbsValue Then
> HobbsValue = Hobbs(I)
> End If
>
> Next
> If HobbsTotal < HobbsValue Then 'Only happens before the first hobbs
> reset
> HobbsTotal = HobbsValue
> End If
>
> End Function
> '-------------------------------------------------------------------------
>
> Sub ResetHobbs() 'call this sub to reset the Hobbs. The running
> total is not reset.
> Dim I As Byte
> If HobbsTotal >= HobbsValue Then 'Only happens before first hobbs reset
> HobbsTotal = HobbsTotal + HobbsValue 'Add to the total
> End If
>
> For I = 1 To 16
> Hobbs(I) = 0.0 'write zeros to the persistent array
> Next
> End Sub
>
> -Don
>
> Yahoo! Groups Links
>
>
>

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Never thought of building a Hobbs Meter before you asked for help.

Now, I can download all this an have one on hand. Very handy code and
a good quickie use for a BasicX24.

Best wishes

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Thanks, I'll try that. Like I said, it's the first time I've played
with a circular buffer.

-Don

--- In b...@yahoogroups.com, Paul Dubinsky wrote:
>
> If you use :
>
> Public Hobbs(0 to 15) as New PersistentSingle 'Hobbs since last reset
>
> and
>
> I = 0 to 15 then
>
> you can use:
>
> N = N Mod 16
>
> and eliminate the if N = 16 then statements which is the standard way
> of forming a circular buffer.
>
> P
>
> psyclopedia wrote:
> > I though since I get so much information from the group, that I would
> > share what I have put together for my hobbs meter. Below is the code
> > I am using, which works fine. It's not very complex, just a little
> > confusing, as I've never used a circular buffer before. Any comments
> > or advice is appreciated.
> >
> >
'---------------------------------------------------------------------------------
> > 'Hobbs Meter (C)2006 Don Kirby
> > 'Tracks time to the nearest minute using single precision persistent
> > variable array.
> > 'The array uses 64 bytes of PRS to store 16 memory locations.
> > 'The values are stored in a circular buffer to extend the EEPROM life
> > 'for measuring time into thousands of hours
> >
> >
> > Public Hobbs(1 to 16) as New PersistentSingle 'Hobbs since last reset
> > Public HobbsTotal as New PersistentSingle 'Hobbs Total
> > Public HobbsStack(1 to 42) as Byte 'Hobbs Meter Task Stack
> >
> >
> >
> > Sub HobbsMeter()
> > 'Hobbs Meter Task - Call this task in Sub Main() to start counting
> > Dim I As Byte, X As Single, N As Byte
> > Do
> > Call Sleep(30720) 'Sleep for 1 minute
> > For I = 1 to 16 'Load the array data one at a time
> > If Hobbs(I) > X Then 'and compare it to the last loaded value
> > X = Hobbs(I) 'remember the highest value
> > N = I 'remember the counter value (array index). this allows
> > strict syntax
> > End If
> > Next
> > If N = 16 Then 'don't forget to loop around the circle
> > N = 0
> > End If
> > N = N + 1
> > Hobbs(N) = HobbsValue + 1.0 'add one to the value, and put it in the
> > next array location
> >
> > Loop
> >
> > End Sub
> >
> >
> >
'-------------------------------------------------------------------------------------
> >
> >
> > Function HobbsValue() As Single 'call this function to retrieve the
> > current value in minutes. HobsMeter task does not have to be running
> > Dim I As Byte
> > For I = 1 to 16
> > If Hobbs(I) > HobbsValue Then
> > HobbsValue = Hobbs(I)
> > End If
> >
> > Next
> > If HobbsTotal < HobbsValue Then 'Only happens before the first hobbs
> > reset
> > HobbsTotal = HobbsValue
> > End If
> >
> > End Function
> >
> >
> >
'-------------------------------------------------------------------------
> >
> > Sub ResetHobbs() 'call this sub to reset the Hobbs. The running
> > total is not reset.
> > Dim I As Byte
> > If HobbsTotal >= HobbsValue Then 'Only happens before first hobbs
reset
> > HobbsTotal = HobbsTotal + HobbsValue 'Add to the total
> > End If
> >
> > For I = 1 To 16
> > Hobbs(I) = 0.0 'write zeros to the persistent array
> > Next
> > End Sub
> >
> > -Don
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Here's another method:
http://groups.yahoo.com/group/basicx/files/Datasheets-Appnotes-Examples-Drawings/Hobbs.bas

This code uses an offset RTC to do the counting. In the BX-24p, if
the RTC tick count is deliberately set well above 24 hours, it will
never reset and will continue counting through 32 bits. This allows
effortlessly counting very long periods with 512Hz resolution.

The code also uses all of the 480 bytes of EEPROM available to store
persistent variables. The ring buffer in this code is 120 longs.

The result is 0.001-hour resolution (3.6 seconds), a resettable
running period maximum of about 1117 hours, and an endurance minimum
of 12000 hours. Changing a few values provide 36-second resolution
over 11170 hours and an endurance of 120000 hours, 13 years of timing.
Tom

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Gee Tom, you're much better at this than I am. Some impressive
numbers you've worked up there.

The problem I'm running into at this point is other tasks causing the
RTC to lose time. I don't really think it's a big deal, as I'm only
losing about 0.3% per day, but it's annoying just the same. The hobbs
task is only 1 of 3 that are running, plus Sub Main() which is fairly
complex in it's own right. I suppose which ever way the hobbs is
implimented, the RTC accuracy issue is still there as all of the
timing methods depend on it.

Interesting though. I never thought of setting the RTC ticks beyond
24 hours. Pretty slick. I think I have a bit more fiddling to do
with this one. Your code has opened up some new options for me to
explore.

As an aside, I'm quickly approaching the memory limits of the BX-24 in
both size and durability. Might be time to add some more.

-Don

--- In b...@yahoogroups.com, "Tom Becker" wrote:
>
> Here's another method:
>
http://groups.yahoo.com/group/basicx/files/Datasheets-Appnotes-Examples-Drawings/Hobbs.bas
>
> This code uses an offset RTC to do the counting. In the BX-24p, if
> the RTC tick count is deliberately set well above 24 hours, it will
> never reset and will continue counting through 32 bits. This allows
> effortlessly counting very long periods with 512Hz resolution.
>
> The code also uses all of the 480 bytes of EEPROM available to store
> persistent variables. The ring buffer in this code is 120 longs.
>
> The result is 0.001-hour resolution (3.6 seconds), a resettable
> running period maximum of about 1117 hours, and an endurance minimum
> of 12000 hours. Changing a few values provide 36-second resolution
> over 11170 hours and an endurance of 120000 hours, 13 years of timing.
> Tom
>

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... other tasks caus[e] the RTC to lose time.

How? Do you disable interrupts or spend much time doing captures or
other functions that commandeer the machine?
Tom

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

CountTransitions.

Unfortunately, I need to do some pulse counting for some low speed
square waves at the same time. If the pulse speed were faster, I
could keep the time interval shorter than the tick period.

I'm open to suggestions as usual.

I'm also measuring a PWM signal, but that one I'm using a diode wave
shaper to convert the PWM signal to voltage.

-Don
--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ... other tasks caus[e] the RTC to lose time.
>
> How? Do you disable interrupts or spend much time doing captures or
> other functions that commandeer the machine?
> Tom
>

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... I need to do some pulse counting for some low speed square waves...

If the interrupt pin and ICP is available, you can measure both period
or pulse width, or both, with hardware.

You can program Timer1 to count at a useful internal rate (or provide
your own externally to T1), and use the input capture (BX-24 ICP pin 10)
and interrupt (11) pins to let you know a new count is available. No
waiting is required.

Study the Atmel processor PDF, 16-bit Timer/Counter 1.
Tom

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I'm studying the Atmel docs, but this one might be over my head.
Sounds like the way to go, as it would solve a lot of my timing
issues. I think I'll be able to impliment it though. The kids won't
be home tonight, so I might actually be able to read a whole paragraph
at once. Turn off the phone, lock the doors, curl up on the couch
with some microcontroller docs...How did this happen to me?
Unrelated topic:
I'm beginning to appreciate my code commenting now as I've just
exceeded 10K worth of compiled code, 6 modules, 40-something subs, and
now 4 simultaneous tasks. For those of you who don't regularly
comment your code, take my advice, start now...

-Don

--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ... I need to do some pulse counting for some low speed square
waves...
>
> If the interrupt pin and ICP is available, you can measure both period
> or pulse width, or both, with hardware.
>
> You can program Timer1 to count at a useful internal rate (or provide
> your own externally to T1), and use the input capture (BX-24 ICP pin
10)
> and interrupt (11) pins to let you know a new count is available. No
> waiting is required.
>
> Study the Atmel processor PDF, 16-bit Timer/Counter 1.
> Tom
>

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... exceeded 10K worth of compiled code, 6 modules, 40-something
subs, now 4 simultaneous tasks...

That sounds like a real application, Don.

What I suggest you consider is this: tie your slow squarewave (you did
say _square_wave - identical high and low portions) to _both_ BX-24
pin 10 and 11. The signal on Pin 10, the Input Capture pin, will
latch the current Timer1 count to the ICP1 register on a rising or
falling edge; your choice. ICP1 will contain a count that represents
the end of a high (or low, depending on the edge you choose) signal
period. The interrupt pin can be similarly programmed to trigger an
interrupt on either edge (the ATMega8535 PDF documents this; late
AT90S8535s officially only offer rising-edge detection but, in fact,
will trigger on both edges if you want it to). Your interrupt handler
(the code that waits after WaitForInterrupt()) can read register.ICP1
to retrieve the count latched just before the interrupt, subtract the
last count from it to get a duration, and calculate the signal's
period or frequency. If the interrupt handler alternately waits for a
rising edge, then a falling edge, you can measure both high and low
portions of each cycle of the signal - if the signal is _not_ square.
[See message http://groups.yahoo.com/group/basicx/message/18488 and
its thread for some details.]

If you program Timer1 to count at Ck/1024, you can count periods up to
about nine seconds in 16 bits with a ~138uS (1/7200) resolution;
higher rates count shorter periods with higher resolution. If you
need an odd rate or a very slow one, you can supply an external clock
from another source to processor pin T1, an unused input on the Atmel
processor that is not brought out to a BX-24 pin. You can use Timer2
and its prescaler divider and OutputCompare register (OCP2) to
generate an odd T1 clock, too; tie its OutputCompare line (BX-24 pin
25) to T1 to have Timer1 count at the Timer2-provided rate.

This might help get you started:

Sub InitializeTimer1()
Register.TCCR1A = bx0000_0000 'Set mode
Register.TCCR1B = bx1100_1101 'rising capture, Ck/1024
register.TCNT1H = 0 'clear for first count
register.TCNT1L = 0
End Sub
Tom

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Sorry. The Input Capture pin on the BX-24 is pin 12.
Tom

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

It is, in fact, a real application. In the past, I had only 'played'
with the BX. This time I actually get to do something useful.

I'm looking into your suggestion on using the interrupt to deal with
the square wave. Yes, it is a true square wave. I must be missing
something here though. I was under the assumption that if I use
WaitForInterrupt, everything else is halted. What happens to my other
tasks while waiting for the interrupt? For example, the square wave
is measuring RPM. If the RPM drops to zero, the application needs to
respond, but it can't as it is waiting for the square wave, which will
never occur.

-Don
--- In b...@yahoogroups.com, "Tom Becker" wrote:
>
> > ... exceeded 10K worth of compiled code, 6 modules, 40-something
> subs, now 4 simultaneous tasks...
>
> That sounds like a real application, Don.
>
> What I suggest you consider is this: tie your slow squarewave (you did
> say _square_wave - identical high and low portions) to _both_ BX-24
> pin 10 and 11. The signal on Pin 10, the Input Capture pin, will
> latch the current Timer1 count to the ICP1 register on a rising or
> falling edge; your choice. ICP1 will contain a count that represents
> the end of a high (or low, depending on the edge you choose) signal
> period. The interrupt pin can be similarly programmed to trigger an
> interrupt on either edge (the ATMega8535 PDF documents this; late
> AT90S8535s officially only offer rising-edge detection but, in fact,
> will trigger on both edges if you want it to). Your interrupt handler
> (the code that waits after WaitForInterrupt()) can read register.ICP1
> to retrieve the count latched just before the interrupt, subtract the
> last count from it to get a duration, and calculate the signal's
> period or frequency. If the interrupt handler alternately waits for a
> rising edge, then a falling edge, you can measure both high and low
> portions of each cycle of the signal - if the signal is _not_ square.
> [See message http://groups.yahoo.com/group/basicx/message/18488 and
> its thread for some details.]
>
> If you program Timer1 to count at Ck/1024, you can count periods up to
> about nine seconds in 16 bits with a ~138uS (1/7200) resolution;
> higher rates count shorter periods with higher resolution. If you
> need an odd rate or a very slow one, you can supply an external clock
> from another source to processor pin T1, an unused input on the Atmel
> processor that is not brought out to a BX-24 pin. You can use Timer2
> and its prescaler divider and OutputCompare register (OCP2) to
> generate an odd T1 clock, too; tie its OutputCompare line (BX-24 pin
> 25) to T1 to have Timer1 count at the Timer2-provided rate.
>
> This might help get you started:
>
> Sub InitializeTimer1()
> Register.TCCR1A = bx0000_0000 'Set mode
> Register.TCCR1B = bx1100_1101 'rising capture, Ck/1024
> register.TCNT1H = 0 'clear for first count
> register.TCNT1L = 0
> End Sub
> Tom
>

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... What happens to my other tasks while waiting for the interrupt?

Everything else runs. A beauty of the interrupt is, in fact, that the
machine can stay busy doing other things while waiting for one - or many
- interrupt conditions to occur.

In Basic-X, only one task - the task that issued the WaitForInterrupt -
is blocked (suspended) while waiting. When the interrupt occurs, that
task is given priority and commandeers the processor, normally within
150uS or so; some executing functions like CountTransitions can delay that.

Everything else stops, briefly, while the interrupt handler code (the
code after the WaitForInterrupt()) runs.

Only one statement execution in the interrupt task seems guaranteed -
the first after WaitForInterrupt(); after that first line, control can
be lost via multitasking. Except for the relatively quick response that
gives control to the handler, the interrupt task code is subsequently
treated like any other task until another WaitForInterrupt() is executed.

If you must assure that nothing else has a chance to run once the
handler has control, the handler must issue a LockTask() or disable
interrupts with that first statement. LockTask() still allows queue
handling and the 512Hz system tick to be acknowledged so the RTC remains
active, but control will return to the same task until an UnlockTask()
(or one of a few other functions; read about LockTask) is issued, or
interrupts are reenabled.

So, only the task that is measuring your slow signal will be blocked by
WaitForInterrupt().
Tom

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> ... LockTask() or disable interrupts...

I should add:

Even the system tick is ignored if interrupts are disabled; that has
heavy consequence. Until you grok interrupts, avoid that.
Tom

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Thanks for the clarification on that Tom. That makes much more sense
now. I have to admit, the BasicX docs are a bit vague on the entire
subject.

I'm off to experiment..

-Don

--- In b...@yahoogroups.com, Tom Becker wrote:
>
> > ... LockTask() or disable interrupts...
>
> I should add:
>
> Even the system tick is ignored if interrupts are disabled; that has
> heavy consequence. Until you grok interrupts, avoid that.
> Tom
>

Yahoo! Groups Links



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Just an update.

The Hobbs meter has just hit the 1000 hour mark without a single
glitch. Works perfectly, and there is no sign of eeprom degredation
(yet).

I'm currently using a circular buffer of 100 Singles. It should
operate without fail for 150000 hours if my math is correct.

Thanks all for the help and input.
-Don



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )