James Paul wrote:

> In the low end (ie 12 bit) core, the Data Direction Registers
> were not user accessable.  The TRIS instruction was implemented to
> allow writing (indirectly) to these registers.

  Hmmm.  You put the value in W, and you effectively implement a single
MOVWF instruction.  How much more direct can you get?  Is it *more*
direct to set RP0 first?

>  In later versions they are available directly, so therefore,
> there is no need for the TRIS instruction as you can now write
> directly to the register.

  Sorry, you can't!  You have to set RP0 first!  And clear it afterward.

> It has been left in this long so users could port their designs to the
> 14 bit core, and still have it available until they rewrote the
> firmware to take advantage of the directly addressable DDR.
> Hope this explains it for you.

  I think you've got that backwards!  With a zeal more appropriate to
marketing than engineering, and oblivious to the needs of users, some
funny little person in Microchip is promoting this Newspeak.

  The TRIS instruction has not been "removed" from any PICs so far (has
it?) and for good reason - it is the fastest and most *reliable* way to
manipulate the TRISx or DDx register.  Neither has it been removed from
the assembler which has been set to *assemble* the TRIS instruction, but
"Warn" against it.  How bizarre!

  Obviously, someone in development decided it would be a Nice Idea to
have the TRISx register readable as well as writeable, and so it Was
Done.

  Problem is - they botched it!  Yes!  Tris was relegated to the
"Sleeping" register bank instead of the "Working" one, along with OPTION
and the EECONs.  It was somehow imagined that TRISx was "set and
forget", which in fact is little different to the original concept of
the TRIS *instruction*.

  But of course, the TRISx function is really much more useful than that
and is frequently used to implement "open-drain" communication, notably
IÓC (master) protocol.  So you have two options, fiddle with the TRISx
register, furiously setting and clearing RP0 all the while, or set up
the values you need in W, and TRIS PORTx.

  Now the perils of performing BSF and BCF instructions on the PORT
registers are commonly discussed.  The TRIS register shouldn't be
affected by glitches, but there seems to be a fair suspicion that it
might, so there is a lot to be said for controlling it with literal
masks or "shadowing", and these are far more easily implemented using
the TRIS instruction.

  Of course, if you use a good "C" compiler, it pops in the RP0 set and
clear instructions all by itself, so you don't have to worry about that.

  Don't believe everything you read.  Certainly not me!
-- 
  Cheers,
        Paul B.