tris vs FIXED_IO

[GiG]

Hello
The question that occupied my mind and I did not get a very strong answer after reading the data sheet is what exactly does this command do?
FIXED_IO
If I want to define a pin output i say FIXED_IO( B_outputs=PIN_B1,PIN_B0 )
how about tris function what is
So,What does TRIS order do? if we use them
thankyou

[Ttelmah]

I/O modes:

Fast_io

Here the compiler does nothing. You have to set the TRIS to the correct
value for the port, before doing I/O.

Standard_io

Here the compiler will automatically generate a TRIS for every I/O
statement. If you perform an input on a pin, this pin will be set to be
an input pin and then the value will be read from it. Perform an output, and
a TRIs will be generated to set the pin as an output, and then the output
will be done. The compiler will also automatically set the TRIS for all
peripheral I/O as well.

Fixed_io

Here a tris will be generated for every I/O statement, but instead of the
value being automatic, the value will be what is defined in the fixed_io
statement. No automation at all.
Downsides still has the time cost of standard_io.
Also no automation so is dependant on you setting the pins correctly.
Advantage though is it can allow you to override the automation.

So (for example), imagine you want to use the interrupt on change on
PortB 4 to 7, but also want to perform an output on B0 to B3. For simplicity
you want to do a byte wide read in the interrupt handler.

[temtronic]

In 2.5 decades of using PICs and the CCS compiler, I've only needed to use fast_io(), 2 or 3 times. Every time it was 'time sensitive' custom, proprietary interfacing with special clients products.
With today's fast PICs, the few extra lines of code needed for 'standard_io()', doesn't really matter.

The big downside of using fast_io(), is when you reconfigure the I/O pins for say a better PCB layout or needing an internal peripheral, and YOU forget to change ALL of your code. Then, what used to work, kinda doesn't, and nothing seems obvious. Using standard_io() eliminates that headache !

[newguy]

I honestly don't understand the bias against using fast_io. I think perhaps the first 2 or 3 projects I did when I was learning PICs and the CCS compiler, I used the default - standard_io. When I learned that I had been overlooking the tris but the compiler 'had my back', I switched to fast_io and haven't looked back.

My time is valuable and I can't afford to trust that the compiler's author did things right, but later learn that they didn't. I take control of the tris myself; this way I know that things are set correctly. In ~20 years I haven't once left the tris as something for the compiler to look after for me.

[temtronic]

I have no bias either way, heck in the good ol' dayze you HAD to control ALL the bits of all the bytes when you programmed in machine code.
We used to have to 'toggle in' loaders for paper tape....

[Ttelmah]

The 'bias' is very simple.
We see so many programs posted here where people have leapt in and
used fast_io, and it does not work because their TRIS settings are wrong.
Seriously I have not seen a single program using standard_io, in probably
at least the last five years, where the compiler gets the TRIS wrong.

[newguy]

I have to admit I'm biased because it's very common for me to employ a design that requires a bidirectional pin in a port where I'm also setting pins to be permanently in or permanently out. I handle the pin directions while also doing a port-wide read or write.

[GiG]

so as you say if i use this command
#use FIXED_IO( A_outputs=PIN_A7,PIN_A6,PIN_A5,PIN_A4 )
No need to use TRIS anymore!?

[Ttelmah]

If that is the I/O pattern you want.