I may have worded it somewhat incorrectly, but the basic idea
 is valid. In the original 12 bit core, the DDR (TRIS)
 register was NOT in the memory map where the user could get to
 it. But later versions (14 & 16 Bit) of the core put this
 register where it is readable and writable just like the
 STATUS register or the PORT register, etc., etc., etc.

 And, Yes, as far as I know, this instruction has not been
 removed from either the PIC or the assembler.  I know Microchip
 has reserved the right to remove this instruction in the future
 at their discreion.  When they will exercise this right, who
 knows.

 If I mislead or confused you, please forgive me.  This is the
 way I interpreted the material in the data books years ago.


                                         Regards,

                                           Jim..





>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.
>