View previous topic :: View next topic |
Author |
Message |
GiG
Joined: 03 Sep 2021 Posts: 39
|
tris vs FIXED_IO |
Posted: Wed Dec 15, 2021 6:44 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Dec 15, 2021 7:26 am |
|
|
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.
Code: |
#use fixed_io(b_outputs=PIN_B0, PIN_B1, PIN_B2, PIN_B3)
//Now B0 to B3 are fixed as output pins
//This effectively sets TRIS to 0b11110000
static int last=0xF0;
#int_RB
void B_changed(void)
{
int temp;
//now we come here is any of RB4 to 7 changes from it's last read
//value
temp=input_b();
//this now reads the whole of PORTB, but only RB4 to RB7 are set
//as inputs.
//So now can compare bits in 'last' to 'temp' and find what bit has
//triggered.
last=temp; //store for next time
}
void main(void)
{
//at the start, load 'last' before enabling the interrupt
last=input_b();
enable_interrupts(INT_RB);
enable_interrupts(GLOBAL);
//now other code
}
|
Generally you should only ever need to use TRIS, when using fast_io.
For both fixed_io, and standard_io, the compiler automatically adds a
TRIS command to every I/O statement. With standard_io, it tries to
do it to support the command you are giving. For any compiler in the
last ten years or so, it honestly is more likely to get it right than you are.
For 99% of code, just use standard_io, and let the compiler handle TRIS. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Wed Dec 15, 2021 7:40 am |
|
|
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 ! |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Wed Dec 15, 2021 9:20 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Wed Dec 15, 2021 9:30 am |
|
|
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.... ![Very Happy](images/smiles/icon_biggrin.gif) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Wed Dec 15, 2021 12:13 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Wed Dec 15, 2021 12:54 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
GiG
Joined: 03 Sep 2021 Posts: 39
|
|
Posted: Thu Dec 16, 2021 4:17 am |
|
|
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!? |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Dec 16, 2021 4:20 am |
|
|
If that is the I/O pattern you want. |
|
![](templates/subSilver/images/spacer.gif) |
|