'Why is Microchip removing the TRIS and OPTION comm'
I know they perhaps encourage unstructured programming, since you do not
have to access Bank1, but is it really necessary?
|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
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?
> 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 Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...