Searching \ for '16C77 INDF possible bug.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=16C
Search entire site for: '16C77 INDF possible bug.'.

Truncated match.
PICList Thread
'16C77 INDF possible bug.'
1998\03\04@121047 by Ray Gardiner

flavicon
face
We are about to start migrating a 16c74 app to 16c77, and have
been warned of  a possible bug in the INDF addressing when
accessing page 3 ram.

Sorry no additional info at this time, anyone else having
problems with 16C77 and INDF addressing?




Ray Gardiner (DSP Systems) spam_OUTrayTakeThisOuTspamdsp-systems.com http://www.dsp-systems.com
private email to:- .....rayKILLspamspam@spam@netspace.net.au

1998\03\04@211536 by David Brobst

flavicon
face
Ray:


>We are about to start migrating a 16c74 app to 16c77, and have
>been warned of  a possible bug in the INDF addressing when
>accessing page 3 ram.
>
>Sorry no additional info at this time, anyone else having
>problems with 16C77 and INDF addressing?


We used the '77 in a project and actually had a 40 byte buffer locatated on
page 3 of RAM, so we made extensive use of indirect addressing on page 3.
We never ran into any problems.  There are only 2 minor bugaboos, however
they are detailed in the data book, so there shouldn't be a problem.  They
are reiterated below for convenience-sake.

1)  The STATUS register contains a bit (called IRP) which sets the indirect
addressing to page 0-1 RAM OR page 2-3.  It is STATUS,7.  When clear (0) it
sets the indirect addressing to page 0-1 RAM, while setting it (1) sets the
indirect addressing to page 2-3 RAM.  A benefit (the drawbacks are obvious)
to this scheme is moving data from one buffer to another on another page in
RAM can be accomplished elegantly with only a BSF/BCF instruction, assuming
the buffers are mapped with due-consideration.

2)  The last 16 bytes of RAM on pages 1, 2, and 3 map to page 0 of RAM,
regardless of the state of the RPx bits or IRP bit in STATUS.  As such there
are 48 fewer bytes of user accessible RAM available than would appear by
looking at the addressing scheme.  A benefit of this (again the drawbacks
are self-evident) is declaring "global" variables which can be modified
regardless of what page of RAM the program is working with at the time.
This is useful for flags and the like.

Good luck with your project,

David Brobst
General Partner, Solutions Cubed

1998\03\05@114806 by Ray Gardiner

flavicon
face
<snip>
>
>We used the '77 in a project and actually had a 40 byte buffer locatated on
>page 3 of RAM, so we made extensive use of indirect addressing on page 3.
>We never ran into any problems.  There are only 2 minor bugaboos, however
>they are detailed in the data book, so there shouldn't be a problem.  They
>are reiterated below for convenience-sake.
>
<snip>
>David Brobst
>General Partner, Solutions Cubed

Hi David,

Thanks for the confirmation, Some details haven't yet
been clarified, but generally the problem manifests itself in
the following way. When IRP bit is set for INDF access to page 3
BUT the RP1 bit is set for page0. Everything appears fine
UNTIL you perform some operation which updates the status reg.
Like something which updates Z. Then everything falls over.

The answer (I think) is simply to ensure the RP1 bit and
the IRP bit always track each other when using INDF addressing.
RP0 is of course irrelevant since the FSR is 8 bits.

I should be able to confirm  that this was the cause within the
next few days.


Ray Gardiner (DSP Systems) rayspamKILLspamdsp-systems.com http://www.dsp-systems.com
private email to:- .....rayKILLspamspam.....netspace.net.au

1998\03\07@115532 by Tom Handley

picon face
  Ray (and David), thanks for posting this. I'm also moving a project
from the 16C74A to the 16C77. My intent was to set IRP and then the RP0/1
bits for a given page. I have'nt got that far yet. Currently I'm busy with
moving code to banks 2 and 3 and adjusting registers for the upper 16 Bytes
that are aliased between the banks. The first things to go are the registers
that are saved in my ISR routine. Since I use all of the bank 0 registers
and most of bank 1, I'm tempted to do a complete re-write of the code for the
'77... I would like to implement data buffers for a variety of sensor inputs
in banks 2 and 3. Currently, my ISR and state machine responds to many events
on a per-Byte basis. Please keep us informed. Thanks,

  - Tom

At 03:09 AM 3/6/98 +1000, you wrote:
{Quote hidden}

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