Searching \ for 'Why is Microchip removing the TRIS and OPTION comm' 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=microchip
Search entire site for: 'Why is Microchip removing the TRIS and OPTION comm'.

Truncated match.
PICList Thread
'Why is Microchip removing the TRIS and OPTION comm'
1998\11\23@051637 by Myers-R-96

flavicon
face
I know they perhaps encourage unstructured programming, since you do not
have to access Bank1, but is it really necessary?

1998\11\24@125024 by John Payson

flavicon
face
|I know they perhaps encourage unstructured programming, since you do not
|have to access Bank1, but is it really necessary?

The "tris" and "option" instructions were implemented as something
of a kludge on the 16C54 since it was necessary to conserve address
space.  The engineers who suggested that they may be obsoleted were
probably hoping that in future architectures such a kludge would no
longer be necessary and--since the instructions are in most cases no
longer really needed(*) on the 16Cxx processors, they suggest that
they no longer be used.

(*) The "option" and, especially, "tris" instructions are often faster
   than the bank-switching sequence needed to access the OPTION or
   TRISx registers directly.  There are times when this speed is needed
   though it usually isn't.

Personally, I disagree with this suggestion on the part of Microchip.
I suspect code portability to future CPU designs (e.g. 18Cxx) will be
better in programs that use TRIS/OPTION than in those which use bank
switching.  After all, TRIS or OPTION may be replaced with macros if
needed, but it's hard to translate bank switching instructions which may
or may not be needed in future architectures.

Personally, my hope is that (TRIS X) will be able to expand to a nice
simple macro like (MOVWF X+8) [i.e. that in the new architecture the PORT
and TRIS registers are both in the main bank].  We'll have to see if that
comes to pass.

Otherwise, I've found the banking of stuff on the PIC to be a nuisance
but usually not too bad--with one recent exception (which I've still not
managed to resolve well):

 I'd like to use two interrupt sources (timer 2 and the PSP) and allow
 the PSP interrupts to nest within the timer 2 interrupts.  Normally,
 nesting interrupts on a PIC isn't a problem (just make sure to use two
 sets of registers for context saving).  But there's one problem I've not
 figured out how to get around (I'm using a 16C74A, but I'd like to stay
 compatible with the 16C77):

   How can I detect the interrupt source, and branch to the right
   interrupt routine?

 Unfortunately, it seems that I need to save W. Status, and PCLATH and
 switch to bank 1/code page 0 before I can tell where an interrupt came
 from, and if it came from the timer I need to copy the saved W, status,
 and PCLATH to a different spot before re-enabling interrupts.  Since the
 timer 2 interrupt will occur pretty frequently, is there any way to
 avoid all this hassle?

1998\11\24@144945 by Andy Kunz

flavicon
face
>  timer 2 interrupt will occur pretty frequently, is there any way to
>  avoid all this hassle?

Don't use the interrupt.  Poll T2IF instead in software.  Leave T2IE=0.

Andy


==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

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