Searching \ for '[PIC] the result of rest' 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: 'the result of rest'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] the result of rest'
2004\10\21@093424 by Wang Zhaoyue

picon face
What will general purpose registers be after rest in 16f877?
The data sheet lists the value of lots registers after rest, but not
mentions
the general purpose registers.

thx a lot!

Zhaoyue Wang

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/

____________________________________________

2004\10\21@095803 by Herbert Graf

flavicon
face
On Thu, 2004-10-21 at 09:30, Wang Zhaoyue wrote:
> What will general purpose registers be after rest in 16f877?
> The data sheet lists the value of lots registers after rest, but not
> mentions
> the general purpose registers.

Their value after reset is undefined, so assume whatever is in them is
garbage to you and initialize if necessary.

This is also true after powerup. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

____________________________________________

2004\10\21@095918 by hael Rigby-Jones

picon face


>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu]
>On Behalf Of Wang Zhaoyue
>Sent: 21 October 2004 14:30
>To: piclistspamKILLspammit.edu
>Subject: [PIC] the result of rest
>
>
>What will general purpose registers be after rest in 16f877?
>The data sheet lists the value of lots registers after rest, but not
>mentions
>the general purpose registers.
>
>thx a lot!
>
>Zhaoyue Wang

Contents of the general purpose registers after a power-on reset are
undefined, you cannot rely on them having any value. If you need them to be
in a defined state you need to implement some startup code to do this.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
____________________________________________

2004\10\21@100611 by olin_piclist

face picon face
Wang Zhaoyue wrote:
> What will general purpose registers be after rest in 16f877?
> The data sheet lists the value of lots registers after rest, but not
> mentions
> the general purpose registers.

They don't get tired much, so it probably doesn't matter.

General RAM retains its value as long as Vdd remains above the "RAM
retention voltage" spec.  Once Vdd goes below that, you should assume all of
RAM gets randomized.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\21@100838 by Jan-Erik Soderholm

face picon face
Wang Zhaoyue wrote :

> What will general purpose registers be after rest in 16f877?

Is "rest" = "half-sleep" :-)

(Sorry about that... :-) )

Anyway...
Always look at them as "undefined".
Never expect them to have any specific value.

Jan-Erik.
____________________________________________

2004\10\21@101056 by olin_piclist

face picon face
Herbert Graf wrote:
>> What will general purpose registers be after rest in 16f877?
>> The data sheet lists the value of lots registers after rest, but not
>> mentions
>> the general purpose registers.
>
> Their value after reset is undefined,

Actually it is.  That's what the minimum RAM retention voltage spec is all
about.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\10\21@101857 by Byron A Jeff

face picon face
On Thu, Oct 21, 2004 at 09:30:20PM +0800, Wang Zhaoyue wrote:
> What will general purpose registers be after rest in 16f877?
> The data sheet lists the value of lots registers after rest, but not
> mentions
> the general purpose registers.

Two points:

1) After a power on reset they will have random values.

2) However if it's a MCLR only reset with power applied all the way through
they are guaranteed to have the value they had when the MCLR reset occured.
Wouter van Ooijen exploits this property in his ZPL bootloader.

BAJ
____________________________________________

2004\10\21@110541 by Wouter van Ooijen

face picon face
> 2) However if it's a MCLR only reset with power applied all
> the way through
> they are guaranteed to have the value they had when the MCLR
> reset occured.
> Wouter van Ooijen exploits this property in his ZPL bootloader.

There are other (earlier!) exploits of this, like using the watchsdog to
measure temperature.

So: initially don't assume anything, not even random!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\21@111010 by Ken Pergola

flavicon
face

Hi Zhaoyue,

Once the contents of the general purpose registers have been assigned a
value programmatically, the really important thing you need to ensure is
that you do not violate the 'RAM Data Retention Voltage' parameter (listed
in the data sheet), otherwise you cannot assure that their contents will not
be compromised. Typically it's around 1.5 volts with respect to Vss, but you
really need to consult the data sheet of your specific PICmicro in question
to be certain.

Please note that you definitely can have certain resets *without* the resets
destroying the contents of the general purpose registers (and in some cases
some of the SFRs). The exception to this would of course be the power-on
reset (POR) in which you can't assume any default values for general purpose
registers only.

As far as Special Function Registers (SFRs) are concerned, the story is
different, some SFRs are known at POR, some are unknown at POR. Some get
initialized under various resets, and some don't. Please consult the data
sheet which details specific initialization conditions for SFRs  under
various resets in a nice table.

Best regards,

Ken Pergola


P.S. It's also very important to note, and be open to the fact, that
documentation errors do sometimes happen. If you ever find something that
refutes what the data sheet says, it could be a documentation error.


____________________________________________

2004\10\21@111635 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Michael Rigby-Jones" <.....Michael.Rigby-JonesKILLspamspam.....bookham.com>
Subject: RE: [PIC] the result of rest


> Contents of the general purpose registers after a power-on reset are
> undefined, you cannot rely on them having any value.

By the way, this is one of the places where the simulator does a bad job.
The simulator begins with all the GPRs having a zero, and always assumes
power remains during a reset.

In the real world, loss of power does NOT result in the GPRs containing
zero.  The contents are random. (Well, they probably aren't truly random,
but for any practical purpose they should be assumed to be.)

72/73 de WB8RCR    http://www.qsl.net/wb8rcr
didileydadidah     QRP-L #1446 Code Warriors #35



____________________________________________

2004\10\21@112257 by Ken Pergola

flavicon
face


Hi Zhaoyue,

I also forgot to mention that the 'RAM Data Retention Voltage' parameter
applies to both the GPRs and the SFRs -- in other words, as it name implies,
*all* RAM. I just wanted to be clear about this.

Best regards,

Ken Pergola


____________________________________________

2004\10\21@113517 by Mike Hord

picon face
> P.S. It's also very important to note, and be open to the fact, that
> documentation errors do sometimes happen. If you ever find something that
> refutes what the data sheet says, it could be a documentation error.

In which case, check the errata for your processor before sending
an angry e-mail to anyone.

Mike H.
____________________________________________

2004\10\21@115036 by Jan-Erik Soderholm

face picon face
John J. McDonough wrote :

> > Contents of the general purpose registers after a power-on reset are
> > undefined, you cannot rely on them having any value.
>
> By the way, this is one of the places where the simulator
> does a bad job.
> The simulator begins with all the GPRs having a zero, and
> always assumes power remains during a reset.

OK. But then, what *should* the simulator do ?

Jan-Erik.
____________________________________________

2004\10\21@120006 by Ken Pergola

flavicon
face

John J. McDonough wrote:

> By the way, this is one of the places where the simulator does a bad job.
> The simulator begins with all the GPRs having a zero, and always assumes
> power remains during a reset.

Hi John,

Have you suggested to Microchip that maybe they should change this? I've
found that the Microchip employees I deal with on the Microchip Forums are
very responsive to the feature requests I have suggested. MPLAB IDE will
only get better through the feedback and suggestions of users. It only takes
a few minutes and is worth the time in my opinion.

Best regards,

Ken Pergola


____________________________________________

2004\10\21@120654 by Alan B. Pearce

face picon face
>By the way, this is one of the places where the
>simulator does a bad job. The simulator begins
>with all the GPRs having a zero, and always
>assumes power remains during a reset.

However it does also have a function that allows you to fill the registers
with scrambled values. IIRC it does it to every register, including the ones
which do have specific power on reset values, so they do not represent the
normal power on reset values.

____________________________________________

2004\10\21@131730 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Jan-Erik Soderholm" <EraseMEjan-erik.soderholmspam_OUTspamTakeThisOuTtelia.com>
Subject: RE: [PIC] the result of rest


> OK. But then, what *should* the simulator do ?

I'm not convinced that I would like something better, but I thought it bore
mention since last week someone was asking about the simulator and I don't
recall this particular issue coming up.

For the uninitiated, it seems "natural" to assume that RAM is zero on power
up, and most C compilers clear all static variables on initialization, so
someone unfamiliar with the PIC could get misled by this behavior.

On the other hand, I expect to have to initialize memory locations I use,
and it is sort of nice to be able to immediately identify anything I've
changed.  I'm not so sure I would like it to come up random.

Someone mentioned a randomize RAM menu selection, which I haven't found.
That would be a good move, IMO.  That still doesn't help the uninitiated,
but could be helpful in some cases.

--McD


____________________________________________

2004\10\21@140339 by piclist

flavicon
face
John J. McDonough wrote:

> By the way, this is one of the places where the simulator does a bad job.
> The simulator begins with all the GPRs having a zero, and always assumes
> power remains during a reset.

The simulator does have an option for doing a random fill of the GPRs
(right click on the File Registers window).  It doesn't appear that
there's any way of making this happen automatically, though.

--
John W. Temples, III
____________________________________________

2004\10\21@140633 by Jan-Erik Soderholm

face picon face
John J. McDonough wrote :

>
> > OK. But then, what *should* the simulator do ?
>
> On the other hand, I expect to have to initialize memory
> locations I use, and it is sort of nice to be able to
> immediately identify anything I've changed.

Maybe a warning or diagnostic message that you are
reading from an "un-written" GPR. The simulator needs
a flag for each GPR that is set "unwritten" on reset, and
"written" as soon as some instruction writes to it...

Jan-Erik.
____________________________________________

2004\10\21@142550 by Bob Ammerman

picon face
From: "Wang Zhaoyue" <wzy1117spamspam_OUThotmail.com>
> What will general purpose registers be after rest in 16f877?
> The data sheet lists the value of lots registers after rest, but not
> mentions
> the general purpose registers.
>
> thx a lot!
>
> Zhaoyue Wang

After power on reset:

Random, or else just exactly what you don't want them to be.

After other resets (like watchdot, MCLR, etc):

Unchanged

Bob Ammerman
RAm Systems


____________________________________________

2004\10\21@143104 by Peter Johansson

flavicon
face
Jan-Erik Soderholm writes:

> John J. McDonough wrote :
>
> >
> > > OK. But then, what *should* the simulator do ?
> >
> > On the other hand, I expect to have to initialize memory
> > locations I use, and it is sort of nice to be able to
> > immediately identify anything I've changed.
>
> Maybe a warning or diagnostic message that you are
> reading from an "un-written" GPR. The simulator needs
> a flag for each GPR that is set "unwritten" on reset, and
> "written" as soon as some instruction writes to it...

No maybe about this one.  This *is* the proper solution.

-p.
____________________________________________

2004\10\21@145923 by Scott Dattalo

face
flavicon
face
On Thu, 21 Oct 2004, Ken Pergola wrote:

>
> John J. McDonough wrote:
>
>> By the way, this is one of the places where the simulator does a bad job.
>> The simulator begins with all the GPRs having a zero, and always assumes
>> power remains during a reset.
>
> Hi John,
>
> Have you suggested to Microchip that maybe they should change this? I've
> found that the Microchip employees I deal with on the Microchip Forums are
> very responsive to the feature requests I have suggested. MPLAB IDE will
> only get better through the feedback and suggestions of users. It only takes
> a few minutes and is worth the time in my opinion.

Ken,

One feature that I've recently added to my simulator, gpsim, is 3-state
logic for all registers. It's main purpose is to handle uninitialized
registers. This feature has not yet propogated fully through the PIC
processor modules. However, in one of my proprietary processor models the
feature is fully supported.

One of the useful features of 3-state logic, is that the values can
propogate through an algorithm. For example:

Start:

  ; MyReg and MyOtherReg have not been initialized
  ; and thus contain unknown values.

    CLRF  MyReg          ;MyReg is now initialized

    MOVF  MyOtherReg,W   ;W contains an uninitialized
                         ;value

    MOVWF MyReg          ;MyReg is uninitialed again


In addition, the status bits can get into an uninitialized state if
instructions that affect the status register operate on uninitialized
data. At the moment (in my proprietary processor module), conditional
branches based on uninitialized data halt the simulation. However, I'm
working on a feature where for skip instructions a merging operation can
be performed. For example:

 ; Myreg is unitialized

     ADDWF  MyReg,W

     MOVLW  0x0F
     SKPC
      MOVLW 0x00

 ; at this point, the upper nibble of W contains zero, but the
 ; lower nibble contains an uninitialized value.


Scott
____________________________________________

2004\10\21@152618 by Bob Ammerman

picon face
> ----- Original Message -----
> From: "Michael Rigby-Jones" <@spam@Michael.Rigby-JonesKILLspamspambookham.com>
> Subject: RE: [PIC] the result of rest
>
>
>> Contents of the general purpose registers after a power-on reset are
>> undefined, you cannot rely on them having any value.
>
> By the way, this is one of the places where the simulator does a bad job.
> The simulator begins with all the GPRs having a zero, and always assumes
> power remains during a reset.
>
> In the real world, loss of power does NOT result in the GPRs containing
> zero.  The contents are random. (Well, they probably aren't truly random,
> but for any practical purpose they should be assumed to be.)
>
> 72/73 de WB8RCR    http://www.qsl.net/wb8rcr
> didileydadidah     QRP-L #1446 Code Warriors #35

Don't, for example, check a few locations for expected values to decide that
this is a non-power down reset. There are SFR flags for this sort of thing.

Bob Ammerman
RAm Systems

____________________________________________

2004\10\21@155734 by Ken Pergola

flavicon
face

Scott Dattalo wrote:

> One feature that I've recently added to my simulator, gpsim, is 3-state
> logic for all registers. It's main purpose is to handle uninitialized
> registers. This feature has not yet propogated fully through the PIC
> processor modules. However, in one of my proprietary processor models the
> feature is fully supported.


Hi Scott,

Thanks for the information. I have never tried gpsim -- it sounds
interesting. Is there a Windows executable for it at this time? I realize
you have plans for one.

By the way, I would venture to guess that you must have spend hundreds (or
thousands?) of hours developing gpsim. What programming language did you use
to develop it?

Thanks again for your contributions.

Thanks,

Ken Pergola




____________________________________________

2004\10\23@004932 by Peter van Hoof

picon face
IMHO the registers should have a additional state (call it undefined) that
only becomes defined when loaded with a literal or loaded with the result of
a literal this way you would be warned about not initialising your ram. the
user should be able to shut this off because all this extra bit twiddeling
is going to cost extra time and speed

Peter van hoof

{Original Message removed}

2004\10\23@013512 by Scott Dattalo

face
flavicon
face
On Sat, 23 Oct 2004, Peter van Hoof wrote:

> IMHO the registers should have a additional state (call it undefined) that
> only becomes defined when loaded with a literal or loaded with the result of
> a literal this way you would be warned about not initialising your ram. the
> user should be able to shut this off because all this extra bit twiddeling is
> going to cost extra time and speed

Peter,

Are you saying that a simulator should behave the way I described gpsim's
behavior a couple posts ago? :)

gpsim does exactly what you say - though I haven't implemented this
feature fully for the PIC processors. In addition to what you describe,
gpsim also has the capability of propogating unknown state just like it
can propogate 1's and 0's.

Scott
____________________________________________

2004\10\24@074713 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Wang Zhaoyue" <KILLspamwzy1117KILLspamspamhotmail.com>
Subject: [PIC] the result of rest


> What will general purpose registers be after rest in 16f877?
> The data sheet lists the value of lots registers after rest, but not
> mentions
> the general purpose registers.

For any registers not mentioned in the datasheet, the value after power up
will be approximately random. (i.e., not predictable but not random enough
to use as a good random number generator.)  Reset will not change the value.

--McD

____________________________________________

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