Searching \ for 'Simulate reset on 16C73A' 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=16C
Search entire site for: 'Simulate reset on 16C73A'.

Truncated match.
PICList Thread
'Simulate reset on 16C73A'
1998\12\23@082941 by Keith DERRICK

flavicon
face
How do I perform a "software reset" on one of these beasts? I've managed to jump
through the reset vector at ROM address 0, but I end up with a stack overflow 8(
Obviously, the stack needs to be reset.

Any help most urgently appreciated - either in ASM or C. I'm working in C, but
will happily put this stuff in as in-line assembler.

Keith Derrick

1998\12\23@091700 by Andy Kunz

flavicon
face
A stack overflow is no problem in the real world - the stack is circular.

In my main() I set/clear a bit flag "ResetMyself" which is controlled by
program logic or by serial port commands.  You need to have the WDT enabled.

void main (void)
       {
       // init code, etc. goes here
       ResetMyself = FALSE;

       while (TRUE)
               {
               CLRWDT ();
               // check all kinds of flags to see if things need to be done, et
c.

               if (ResetMyself)                // Null loop with no CLRWDT forc
es
                       while (TRUE)            //   reset in about 18mS
                               ;

               // Other things happen here.
               }
       }

At 01:16 PM 12/23/98 -0800, you wrote:
>How do I perform a "software reset" on one of these beasts? I've managed
to jump
>through the reset vector at ROM address 0, but I end up with a stack
overflow 8(
>Obviously, the stack needs to be reset.
>
>Any help most urgently appreciated - either in ASM or C. I'm working in C,
but
>will happily put this stuff in as in-line assembler.
>
>Keith Derrick
>
==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\23@094949 by Nuno Pedrosa

flavicon
face
Enable the Watchdog. When you want the reset, just get into a
never-ending loop, _with_no_ clrwdt, and all interrupts disabled.
This will take some time (miliseconds), depending on the settings of
your WDT, but it works.

Merry Christmas, Happy New Year, and wonderful Holidays to you all!
Ho, ho, ho! 8)

Nuno Pedrosa.

Keith DERRICK wrote:
>
> How do I perform a "software reset" on one of these beasts? I've managed to ju
mp
> through the reset vector at ROM address 0, but I end up with a stack overflow
8(
> Obviously, the stack needs to be reset.
>
> Any help most urgently appreciated - either in ASM or C. I'm working in C, but
> will happily put this stuff in as in-line assembler.
>
> Keith Derrick

--
----  ~~~~~~~  -------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  spam_OUTNuno.PedrosaTakeThisOuTspamoen.siemens.de
-  ~~~~       ~~  ----  "A crooked stick will have a crooked shadow."
=======================================================================

1998\12\23@134551 by Dwayne Reid

flavicon
face
Andy Kunz wrote:

>A stack overflow is no problem in the real world - the stack is circular.
>

Sorry Andy - the stack is NOT circular (thank god)!

The best way that I have come up with is to think of the stack as open
ended.  If you push too many items onto the stack, the excess items are
lost.  When popping the stack, all items move up one level; with the very
end of the stack keeping its current value.

This last statement is very important since it allows some very nice table
ookup routines.  Tom Napier described a very useful and extremely fast table
lookup routine in Circuit Cellar Ink that relies upon this.

dwayne


Dwayne Reid   <.....dwaynerKILLspamspam@spam@planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(403) 489-3199 voice     (403) 487-6397 fax

1998\12\23@141545 by Gerhard Fiedler

picon face
At 11:43 12/23/98 -0700, Dwayne Reid wrote:
>Andy Kunz wrote:
>>A stack overflow is no problem in the real world - the stack is circular.
>
>Sorry Andy - the stack is NOT circular (thank god)!
>
>The best way that I have come up with is to think of the stack as open
>ended.  If you push too many items onto the stack, the excess items are
>lost.  When popping the stack, all items move up one level; with the very
>end of the stack keeping its current value.

isn't that exactly what one means when saying "circular"? the way it works
looks very suspiciously like a circular stack... build one, and you'll see
that works exactly like this.

ge

1998\12\23@145149 by evan

picon face
Gerhard Fiedler wrote:
> At 11:43 12/23/98 -0700, Dwayne Reid wrote:
> >Andy Kunz wrote:
> >>A stack overflow is no problem in the real world - the stack is
> circular.
> >
> >Sorry Andy - the stack is NOT circular (thank god)!
> >
> >The best way that I have come up with is to think of the stack as open
> >ended.  If you push too many items onto the stack, the excess items are
> >lost.  When popping the stack, all items move up one level; with the very
> >end of the stack keeping its current value.
>
> isn't that exactly what one means when saying "circular"? the way it works
> looks very suspiciously like a circular stack... build one, and you'll see
> that works exactly like this.

Gerhard's right, you've just described a circular stack.  Remember that it's
not the items pushed onto the stack that go in a circle, it's the pointer to
the current item in the stack.  Even the PIC16C7x manual says "The stack
operates as a circular buffer".  See the section on "PCL and PCLATH".

-Ed V.
Agile Controls

>

1998\12\28@095601 by Andy Kunz

flavicon
face
Thanks guys!  I love not having to defend myself!

I'm curious, though - why would someone NOT want a circular stack?  It
NEVER overflows down into the heap or code space then (remember those Z80
copy-protection schemes on the TRS-80 games?!)

I sense a thread forming on nostalgic memories...

Andy


At 11:51 AM 12/23/98 -0800, you wrote:
{Quote hidden}

==================================================================
 Andy Kunz - Montana Design - http://www.users.fast.net/~montana
==================================================================

1998\12\28@132349 by Gerhard Fiedler

picon face
At 09:02 12/28/98 -0500, Andy Kunz wrote:
>I'm curious, though - why would someone NOT want a circular stack?  It
>NEVER overflows down into the heap or code space then (remember those Z80
>copy-protection schemes on the TRS-80 games?!)

a hardware stack that's not circular and gives me some kind of
exception/interrupt before it overflows is also nice.

ge

1998\12\29@132556 by John Payson

flavicon
face
> >The best way that I have come up with is to think of the stack as open
> >ended.  If you push too many items onto the stack, the excess items are
> >lost.  When popping the stack, all items move up one level; with the very
> >end of the stack keeping its current value.
>
> isn't that exactly what one means when saying "circular"? the way it works
> looks very suspiciously like a circular stack... build one, and you'll see
> that works exactly like this.

|Gerhard's right, you've just described a circular stack.  Remember that it's
|not the items pushed onto the stack that go in a circle, it's the pointer to
|the current item in the stack.  Even the PIC16C7x manual says "The stack
|operates as a circular buffer".  See the section on "PCL and PCLATH".

The 14-bit PICs use a different method of handling the stack
than the 12-bit PICs.  I don't know what the new HV'540's do
but in most cases it shouldn't matter.

On the 12-bit parts, a call results in the following sequence:
 Stack1->Stack2; PC->Stack1
and a return does this:
 Stack1->PC; Stack2->Stack1

Any time a call is performed, the value in Stack2 is lost, whether
it's meaningful or not, and any time a return is performed the
value in Stack2 gets duplicated (even though the still-in-Stack2
value is basically meaningless).  Although it would be meaningful
to talk about logical stack overflow or underflow, the hardware
has no clue about what values in Stack1 or Stack2 are actually
meaningful.

On the 14-bit PICs, the stack is an 8-word RAM combined with a 3
bit pointer.  Performing a CALL instruction will cause the PC to
be stored at the address indicated by the stack pointer and cause
the pointer to be incremented.  A return will cause the stack poi-
nter to be decremented and the indicated stack address to be load-
ed into the PC.  Note that the value in the stack RAM will remain
untouched.

In this case, assuming the pointer started at zero, the PIC could
detect an apparent "stack overflow" condition by looking for the
stack pointer to wrap around to zero.  Since it may often be use-
ful to catch such problems (rather than having them simply produce
goofy behavior) PIC emulators may stop program execution when this
occurs.  In fact, however, stack overflow is only a problem if it
later results in stack underflow (popping an address from the stack
that isn't valid).  AFAIK, no emulators make this distinction.

To properly detect stack overflow/underflow, it would be necessary
to ensure that when an address is popped from the stack, it is also
physically purged.  On the 2-level-stack PICs, assuming a call from
address 0xFFF would be odd, a simple method of stack validation
would be to load Stack2 with 0xFFF every time a return is performed.
Similarly, on the 14-bit PICs, popping a value from the stack could
be made to clear the value (so that if 8 more returns are performed
a "bogus" PC value would be observed/loaded.

Note that stack problems on a PIC can cause truly odd behaviors.
Although it's possible to write code to take advantage of the 12-
bit PICs' stack implementation (e.g. a rapid table loading trick
involving lots of RETLW's with no intervening CALLs) I would regard
such tricks as being highly apt to break.

On a somewhat different note, is the prescalar counter actually
implemented anything like Microchip's depiction, or were they just
drawing it that way for convenience?  A simpler way to design a
programmable-prescalar counter would be to use an 8-bit counter
with certain bits "jammed" set unless the appropriate bits in OPTION
are cleared.  Has anyone written cany code which relied upon a par-
ticular implementation of the prescalar (e.g. by changing prescalar
values while the counter is running?)  How does it work?

1998\12\29@140553 by Dwayne Reid

flavicon
face
I wrote:

DR>Sorry Andy - the stack is NOT circular (thank god)!

Then Gerhard Fiedler wrote:

DR>The best way that I have come up with is to think of the stack as open
DR>ended.  If you push too many items onto the stack, the excess items are
DR>lost.  When popping the stack, all items move up one level; with the very
DR>end of the stack keeping its current value.

GF>isn't that exactly what one means when saying "circular"? the way it works
GF>looks very suspiciously like a circular stack... build one, and you'll see
GF>that works exactly like this.

and Ed VanderPloeg wrote:

EV>Gerhard's right, you've just described a circular stack.  Remember that it's
EV>not the items pushed onto the stack that go in a circle, it's the pointer to
EV>the current item in the stack.


I stand corrected, I guess.  The only implementations of circular buffers
that I've seen do NOT overwrite the old values when popping - the pointers
change but the old values remain.  This is different from the pic stack
behaviour.

To me, the pic stack acts in a fashion similar to my old HP calculator's
stack which behaves as I described above.

Thanks for the explanations, guys.  I learn every more day!

dwayne


Dwayne Reid   <dwaynerspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(403) 489-3199 voice     (403) 487-6397 fax

1998\12\29@163453 by Gerhard Fiedler

picon face
At 12:03 12/29/98 -0700, Dwayne Reid wrote:
>The only implementations of circular buffers
>that I've seen do NOT overwrite the old values when popping - the pointers
>change but the old values remain.  This is different from the pic stack
>behaviour.

actually all circular implementations i know do overwrite (that's why they
are circular) -- of course not when popping, but when pushing. how about

char stack[N];
char *p = stack;

void push(char c) {
 *p++ = c; // normal push
 if (p >= stack+N) p=stack; // make it circular
}

char pop(void) {
 if (--p < stack) p=stack+N-1;
 return *p;
}

ge

1998\12\29@235507 by Dwayne Reid

flavicon
face
This stack stuff is VERY interesting!

Earlier I wrote:
DR> I stand corrected, I guess.

Now I ** really ** stand corrected!

John Payson explained all!

I was describing how I understood stack behaviour to be - stuff I've used
only with the 12c508.  Turns out what I was doing with the 12c508 won't work
with the 14 bit core parts (something I was going to try sometime over the
next couple of weeks).  And, of course, this digression started over a
discussion involving 14 bit parts.  I really was barking up the wrong tree -
sorry and thanks!

dwayne


Dwayne Reid   <.....dwaynerKILLspamspam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(403) 489-3199 voice     (403) 487-6397 fax

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