Searching \ for 'RAM lost ?' 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/index.htm?key=ram+lost
Search entire site for: 'RAM lost ?'.

Truncated match.
PICList Thread
'RAM lost ?'
1997\12\25@184142 by senna

flavicon
face
Hi PIC_World !

Is someone know if then 12c50x or 16c84 have problemes with internal RAM
on Power On Reset ?

What happen if i try to read an address not previously initialized ?

Is RAM locations are lost on a wake-up from sleep ?

After a MCLR, is RAM cleared ?

Thanks ! And best wishes .

1997\12\26@131622 by Mike Keitz

picon face
On Fri, 26 Dec 1997 00:37:50 +0100 ZyLog <spam_OUTsennaTakeThisOuTspamworldnet.fr> writes:
>Hi PIC_World !
>
>Is someone know if then 12c50x or 16c84 have problemes with internal
>RAM
>on Power On Reset ?
>
>What happen if i try to read an address not previously initialized ?

After power has been off, the RAM will start up holding "random" values.
As long as the Vdd voltage is kept above 1.5V, nothing other than writes
by software is supposed to change the RAM.  I haven't tried much of this
to see if there's a "problem".

It's good practice to assume that the contents of RAM could change at any
time from a "glitch" and write the program to minimize the damage if this
happens.  For example, say you need to output a shifting 1 bit to a port
to scan a keyboard or display.  So you keep a RAM variable of the last
value output.  A routine is needed to shift the 1 one position to the
left, rolling it over to bit 0 when it reaches the end.

This routine is compact, but unreliable in case of RAM disruption:
       clrc                    ;Shift in a 0.
       rlf     scanbit,f       ;Do the shift.
       skpnc                   ;Skip if 1 didn't come out.
       rlf     scanbit,f       ;If 1 came out, put it to bit 0.

If the RAM location 'scanbit' contains a value other than one of the form
having a single 1 and 7 zeros, it won't work.  Now consider this routine:

       clrc                    ;Shift in a 0
       rlf     scanbit,f       ;Rotate it in.
       movf    scanbit,f       ;Test if new value is 0
       skpnz                   ;It's not, shifted value OK.
       bsf     scanbit,0       ;Reset scan to first bit.

This routine will "count out of" a bad value in scanbit within 8 shifts.
So some of the scans after a RAM glitch are bad, but the PIC doesn't
continue indefinitely with faulty data like it would with the first
routine.


>Is RAM locations are lost on a wake-up from sleep ?
>After a MCLR, is RAM cleared ?

Sleep mode, MCLR or watchdog resets do not affect it.  MCLR resets many
of the special registers, but not the data RAM.

1997\12\27@122245 by John Payson

picon face
> This routine is compact, but unreliable in case of RAM disruption:
>         clrc                    ;Shift in a 0.
>         rlf     scanbit,f       ;Do the shift.
>         skpnc                   ;Skip if 1 didn't come out.
>         rlf     scanbit,f       ;If 1 came out, put it to bit 0.
>
> If the RAM location 'scanbit' contains a value other than one of the form
> having a single 1 and 7 zeros, it won't work.

The point about self-stabilizing vs non-self-stabilizing code is an important
one (if a glitch that may occur once every few days disrupts operation for
a few seconds that's often not as bad as one that disrupts operation indef-
initely).

>                                                Now consider this routine:
>
>         clrc                    ;Shift in a 0
>         rlf     scanbit,f       ;Rotate it in.
>         movf    scanbit,f       ;Test if new value is 0
>         skpnz                   ;It's not, shifted value OK.
>         bsf     scanbit,0       ;Reset scan to first bit.

If it's okay (or desirable) to have the result in W as well as F, it can be
done safely in 4 cycles:

       movlw   1
       btfss   scanbit,7
        rlf    scanbit,w
       movwf   scanbit

1997\12\27@133508 by Dmitry Kiryashov

flavicon
face
John Payson wrote:

>
> If it's okay (or desirable) to have the result in W as well as F, it can be
> done safely in 4 cycles:
>
>         movlw   1
>         btfss   scanbit,7
>          rlf    scanbit,w
>         movwf   scanbit

Another variant.

       movfw   scanbit
       addwf   scanbit,f
       skpnz
       bsf     scanbit,0

After this W contain previous scan and scanbit contain next scan.

WBR Dmitry.

1997\12\28@103612 by John Payson

picon face
> > If it's okay (or desirable) to have the result in W as well as F, it can be
> > done safely in 4 cycles:
> >
> >         movlw   1
> >         btfss   scanbit,7
> >          rlf    scanbit,w
> >         movwf   scanbit
>
> Another variant.
>
>         movfw   scanbit
>         addwf   scanbit,f
>         skpnz
>         bsf     scanbit,0
>
> After this W contain previous scan and scanbit contain next scan.

Hmm... this has the same problem that the first four-cycler given before
had: if scanbit holds something other than a power of two, running the
routine repeatedly won't fix that.  On the other hand, looking at mine
above it's just plain broken.  Sigh.  Maybe too much egg nog.

1997\12\28@154540 by Mike Keitz

picon face
On Sun, 28 Dec 1997 09:24:30 -0600 John Payson <.....supercatKILLspamspam@spam@MCS.NET> writes:

>> Another variant.
>>
>>         movfw   scanbit
>>         addwf   scanbit,f
>>         skpnz
>>         bsf     scanbit,0
>>
>Hmm... this has the same problem that the first four-cycler given
>before
>had: if scanbit holds something other than a power of two, running the
>routine repeatedly won't fix that.

This version should work.  Adding a number to itself is exactly the same
as shifting it left 1 bit and putting a 0 into the LSB (The AVR's 'shift
left' instruction is actually an add to itself, though shifting to the
right is apparently done with a dedicated unit.).  After 8 or fewer such
operations, any initial value is certain to become 0, at which time the
BSF is executed to reset the value to 00000001.

Note this will not work with a RLF instruction because RLF doesn't affect
the Z flag (as well as requiring the proper initial value in C).

A somewhat faster recovery may be possible by additionally testing for
the first 1 bit to come out:

       movfw   scanbit
       addwf   scanbit,f       ;Shift 'scanbit' left 1.
       skpnc
       clrf    scanbit         ;Immediately go to 0 if 1 came
out.
       skpnz                   ;If result 00000000,
       bsf     scanbit,0       ; restart to 00000001

The C test can't be used alone because then it won't detect if the value
was 0 at first.  The BSF always executes if the CLRF did because CLRF
always sets the Z bit.

I think the worst-case recovery for this routine is if scanbit is
00000011, in which case 7 iterations would be required to get a valid
value.  So the extra 2 instructions aren't worth that much.

What's the best way to guarantee a valid output with only one execution
of the update routine?  Maybe changing the whole approach to use a
counter that counts from 0 to 7, then generating ths scan mask from it
(Most likely any real application will require both a count and a mask
anyway).  The counter can be guaranteed valid just by ANDing it with 7.

Or some method that finds the first '1' bit in the result and sets the
other 7 bits all to 0?

It appears that XORing n with n-1 produces a result having zeros on the
left and at least 1 one on the right.  The position of the rightmost 0 in
the result is one left of the position of the rightmost 1 in n.

Now take these results (r) and convert them to a form having one 1 and 7
zeros with z = (((r << 1)+1) ^ r).  The special case of r = 11111111
(actually can test 1XXXXXXX since we know all the LSBs will be 1 anyway)
needs to generate z = 00000001.

   n        n-1         r         z
00001100, 00001011 -> 00000111 -> 00001000
00001101, 00001100 -> 00000001 -> 00000010
00000000, 11111111 -> 11111111 -> 00000001 *
11111111, 11111110 -> 00000001 -> 00000010
00010000, 00001111 -> 00011111 -> 00100000
10000000, 01111111 -> 11111111 -> 00000001 *
10001000, 10000111 -> 00001111 -> 00010000
etc.

Writing this in PIC code:
       decf    scanbit,w
       xorwf   scanbit,w       ;W = r.
       movwf   tmp             ;Prepare to compute z.
       rlf     tmp,f
       bsf     tmp,0           ;tmp = r<<1 + 1
       xorwf   tmp,w           ;W = z (exc. special case)
       skpnz                   ;z is OK.
       movlw   1               ;Special case resulting if r = 0xFF
       movwf   scanbit         ;New scan mask, guaranteed
legal.

Obscure? Yes.  Useful?  Maybe.  Functional?  Not sure.

1997\12\28@173651 by Dmitry Kiryashov

flavicon
face
Hello John.

> > Another variant.
> >
> >         movfw   scanbit
> >         addwf   scanbit,f
> >         skpnz
> >         bsf     scanbit,0
> >
> > After this W contain previous scan and scanbit contain next scan.
>
> Hmm... this has the same problem that the first four-cycler given before
> had: if scanbit holds something other than a power of two, running the
> routine repeatedly won't fix that.  On the other hand, looking at mine
> above it's just plain broken.  Sigh.  Maybe too much egg nog.

Put any value to scanbit and excute my code up to 8 times.
I think you will see recovering :-)

WBR Dmitry.

1997\12\28@185956 by Dmitry Kiryashov

flavicon
face
Hello Mike.

> What's the best way to guarantee a valid output with only one execution
> of the update routine?  Maybe changing the whole approach to use a
> counter that counts from 0 to 7, then generating ths scan mask from it
> (Most likely any real application will require both a count and a mask
> anyway).  The counter can be guaranteed valid just by ANDing it with 7.


How about following example:

;       get a lowest "1" bit in a byte

       movfw   scanbit
       sublw   0
       andwf   scanbit,f
       skpnz                   ;if _Z=1 than _C=1 too (see sublw)
       bsf     scanbit,_N      ;if _Z=1 than init scanbit with 1<<_N
                               ;where _N is desirable position

;       calc. next scan_value

       rlf     scanbit,w
       rlf     scanbit,f
;

WBR Dmitry.

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