Dwayne Reid wrote:
> Its actually fairly common coding practice when working with the
> 14-bit core to treat the TRIS bits as if they were in the same
> location as the port bits - but in a different bank.

Common is no proof of good.  There are many idiots out there.

> This is, of course, exactly the case.  They **ARE** in the same
> bit and register locations - just in different banks.

Really?  Have you ever seen a statement from Microchip that this is a rule
they intend to continue following?  I haven't.  As far as I know, all we
have is a bunch of cases where this happens to be true.  Without a stated
rule, these are merely coincidences, and it would be bad programming to
extrapolate them further.

> Recognizing this allows for some really neat code optimization,
> particularly when you are writing your code to be somewhat port or
> bit independent.  I2C routines are the first thing that comes to
> mind, but there are many others.

But that wasn't what was going on here.  There was no optimization or
advantage derived from the TRIS and PORT registers being at the same offset
in different banks.  The code was accessing the TRIS register while using
the name of the PORT register, which only happened to work on a PIC 16 due
to a coincidence of SFR layout.  There would have been nothing lost by
referencing the TRIS register directly by name, and of course a great deal
of clarity and robustness gained.

> I've seen much code written this way and I use this technique all the
> time when writing my own code.

Again, no proof of anything.

> It works, its efficient, its
> readable, its maintainable.  What more do you want?

Something that works by more than just coincidence, and actually IS readabl=
e
and maintainable.

In rare cases you can save a cycle or two by knowing that the PORT and TRIS
registers are at the same offset in different banks **on that machine**.
Most of the time that cycle or two is of no consequence, and code
readability and maintainability is far more important.

In those cases where the cycles do matter, there are proper ways to exploit
the coincendence.  First there should be a clear comment explaining what yo=
u
are doing and why, so that anyone reading the code understands the SFR
layout quirk you are exploiting.  Second, you should verify the quirk at
assembly time.  If your code relies on PORTB and TRISB being at the same
bank offset, then test that and throw a assembly error if it is found not t=
o
be true.  PORTB and TRISB are both fixed constants defined in the processor
include file.  All you have to do is check at assembly time that their low =
7
bits are equal:

  if (portb ^ trisb) & h'7F'
        error  ....
    endif

Now you can safely exploit the quirk, with proper comments of course.

> Yeah - it doesn't fit the Olin development model.  That does NOT make
> it " *really* bad programming ".

You forget that this code actually did fail, and for precisely the reason
caused by the irresponsible programming.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.