![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
scottc
Joined: 16 Aug 2010 Posts: 95
|
FAST_IO General Question |
Posted: Sat Apr 28, 2012 1:35 pm |
|
|
Hello, I am in the process of writing some code and I am curious about
the compilers fast_io option.
In the help it says I have to set the direction register which is not a problem to do for a given pin but what I am curious about is how fast
fast_io really is or if there is a benefit to using it as opposed to the compiler
default of standard IO.
I am using a PIC18F26K20 running internally at 64Mhz to sample two
AD pins and then do some very basic calculation. Would using fast_io
make much of a difference in how fast the AD converter can sample
from it's AD pin or is the limitation on sampling a AD pin really tied to
the actual speed of the AD converter itself ?
Just trying to get a handle on the benefit to using the fast_io option so
any insight would be helpful
Thanks Scott.. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Sat Apr 28, 2012 2:09 pm |
|
|
If you perform:
output_high(PIN_A0);
Then with fast_io, this generates just a single instruction, setting the output bit corresponding to PIN_A0.
With standard I/O, the compiler will clear the TRIS bit for PIN_A0, to make the pin an output, and then set the output bit. One or two extra instructions (depends on the chip). Easiest way to find out, is to try the instruction, and look at the list file in each mode.
Generally, disadvantage of fast_io, is that _you_ then become responsible for remembering to set the TRIS, and in particular for the chip variations that apply, in particular for peripherals (for example on some chips you need to set UART pins as inputs, while on others they need to be set for the data directions involved). Downside of standard I/O, is the extra instruction(s) to handle TRIS, and it can be a problem where (for instance), you want to use the interrupt on change on PortB, and clear this by reading the whole port (one instruction, rather than accessing the individual bits), but want to also use some pins as outputs (and don't therefore want the compiler to set the whole port as input on the read...). Here taking 'manual control' with fast_io is the way to go.
Realistically standard_io, is quicker to code, and less likely to have problems, but fast_io, is quicker in use, and gives you full control.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Sat Apr 28, 2012 10:15 pm |
|
|
Thanks for the good explanation Ttelmah.
I think for the most part fast_io is better from the perspective that you
will save an instruction or two. I also like the idea of manual control.
By way of a similar question, is Fixed_IO the same as Fast_IO with Tris ?
In other words would
#USE FAST_IO(B)
set_tris_b(0b00001100);
be the same as
#use fixed_io(B_outputs=PIN_b0, PIN_b1 etc )
I think setting the direction register is an easier read to be honest as in
the Tris command, and since most hardware pinning will be decided early
on in a design manually setting the IO seems more intuitive to me...
Thanks Scott |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Sun Apr 29, 2012 1:35 am |
|
|
No.
With fixed_io, the compiler still sets the TRIS for every I/O operation. However it sets it to the value you specify, rather than the one the instruction implies. So (for instance), if you set up fixed_io, with PIN_A0 as an output, then performed x=input(PIN_A0), the compiler would program A0 as an output, then return the bit read from this....
Seriously, years ago, I'd have always used fast_io, since the compiler so often got it wrong. However I'd now use standard_io, _unless_ I was doing something special. The speed difference is negligible, and in fact updating the TRIS for every operation can avoid some PIC glitches.
Far more code here goes 'wrong', because people use fast_io, and then get a bit incorrect in the settings, than goes wrong because of the extra time, or the compiler getting it wrong now...
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Sun Apr 29, 2012 12:28 pm |
|
|
Ah I see, Thanks for the heads up..
Best Regards Scott |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Sun Apr 29, 2012 2:28 pm |
|
|
Quote: |
disadvantage of fast_io, is that _you_ then become responsible for remembering to set the TRIS,
|
I firmly believe that fast_io is advantageous,
in that it requires programmers to pay full attention to the code they write.
I feel lucky, in that early on in my CCS use, the time overhead of auto_tris bit me in the a**, badly.
So as soon as I realized HOW, ever after, the initialization for each program I wrote, specified ALL the TRIS. Even for bi-directional i/o...
I've never looked back or gotten lazy enough to consider NOT using fast_io.
just my 2 cents |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|