For my application I was looking for a very low current reset chips -
supervisor and watchdog with no external components and in a small case (SO8
is too big). After searching at ti.com I only found the TPS3813 - with 10uA
current consumption. Too much.

But then I stumbled through my archive of this list and there
was a suggestion: TI TPS3110K33 (2uA) - quite good. 

And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the
TPS3110 (only 2 pins swapped). The drawback is: one can get it only in
quantities of 2 or 2500. Does some of you know a distributor that would sell
me e.g. 100pcs?

Are there other low current supervisor/watchdogs available? My TOP TWO are
still the MAX6864 and the TPS3110 - I did'nt find better ones.

        Matthias

I don't use one, and have never had the need. Cheapest option around.

;?}

Al

Matthias Weingart wrote:

> For my application I was looking for a very low
current reset chips -
> supervisor and watchdog with no external components and in a small case
(SO8
> is too big). After searching at ti.com I only found the TPS3813 - with 10uA
> current consumption. Too much.
> 
> But then I stumbled through my archive of this list and there
> was a suggestion: TI TPS3110K33 (2uA) - quite good. 
> 
> And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the
> TPS3110 (only 2 pins swapped). The drawback is: one can get it only in
> quantities of 2 or 2500. Does some of you know a distributor that would
sell
> me e.g. 100pcs?
> 
> Are there other low current supervisor/watchdogs available? My TOP TWO are
> still the MAX6864 and the TPS3110 - I did'nt find better ones.
> 
>         Matthias
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Al
  OK, I know I'm opening myself up for a "learning" experience,
but
here goes anyway: What do you use for brownout detection and recovery?

-Bill Knight
R O SoftWare


On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:


>I don't use one, and have never had the need.
Cheapest option around.

>;?}

>Al

>Matthias Weingart wrote:

>> For my application I was looking for a very
low current reset chips -
>> supervisor and watchdog with no external components and in a small case
(SO8
>> is too big). After searching at ti.com I only found the TPS3813 - with
10uA
>> current consumption. Too much.
>> 
>> But then I stumbled through my archive of this list and there
>> was a suggestion: TI TPS3110K33 (2uA) - quite good. 
>> 
>> And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the
>> TPS3110 (only 2 pins swapped). The drawback is: one can get it only in
>> quantities of 2 or 2500. Does some of you know a distributor that would
sell
>> me e.g. 100pcs?
>> 
>> Are there other low current supervisor/watchdogs available? My TOP TWO
are
>> still the MAX6864 and the TPS3110 - I did'nt find better ones.
>> 
>>         Matthias

Am I really that bad?

Why might I expect brownout to occur in the first place? If I have no 
sound reason to expect it then I have no need to compensate for it. I do 
monitor my supplies constantly, and do a lot of power management, but in 
all of the testing I've done I've never experienced brown out once.

Al

Bill Knight wrote:

> Al
>   OK, I know I'm opening myself up for a "learning"
experience, but
> here goes anyway: What do you use for brownout detection and recovery?
> 
> -Bill Knight
> R O SoftWare
> 
> 
> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
> 
> 
> 
>>I don't use one, and have never had the need. Cheapest option
around.
> 
> 
>>;?}
> 
> 
>>Al
> 
> 
>>Matthias Weingart wrote:
> 
> 
>>>For my application I was looking for a very low current reset chips
-
>>>supervisor and watchdog with no external components and in a small
case (SO8
>>>is too big). After searching at ti.com I only found the TPS3813 -
with 10uA
>>>current consumption. Too much.
>>>
>>>But then I stumbled through my archive of this list and there
>>>was a suggestion: TI TPS3110K33 (2uA) - quite good. 
>>>
>>>And there is the MAX6864 (0.2uA!). The pinout is nearly the same as
the
>>>TPS3110 (only 2 pins swapped). The drawback is: one can get it only
in
>>>quantities of 2 or 2500. Does some of you know a distributor that
would sell
>>>me e.g. 100pcs?
>>>
>>>Are there other low current supervisor/watchdogs available? My TOP
TWO are
>>>still the MAX6864 and the TPS3110 - I did'nt find better ones.
>>>
>>>        Matthias
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Sorry Al, I definitely should have inserted a <grin> or two in my
message.  Though your dogged support for assembly language is legendary,
your experience with both the MSP and with low power, embedded systems
design is equally impressive.  And unlike many (myself included), you
always seem ready to help those who are able to post a reasonable question.

I had to ponder your response.  It is not really something I had consider
recently.  And yes, I must admit there are probably many designs in which
recovering from a brownout may not be required.  However, there are systems
in which it is necessary.  In one instance, the design was for an inductively
coupled and powered interface device that allowed non-contact reading of
water meters.  The reader would output a 32-40KHz "tone" into/onto 1/2
of a pot-core transformer.  The device had the other half of the transformer
as its input and power supply.  The reader would on/off modulate the tone
to send data to the device.  The device would send back data by modulating
the transformer when the reader was silent.  All the while the device was
rectifying the output of the transformer and using it for its power source.
The problem came when the reader/device transformer coupling (it was positioned
by the person doing the meter reading) was either insufficient or dropped out
while the device was in operation.  The reading could be retaken but recovering
from the brownout was necessary.

-Bill

On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:


>Am I really that bad?

>Why might I expect brownout to occur in the first
place? If I have no 
>sound reason to expect it then I have no need to compensate for it. I do 
>monitor my supplies constantly, and do a lot of power management, but in 
>all of the testing I've done I've never experienced brown out
once.

>Al

>Bill Knight wrote:

>> Al
>>   OK, I know I'm opening myself up for a "learning"
experience, but
>> here goes anyway: What do you use for brownout detection and recovery?
>> 
>> -Bill Knight
>> R O SoftWare
>> 
>> 
>> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
>> 
>> 
>> 
>>>I don't use one, and have never had the need. Cheapest option
around.
>> 
>> 
>>>;?}
>> 
>> 
>>>Al

<<<<  snip >>>>

Hi Bill and Al,

I've done several apps where brownout protection was paramount, and 
by the same token I've known an Oz based company that was exporting
critical industrial systems, such as Mains Water pollution (backflow)
monitoring,
where they were shipping F149 based designs without even as much as the use of
the 
watchdog, and their USA client was very happy, no problems.
I personally found it bizarre, but maybe they were using really sound HW design
- dunno -
...which would equally support Al's assertion.
(I only did the RF for them)

My personal experience is that - ironically - brown out protection is very
important
on battery powered products, where eg. AA alkalines and the likes are replaced.
The bounce in the battery holder seems to be unfriendly to an MCU w/o BOD.

Finally, I think it's important to establish what "brown out"
means for each of us.
For me brown out includes Vcc "sagging" fast, but then eg. rise
slower, but equally
includes transients that go right through the regulator (the feedback in LDO
isn't fast
enough), and even ceramic (thru hole) bypass caps couldn't kill it enough.
Transils seem the sure fire way.
Nowdays LDOs are much better by taking care wrt ESR on eg. SMT tantalum caps.
(ie. ensuring an optimal ESR)

Example : Around 1992 or so when the XC705P9 was introduced, I had nightmare 
problems with its MCU clock getting a "cardiac arrest". The WD was
clocked from the Xtal, 
so nodes would occasionally fail. This was used in large Emergency lighting
monitoring networks,
(up to 6-8 K nodes in one building) - and big FL battens where a chunky relay
switched the FL 
from mains-ballast to inverter (with local battery) on power loss, the relay
contacts arced like the 
4th of July. (I found that the manufacturer's inverter would rise to a
600-800 V, before having
the FL (relay) connected, thus the gas hadn't fired yet - after all it will
fire at 90 Volts or so IIRC)
Certain fall/rise Vcc sequences would kill the MCU clock...
This was catastrophic, as they'd sometimes happily freeze on the RS485
while in TX @#$%!!!
(killing a subnet)
Anyhow, eventually I convinced them to use Motorola zero crossing detect optos
with a TRIAC.

Shortly after I redesigned it on PIC16C71, and the network nodes NEVER failed
again.
Back then I loved PICs, and their superior QA, finally someone put the WD on an
RC clock !!!
We'd run 3000 in one go, and NONE would fail in programming (OTP), and
average
_one_ would fail (out of 3 K) after wave soldering....

Basically, I think Al and Bill both equally make a good point.

-- Kris


> Sorry Al, I definitely should have inserted a
<grin> or two in my
> message.  Though your dogged support for assembly language is legendary,
> your experience with both the MSP and with low power, embedded systems
> design is equally impressive.  And unlike many (myself included), you
> always seem ready to help those who are able to post a reasonable question.
> 
> I had to ponder your response.  It is not really something I had consider
> recently.  And yes, I must admit there are probably many designs in which
> recovering from a brownout may not be required.  However, there are systems
> in which it is necessary.  In one instance, the design was for an
inductively
> coupled and powered interface device that allowed non-contact reading of
> water meters.  The reader would output a 32-40KHz "tone"
into/onto 1/2
> of a pot-core transformer.  The device had the other half of the
transformer
> as its input and power supply.  The reader would on/off modulate the tone
> to send data to the device.  The device would send back data by modulating
> the transformer when the reader was silent.  All the while the device was
> rectifying the output of the transformer and using it for its power source.
> The problem came when the reader/device transformer coupling (it was
positioned
> by the person doing the meter reading) was either insufficient or dropped
out
> while the device was in operation.  The reading could be retaken but
recovering
> from the brownout was necessary.
> 
> -Bill
> 
> On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:
> 
> 
> >Am I really that bad?
> 
> >Why might I expect brownout to occur in the first place? If I have no 
> >sound reason to expect it then I have no need to compensate for it. I
do 
> >monitor my supplies constantly, and do a lot of power management, but
in 
> >all of the testing I've done I've never experienced brown out
once.
> 
> >Al
> 
> >Bill Knight wrote:
> 
> >> Al
> >>   OK, I know I'm opening myself up for a "learning"
experience, but
> >> here goes anyway: What do you use for brownout detection and
recovery?
> >> 
> >> -Bill Knight
> >> R O SoftWare
> >> 
> >> 
> >> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
> >> 
> >> 
> >> 
> >>>I don't use one, and have never had the need. Cheapest
option around.
> >> 
> >> 
> >>>;?}
> >> 
> >> 
> >>>Al
> 
> <<<<  snip >>>>
> 
> 
> 
> 
> .
> 
> 
> 
> 
>       
>            
>      
>      
> 
> 
> --------
> . 
> 
> 

Hi Bill, I was only joking too, as you probbaly realise it doesn't 
bother me too much what others think, unless it gets to the point where 
the majority here get ticked off. Other wise I'll go on trying to be 
helpful when I can. I simply still get a kick out of designing and 
programming, and hope to be able to pass a little of that on. As to my 
dogged support for assembler, it is simply that, these days, I usually 
seem to find myself doing stuff that pushes the envelope a little. and 
am so accustomed to it by now, and have so many libraries that it really 
is so much easier for me than C, or speed (more often than program size) 
dictates that I have no option.

I fully understand that there are odd times when brown outs can't be 
avoided, as in your example, or even on mains powered designs, but, in 
recent years I think only my latest project is mains powered, all the 
others use switchers, battery monitors, etc. So I can perform and 
orderly shut down before things get too uncomfortable.

Cheers

Al


Bill Knight wrote:
> Sorry Al, I definitely should have inserted a <grin> or two in my
> message.  Though your dogged support for assembly language is legendary,
> your experience with both the MSP and with low power, embedded systems
> design is equally impressive.  And unlike many (myself included), you
> always seem ready to help those who are able to post a reasonable question.
> 
> I had to ponder your response.  It is not really something I had consider
> recently.  And yes, I must admit there are probably many designs in which
> recovering from a brownout may not be required.  However, there are systems
> in which it is necessary.  In one instance, the design was for an
inductively
> coupled and powered interface device that allowed non-contact reading of
> water meters.  The reader would output a 32-40KHz "tone"
into/onto 1/2
> of a pot-core transformer.  The device had the other half of the
transformer
> as its input and power supply.  The reader would on/off modulate the tone
> to send data to the device.  The device would send back data by modulating
> the transformer when the reader was silent.  All the while the device was
> rectifying the output of the transformer and using it for its power source.
> The problem came when the reader/device transformer coupling (it was
positioned
> by the person doing the meter reading) was either insufficient or dropped
out
> while the device was in operation.  The reading could be retaken but
recovering
> from the brownout was necessary.
> 
> -Bill
> 
> On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:
> 
> 
> 
>>Am I really that bad?
> 
> 
>>Why might I expect brownout to occur in the first place? If I have no 
>>sound reason to expect it then I have no need to compensate for it. I do

>>monitor my supplies constantly, and do a lot of power management, but in

>>all of the testing I've done I've never experienced brown out
once.
> 
> 
>>Al
> 
> 
>>Bill Knight wrote:
> 
> 
>>>Al
>>>  OK, I know I'm opening myself up for a "learning"
experience, but
>>>here goes anyway: What do you use for brownout detection and
recovery?
>>>
>>>-Bill Knight
>>>R O SoftWare
>>>
>>>
>>>On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
>>>
>>>
>>>
>>>
>>>>I don't use one, and have never had the need. Cheapest
option around.
>>>
>>>
>>>>;?}
>>>
>>>
>>>>Al
> 
> 
> <<<<  snip >>>>
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

microbit wrote:

> Hi Bill and Al,
> 
> I've done several apps where brownout protection was paramount, and 
> by the same token I've known an Oz based company that was exporting
> critical industrial systems, such as Mains Water pollution (backflow)
monitoring,
> where they were shipping F149 based designs without even as much as the use
of the 
> watchdog, and their USA client was very happy, no problems.
> I personally found it bizarre, but maybe they were using really sound HW
design - dunno -
> ...which would equally support Al's assertion.
> (I only did the RF for them)

I only speak for myself on this. I know there are certainly designs that 
may be prone to brownout. particularly as you state later in battery 
based designs where the holders are a bit suspect;. equally, to me, this 
is part of the design mantra. I use batteries, but I use LI-polys 
soldered to the PCB in 99% of cases. No contact bounce. Again, to 
overcome anohter problem I used to expereicne with RFM wireless stuff 
using coin cells I decided NOT to just use batteries, smaller batteries 
can droop enormously, very fast as peripherals are running, causing a 
brownout event. Now its switchers and adequate C to ensure that any 
switching loads are smoothly handled. The cost is well worth it to me.

> 
> My personal experience is that - ironically - brown out protection is very
important
> on battery powered products, where eg. AA alkalines and the likes are
replaced.
> The bounce in the battery holder seems to be unfriendly to an MCU w/o BOD.
> 
> Finally, I think it's important to establish what "brown
out" means for each of us.
> For me brown out includes Vcc "sagging" fast, but then eg. rise
slower, but equally
> includes transients that go right through the regulator (the feedback in
LDO isn't fast
> enough), and even ceramic (thru hole) bypass caps couldn't kill it
enough.
> Transils seem the sure fire way.
> Nowdays LDOs are much better by taking care wrt ESR on eg. SMT tantalum
caps.
> (ie. ensuring an optimal ESR)
> 
> Example : Around 1992 or so when the XC705P9 was introduced, I had
nightmare 
> problems with its MCU clock getting a "cardiac arrest". The WD
was clocked from the Xtal, 
> so nodes would occasionally fail. This was used in large Emergency lighting
monitoring networks,
> (up to 6-8 K nodes in one building) - and big FL battens where a chunky
relay switched the FL 
> from mains-ballast to inverter (with local battery) on power loss, the
relay contacts arced like the 
> 4th of July. (I found that the manufacturer's inverter would rise to a
600-800 V, before having
> the FL (relay) connected, thus the gas hadn't fired yet - after all it
will fire at 90 Volts or so IIRC)
> Certain fall/rise Vcc sequences would kill the MCU clock...
> This was catastrophic, as they'd sometimes happily freeze on the RS485
while in TX @#$%!!!
> (killing a subnet)
> Anyhow, eventually I convinced them to use Motorola zero crossing detect
optos with a TRIAC.

Most of the old HC05/HC11 HCMOS stuff was incredibly prone to latch up 
caused by small negative ground transients. I first discovered this in a 
commercial security system based on a P9 that I was functionally 
duplicating (the taiwanese company hired to produce the system refused 
to delliver the code or other design data to the company, even though 
they'd paid for them, and were selling to the clients competitors) I met 
it again on an E9 based ECU.this was when I first started using the 
SP720. Anything >Vcc+0.6 on Vcc or < gnd-.6 on ground would or could 
latch the micro. The SP720 limits these spikes to < 0.3V

> 
> Shortly after I redesigned it on PIC16C71, and the network nodes NEVER
failed again.
> Back then I loved PICs, and their superior QA, finally someone put the WD
on an RC clock !!!
> We'd run 3000 in one go, and NONE would fail in programming (OTP), and
average
> _one_ would fail (out of 3 K) after wave soldering....

PICs got a LOT of things right, I was a big fan for many years, but 
after a while got too fed up waiting for the promised Flash/!* series 
etc. They were announced too soon, and delayed too often, it totally 
turned me off Microchip for some time.

Al

> 
> Basically, I think Al and Bill both equally make a good point.
> 
> -- Kris
> 
> 
> 
>>Sorry Al, I definitely should have inserted a <grin> or two in my
>>message.  Though your dogged support for assembly language is legendary,
>>your experience with both the MSP and with low power, embedded systems
>>design is equally impressive.  And unlike many (myself included), you
>>always seem ready to help those who are able to post a reasonable
question.
>>
>>I had to ponder your response.  It is not really something I had
consider
>>recently.  And yes, I must admit there are probably many designs in
which
>>recovering from a brownout may not be required.  However, there are
systems
>>in which it is necessary.  In one instance, the design was for an
inductively
>>coupled and powered interface device that allowed non-contact reading of
>>water meters.  The reader would output a 32-40KHz "tone"
into/onto 1/2
>>of a pot-core transformer.  The device had the other half of the
transformer
>>as its input and power supply.  The reader would on/off modulate the
tone
>>to send data to the device.  The device would send back data by
modulating
>>the transformer when the reader was silent.  All the while the device
was
>>rectifying the output of the transformer and using it for its power
source.
>>The problem came when the reader/device transformer coupling (it was
positioned
>>by the person doing the meter reading) was either insufficient or
dropped out
>>while the device was in operation.  The reading could be retaken but
recovering
>>from the brownout was necessary.
>>
>>-Bill
>>
>>On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:
>>
>>
>>
>>>Am I really that bad?
>>
>>>Why might I expect brownout to occur in the first place? If I have
no 
>>>sound reason to expect it then I have no need to compensate for it.
I do 
>>>monitor my supplies constantly, and do a lot of power management,
but in 
>>>all of the testing I've done I've never experienced brown
out once.
>>
>>>Al
>>
>>>Bill Knight wrote:
>>
>>>>Al
>>>>  OK, I know I'm opening myself up for a
"learning" experience, but
>>>>here goes anyway: What do you use for brownout detection and
recovery?
>>>>
>>>>-Bill Knight
>>>>R O SoftWare
>>>>
>>>>
>>>>On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I don't use one, and have never had the need. Cheapest
option around.
>>>>
>>>>
>>>>>;?}
>>>>
>>>>
>>>>>Al
>>
>><<<<  snip >>>>
>>
>>
>>
>>
>>.
>>
>>
>>
>>
>>      
>>           
>>     
>>     
>>
>>
>>--------
>>. 
>>
>>
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Hi Matthias,
it seems, as if there was no answer about distributor at all.
I found digikey (www.digikey.com) a good source for TI stuff. They are now
located in the Netherlands, with a 0800... phone number from Germany. And
getting stuff on account in  is possible as well as sending cash on delivery,
no need for expensive valuta exchange fees as with credit cards...

Harald Wehner

"Matthias Weingart" <msp430@msp4...> schrieb:
> 
> For my application I was looking for a very low current reset chips -
> supervisor and watchdog with no external components and in a small case
(SO8
> is too big). After searching at ti.com I only found the TPS3813 - with 10uA
> current consumption. Too much.
> 
> But then I stumbled through my archive of this list and there
> was a suggestion: TI TPS3110K33 (2uA) - quite good. 
> 
> And there is the MAX6864 (0.2uA!). The pinout is nearly the same as the
> TPS3110 (only 2 pins swapped). The drawback is: one can get it only in
> quantities of 2 or 2500. Does some of you know a distributor that would
sell
> me e.g. 100pcs?
> 
> Are there other low current supervisor/watchdogs available? My TOP TWO are
> still the MAX6864 and the TPS3110 - I did'nt find better ones.
> 
>         Matthias
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Brownout is important when the power source can be momentarily 
disconnected or could have bouncing contacts such as changing 
batteries like Kris mentioned below.  One glitch is enough to lockout 
a microprocessor.  But, if the power supply is designed to eliminate 
any of these "brownout" or "glitches" to the rest of the
circuit then 
there is no need to check for it.

Yvon.


--- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> Hi Bill and Al,
> 
> I've done several apps where brownout protection was paramount, and 
> by the same token I've known an Oz based company that was exporting
> critical industrial systems, such as Mains Water pollution 
(backflow) monitoring,
> where they were shipping F149 based designs
without even as much as 
the use of the 
> watchdog, and their USA client was very happy, no
problems.
> I personally found it bizarre, but maybe they were using really 
sound HW design - dunno -
> ...which would equally support Al's
assertion.
> (I only did the RF for them)
> 
> My personal experience is that - ironically - brown out protection 
is very important
> on battery powered products, where eg. AA
alkalines and the likes 
are replaced.
> The bounce in the battery holder seems to be
unfriendly to an MCU 
w/o BOD.
> 
> Finally, I think it's important to establish what "brown
out" means 
for each of us.
> For me brown out includes Vcc "sagging"
fast, but then eg. rise 
slower, but equally
> includes transients that go right through the
regulator (the 
feedback in LDO isn't fast
> enough), and even ceramic (thru hole) bypass caps
couldn't kill it 
enough.
> Transils seem the sure fire way.
> Nowdays LDOs are much better by taking care wrt ESR on eg. SMT 
tantalum caps.
> (ie. ensuring an optimal ESR)
> 
> Example : Around 1992 or so when the XC705P9 was introduced, I had 
nightmare 
> problems with its MCU clock getting a
"cardiac arrest". The WD was 
clocked from the Xtal, 
> so nodes would occasionally fail. This was used in
large Emergency 
lighting monitoring networks,
> (up to 6-8 K nodes in one building) - and big FL
battens where a 
chunky relay switched the FL 
> from mains-ballast to inverter (with local
battery) on power loss, 
the relay contacts arced like the 
> 4th of July. (I found that the manufacturer's
inverter would rise 
to a 600-800 V, before having
> the FL (relay) connected, thus the gas hadn't
fired yet - after all 
it will fire at 90 Volts or so IIRC)
> Certain fall/rise Vcc sequences would kill the MCU
clock...
> This was catastrophic, as they'd sometimes happily freeze on the 
RS485 while in TX @#$%!!!
> (killing a subnet)
> Anyhow, eventually I convinced them to use Motorola zero crossing 
detect optos with a TRIAC.
> 
> Shortly after I redesigned it on PIC16C71, and the network nodes 
NEVER failed again.
> Back then I loved PICs, and their superior QA,
finally someone put 
the WD on an RC clock !!!
> We'd run 3000 in one go, and NONE would fail
in programming (OTP), 
and average
> _one_ would fail (out of 3 K) after wave
soldering....
> 
> Basically, I think Al and Bill both equally make a good point.
> 
> -- Kris
> 
> 
> > Sorry Al, I definitely should have inserted a <grin> or two in
my
> > message.  Though your dogged support for assembly language is 
legendary,
> > your experience with both the MSP and with
low power, embedded 
systems
> > design is equally impressive.  And unlike
many (myself included), 
you
> > always seem ready to help those who are able
to post a reasonable 
question.
> > 
> > I had to ponder your response.  It is not really something I had 
consider
> > recently.  And yes, I must admit there are
probably many designs 
in which
> > recovering from a brownout may not be
required.  However, there 
are systems
> > in which it is necessary.  In one instance,
the design was for an 
inductively
> > coupled and powered interface device that
allowed non-contact 
reading of
> > water meters.  The reader would output a
32-40KHz "tone" 
into/onto 1/2
> > of a pot-core transformer.  The device had
the other half of the 
transformer
> > as its input and power supply.  The reader
would on/off modulate 
the tone
> > to send data to the device.  The device would
send back data by 
modulating
> > the transformer when the reader was silent. 
All the while the 
device was
> > rectifying the output of the transformer and
using it for its 
power source.
> > The problem came when the reader/device
transformer coupling (it 
was positioned
> > by the person doing the meter reading) was
either insufficient or 
dropped out
> > while the device was in operation.  The
reading could be retaken 
but recovering
> > from the brownout was necessary.
> > 
> > -Bill
> > 
> > On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:
> > 
> > 
> > >Am I really that bad?
> > 
> > >Why might I expect brownout to occur in the first place? If I 
have no 
> > >sound reason to expect it then I have no
need to compensate for 
it. I do 
> > >monitor my supplies constantly, and do a
lot of power 
management, but in 
> > >all of the testing I've done
I've never experienced brown out 
once.
> > 
> > >Al
> > 
> > >Bill Knight wrote:
> > 
> > >> Al
> > >>   OK, I know I'm opening myself up for a
"learning" 
experience, but
> > >> here goes anyway: What do you use
for brownout detection and 
recovery?
> > >> 
> > >> -Bill Knight
> > >> R O SoftWare
> > >> 
> > >> 
> > >> On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
> > >> 
> > >> 
> > >> 
> > >>>I don't use one, and have never had the need.
Cheapest option 
around.
> > >> 
> > >> 
> > >>>;?}
> > >> 
> > >> 
> > >>>Al
> > 
> > <<<<  snip >>>>
> > 
> > 
> > 
> > 
> > .
> > 
> > 
> > 
> > 
> >       
> >            
> >      
> >      
> > 
> > 
> > ------------------------------
--------------
> > Yahoo! Groups Links
> > 
> >   a.. To visit your group on the web, go to:
> >   http://groups.yahoo.com/group/msp430/
> >     
> >   b.. .
> >     
> >   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of 
Service. 
> > 
> > 
> 
>