Searching \ for '[PIC]:Reinitializing registers on reset (was New t' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Reinitializing registers on reset (was New t'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Reinitializing registers on reset (was New t'
2000\09\19@075338 by Bob Ammerman

picon face
Ok, the MChip spec sheets go to great trouble to define the state of various
registers on a reset.

The 'wisdom' here is that you ignore that and reinitialize them anyway.

Is this really needed?

What next, are we going to assume that ADDWF won't correctly add 2 + 2.

When you start doubting that a chip is following spec in one area, you have
to, for consistency, assume it could fail in any other area.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\09\19@101411 by Barry King

flavicon
face
Bob,

> The 'wisdom' here is that you ignore that and reinitialize them anyway.
>
> Is this really needed?
> What next, are we going to assume that ADDWF won't correctly add 2 + 2.

No, the reason for re-initializing is not that we don't believe the
chip will reset.  I do it because:

1) The reset state is rarely what "I" want, and since we're
initializing anyhow, I run the whole re-init.

2) The init code and its /* comments */ document how you WANT it set
up!  This is the most common benefit for me.

3) I don't have to remember how Microchip left it after reset, and
when I port the same code to a different chip, with different reset
state, my code still works.  Re-use Rules!

Regards,

Barry.
------------
Barry King, KA1NLH
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the accumulated (PIC) wisdom of the ages at:
PIC/PICList FAQ: http://www.piclist.org

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\19@112807 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

Bob Ammerman wrote:

>The 'wisdom' here is that you ignore that and reinitialize them anyway.

No, only the once's you are depending on.

>Is this really needed?

Yes, for most cases, case in point: The 'default' of PORTA in 16F87x
series
as analogue input. On previous chips ( most of them ) all ports were
digital unless otherwise configured. If one were depending on this
and, my main argument, did not document this 'assumption' on code that
was supposed to be ported, things can/will go wrong. Yes ofcource it is
no excuse for not reading the data sheet before one attempt to port code
between pic's, but still.

>What next, are we going to assume that ADDWF won't correctly add 2 + 2.
>When you start doubting that a chip is following spec in one area, you
have
>to, for consistency, assume it could fail in any other area.

No :-), my point is no such much in NOT trusting the defaults as to
clearly initializing/documenting the EXACT startup state of the pic (
with periphials )
for this particular piece of software.

If one writes routines like: INIT_PORTS, INIT_SPI, INIT_XXX and in these
routines
configure ( and document ) how things are setup and WHY. Then the code
is much easier
to understand/read/port both for other people and for yourself ( after 6
months :) ).
Also makes it easier to handle things like BOR ( try that without
'proper' initialization code ).


But I'm not against 'saving code' by assuming ( or let me rephrase
'depend' ) on that
the default state of registers/ports. But it should then be clearly
documented
that this assumption was made.

/Tony



Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: spam_OUTtony.kubekTakeThisOuTspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\19@124027 by Dan Michaels

flavicon
face
Bob Ammerman wrote:
>Ok, the MChip spec sheets go to great trouble to define the state of various
>registers on a reset.
>
>The 'wisdom' here is that you ignore that and reinitialize them anyway.
>
>Is this really needed?
>
>What next, are we going to assume that ADDWF won't correctly add 2 + 2.
>


What next is that you can write a callable routine that initializes all
the registers to a known state, and then call this routine - in s.w. -
whenever you want to get the processor back into that state. Has nothing
to do with "faith".

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\19@125449 by staff

flavicon
face
Bob Ammerman wrote:
>
> Ok, the MChip spec sheets go to great trouble to define the state of various
> registers on a reset.
>
> The 'wisdom' here is that you ignore that and reinitialize them anyway.
>
> Is this really needed?
>
> What next, are we going to assume that ADDWF won't correctly add 2 + 2.
>
> When you start doubting that a chip is following spec in one area, you have
> to, for consistency, assume it could fail in any other area.
>
> Bob Ammerman
> RAm Systems


Afraid I'm guilty of this too Bob. I always think that reset
or power up reset may be caused by some scary power spike etc,
and a safe clear of all ram only costs a few bytes and makes
me feel happier even if logic tells me it might be a waste.

You sound like an engineer, I'm not an engineer but originally
trained as a repairer. We fix the things engineers design ;o)
That's a good education in itself.

Anyway, I look at it like insurance, even though logically it
may never be needed, it has tiny cost and great safety so I
do it. If it makes you feel any better I also put code modules
in that check memory state and for other faults and correct
them. They will probably never be used either.

I also build power supplies with excessive sized filters
and other safety factors that seem silly based on the
correct formulas. I also have never had a supply fail, but I
have repaired many others that were designed TO the safe
formulas. Maybe sometimes an engineer has to break the rules
and build something exceptional, instead of just build
somthing correct?

Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\19@132424 by Bob Ammerman

picon face
----- Original Message -----
From: Barry King <.....barryKILLspamspam@spam@NRGSYSTEMS.COM>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Tuesday, September 19, 2000 11:02 AM
Subject: Re: [PIC]:Reinitializing registers on reset (was New to this world)


{Quote hidden}

Ok... why not just make the changes?

> 2) The init code and its /* comments */ document how you WANT it set
> up!  This is the most common benefit for me.

Ok... but why not just the comments (you do make sure your comments
accurately reflect the real world, don't you?)

> 3) I don't have to remember how Microchip left it after reset, and
> when I port the same code to a different chip, with different reset
> state, my code still works.  Re-use Rules!

Ah... this is by far the best argument here

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\19@132436 by Bob Ammerman

picon face
But I'm not against 'saving code' by assuming ( or let me rephrase
'depend' ) on that
the default state of registers/ports. But it should then be clearly
documented
that this assumption was made.

/Tony

I concur exactly.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\20@124534 by Bruce Cannon

picon face
Bob, it's something I've been worrying about for a while; in Mchip seminars
they tell me to "think robust", and always reinitialize in all sorts of
different situations, but it really troubles me because if ANY register is
corrupt then you must assume they ALL might be corrupt, right?  I'd like to
learn more about how they do it in the auto world, where there's bootloads
of trauma circulating around...

Bruce Cannon
Style Management Systems
http://siliconcrucible.com
(510) 787-6870
1228 Ceres ST Crockett CA 94525

Remember: electronics is changing your world...for good!

{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\09\20@153803 by Olin Lathrop

flavicon
face
> I'd like to
> learn more about how they do it in the auto world, where there's bootloads
> of trauma circulating around...

Low priced software engineers, with the savings going into high priced
lawyers ;-)


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam.....cognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\09\20@163606 by Bob Ammerman

picon face
For one thing, I'm guessing that the WDT intervals in some automotive
products are _very_ short.

Also, a lot of effort goes into making things fail intelligently. For
example, if an engine sensor goes bad, the engine control computer will
usually be able to limp along allowing you to get the car in for service.
(the famous 'check engine light' scenario).

I've run into similar things in my work on power plants. Basically very
simple, highly reliable systems are capable of keeping things running when
the more complex advanced systems fail.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)



{Original Message removed}

2000\09\23@032510 by Peter L. Peres

picon face
One way that works for me is to initialize all registers after reset and
run with WDT on, and deliberately allow the WDT to trip every time you can
afford it (i.e. about every 2 seconds in the idle loop). This means that
you have clrwdt instructions only in a certain shared main program branch
but none in the main loop, and some in longer duration subroutines. So far
this scheme has worked well with inconsistent power supplies and other
problematic projects. But I am not a large volume manuf..

Peter

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...