#USE fast_IO (B)

[kamillas]

I want to know the meaning of : #USE fast_IO (B)

[asmallri]

[temtronic]

As long as you're 100% sure your code handles the pin I/O directions of all the ports that you've used fast_IO, you'll be OK, BUT and it's a big one !, If you miscode a pin for input when it should be an output(say during the 4th revision..late at night) or swap pins because it lays outbetter on the pcb, you'll cause yourself a LOT of loss time, hair pulling, cursing'it worked before !!'.

Let the compiler handle the data direction registers at least until the final version of the program.It's just one less thing to deal with and while using fast_IO will result in slighly faster program execution and smaller code space, you may not actually benefit from it.

[RF_Developer]

In the past all embedded programming had to use the equivalent of fast io. Programmers had to set the IO direction of all IO ports. Assemblers didn't do it for you, and there were few compilers and they didn't do it for you either.

However there are problems. fast IO requires the programmer to keep track of which IO bits are inputs and which are outputs. This rapidly gets more difficult as code becomes more complex. Its especially tricky when you are using IO drivers that you haven't written and don't have control over. Even getting a small programming team to consistently and compatibly control IO directions can be a challenge. So that even modestly complex code can cause headaches. For instance do you set all IO directions at one place at the start of the main code - "safer" perhaps but limiting - or do you let sections of code set them as they need, say in device specific initialisation code? That's more complex and can lead to confusion - probably best avoided except for well disciplined teams with well thought out programming definitions.

Extra complications come with using the hardware peripherals, as its possible to make them not work by careless use of IO directions/TRIS.

The "normal" CCS IO method does all this for you. It sets the IO directions as required and keeps track of hardware peripheral ports for you.

On the other hand fast IO/setting IO direction yourself makes it simpler to use open source/collector type outputs.

Fast IO is not much faster, and in most applications is not necessary. Its speed advantage is only valuable in specific and rare circumstances. I have only used it once, and that was in a control loop application where I wanted the fastest response I could get. In the end it was limited by ADC speed, and further improvements in IO speed increase had no effect.

Setting IO direction is done on PICs on a port by port basis, not bit by bit. This means setting bit patterns which can cause confusion.

Personally I am glad to be able to offload the complication of setting IO direction to the CCS compiler. It is rather better at it than I am. Others see it differently.

RF Developer

[asmallri]

One other consideration is the lack of portability introduced by letting the CCS compiler automatically set the I/O direction. Direct manipulation of a port, typically used by the manufactures compilers and by any one programming in assembler, such as LATBbits.LATB3 = 1, would fail using the CCS compiler unless the programmer or integrator knew to change from the default to #USE FAST_IO(B).

If code from Microchip was to be integrated into CCS code, for example a developer wants to integrate some or all of the one or more library stacks, then the developer would either have to replace all of the above type statements with the CCS equivalent OR they would have to change the rest of the CCS application such that any code that used the peripheral pins used on PORT B (in this example) would have to be modified.

The simplest solution is to use FAST_IO maintaining compatibility between the CCS and Microchip C compilers and assembler.

Letting the compiler do it automatically promotes poor programming style (laziness).
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[temtronic]

I don't consider letting the compiler automatically control the DDRs 'lazy'.
It's a good way(probably the best) for new and young 'programmers' to get their code up and running with minimal headaches.

Andrew , do you consider it 'lazy' to use the builtin functions like use RS232 and I2C or PRINTF ?

A 'real' programmer would cut his own code,all of it,in assembler of course! Heck, I remember having to manually toggle in bootloaders into PDP-8s to get the papertape reader to read in the 'real' program...Time's have changed and in order to get product out the door , you have to 'work smarter, not harder'

I don't see many requirements to port code from one compiler to another these days.The Net has allowed finding what you need in your language an easy task, so cross-compilers are dinosaurs, same as us 'assembler' programmers.

The compiler is a tool, with options.It's like a claw hammer that can pound nails in or take them out, you can choose how you use it.

[dyeatman]

Wow, I am impressed there is someone else still out there with PDP-8
experience! I worked on PDPs with 64K of core memory and a
Hazeltine terminal. Toggled in the bootloader to load paper tape from
the ASR33, then used that to boot the dual cassette magtape reader..
Since there was nothing commercially available, we built all our
interfaces from scratch on Augat wirewrap boards. All this advanced,
cutting edge technology had a price tag of $50,000 dollars! Sorry for
the trip down memory lane, but I hadn't seen a mention of DEC
equipment in many years!
_________________
Google and Forum Search are some of your best tools!!!!

[asmallri]

[SherpaDoug]

I vote with temtronic to let the compiler do all the mind numbing menial tasks it can, and reserve my (limited) brainpower for higher level thinking.

A competent CCS PIC C programmer should know that the compiler is handling the TRIS registers and when he needs to do it himself. He should also be able to figure out small pieces of PIC assembler code when he has to. But both manually setting TRIS registers and dealing with assembly should be exceptions, not the rule. Using C compilers and all their features make us efficient, not lazy.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[asmboy]

My design work tends to flow from the HARDWARE back to the PIC.

That makes it pretty simple to define the TRIS states i need for fast_io.

It is very seldom that i need to do bidirectional IO on a given port or pin - but when i do - i have no problem with switching tris.


The KIND of instruments i work on tend to require very fast I/O ( reading
750 k sample/sec parallel output 16 bit A?D converters comes to mind) and with a minimum of wasted time.

As far as allowing the compiler to set tris ?

Based on my own experience of how trusted things in one compiler version get trashed in another - its not laziness or lack thereof.
I comes down to not trusting what i did not specify.

In the latest version - even SIMPLE helpful things can get changed - like fuse parameters being altered in device files for some older chips -
or suddenly needing to call the command line compiler with .C in the explicit file name.
SO why should i trust the compiler when i don't have to ?


and