CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

HowTo define a pin to be digital input pin?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
djole_nisam_ja



Joined: 10 Dec 2009
Posts: 18

View user's profile Send private message

HowTo define a pin to be digital input pin?
PostPosted: Fri Mar 19, 2010 3:54 am     Reply with quote

I need help with defining pin as digital input pin.

I know how to define it as digital output:
Code:

set_tris_a(0);   // PORTA defined as output */
output_a(0);    // PORTA = 0; set to logical '0' */

output_high(PIN_A0); // PIN_A0 = 1 */

I also found that I can use:
Code:
 
input(PIN_B0); // to check the condition of PIN_B0 */

Is this right and what else I need to use before using input(PIN_B0)?

Thanks in advance
bungee-



Joined: 27 Jun 2007
Posts: 206

View user's profile Send private message

PostPosted: Fri Mar 19, 2010 5:10 am     Reply with quote

You do not need to to use tris commands with CCS, because CCS will do that for you.

If you use pin as output than you use command output_bit(Pin_a2), if you need digital input, you'll read it with input(Pin_a2).

If you need to read ADC... then read_adc() will do the trick, but in this case you need to setup adc correctly at first.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Mar 19, 2010 5:25 am     Reply with quote

On the PIC, there are two registers asssociated with each pin (slight simplification, on some there are really three), The TRIS register, which controls the I/O direction, and the actual data register, which you can read/write.
Now, in assembler, to read a pin, you would have to set the corresponding TRIS bit to '1', making the pin an input, and then read the input register.
In CCS, by default, the compiler _automatically does this for you_.

So, in your first part:
Code:

set_tris_a(0);   // PORTA defined as output */
output_a(0);    // PORTA = 0; set to logical '0' */
//Port A, is _automatically_ set to output for you.

output_high(PIN_A0); // PIN_A0 = 1 */

You don't actually need the first TRIS line. The compiler sees that you are outputting data, so automatically changes TRIS to set the port as an output. If you look at the assembler code generated, you will actually find that TRIS is being set to 0 twice...

input(PIN_B0);

Here, the compiler sees that you want to read pin A0, so changes the TRIS to:

0b00000001

automatically.

Now, if you want to control TRIS yurself, the command:

#use fast_io(a)

will tell the compiler that _you_ are going to control the TRIS, and the extra 'automatic' code is removed. This gives faster performance (hence the name...), but now _you_ would have to control TRIS before performing the read.

So you have two choices:
1) Let the compiler do it's job, and control TRIS for you. If so, you can remove the set_tris lines.
2) Elect to control TRIS yourself. Select fast_io, and make sure that you set TRIS before using the port.

The advantages of the latter, come in two places:
1) Speed.
2) It allows partial port I/O, without changing things.

The second is 'non obvious', but (for instance), if you want to have pin A0, as an input, while the rest of the port is an output, with fast_io selected, you can use:
Code:

set_tris_a(0b00000001);   // PORTA defined as output, except for A0 */
output_a(0);    // PORTA = 0; set to logical '0' */


This then performs an output on A1 to A7, all at once, _without changing the direction of A0_, which stays as an input. Whereas by default, it'll be changed to an output if this is done.....

So what you work is fine, but you don't need the tris statement at all, and provided you don't need to perform port I/O on 'part' of the port, without changing the direction register, will be OK.

Best Wishes
jacktaylor



Joined: 02 Sep 2017
Posts: 75

View user's profile Send private message Send e-mail

Doubts in the configuration of a Tris with input and output
PostPosted: Tue Jan 16, 2018 2:08 pm     Reply with quote

Friends
I've been reading this topic to try to heal a question.
I need to set the TRIT BIT RA4 during the program as output and at other times as input, but I still can not hit the code for programming. I would use a define #define IO tris xxxx. How would this code look, can you help me? I rated the answers of this topic but I could not understand how I can do this. For example, in another compiler I was able to do this by using a directive written as:

#define IO trisa.ra4;
During the program I assign IO = 0x00; or IO = 0x01 as required by the program.

How to do this in CCS?

Thank you. Embarassed Embarassed


Last edited by jacktaylor on Tue Jan 16, 2018 2:16 pm; edited 1 time in total
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Tue Jan 16, 2018 2:14 pm     Reply with quote

Code:
output_float(PIN_whatever); // this will set the tris bit for that pin to 1 (input)

output_drive(PIN_whatever); // this will set the tris bit for that pin to 0 (output)
jacktaylor



Joined: 02 Sep 2017
Posts: 75

View user's profile Send private message Send e-mail

Thanks NewGay
PostPosted: Tue Jan 16, 2018 2:33 pm     Reply with quote

Thanks Newguy, I'm testing the command. Thanks for the tip.

newguy wrote:
Code:
output_float(PIN_whatever); // this will set the tris bit for that pin to 1 (input)

output_drive(PIN_whatever); // this will set the tris bit for that pin to 0 (output)
Laughing Laughing
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Wed Jan 17, 2018 5:52 am     Reply with quote

To add to Newguy's post.

This is for the default, standard IO mode in CCS C. In this mode set_tris() is effectively redundant, and output_float() and output_drive() can be used instead, but are for individual IO pins instead of port-wide.

If you find yourself wanting to use set_tris then think again. Why do you need it? Do you really, really need it? CCS standard mode is so much simpler and easier and works fine for practically every application. Any use of set_tris should be regarded, in CCS C at least, as an advanced, even arcane, technique.

Code:
output_float(PIN_whatever); // this will set the tris bit for that pin to 1 (input)

output_drive(PIN_whatever); // this will set the tris bit for that pin to 0 (output)

output_low(PIN_whatever); // this will set the tris bit to 0 and drive the output low.

output_high(PIN_whatever); // this will set the tris bit to 0 and drive the output high.

output_bit(PIN_whatever, state); // this will set the tris bit to 0 and drive the output to the required state.

state = input(PIN_whatever); // this will set the tris bit to 1 and read the state of the pin.

state = input_state(PIN_whatever); // this reads the state of the pin without changing tris.


At power on or most other resets, the PIC hardware sets all tris bits to 1, making all GPIO pins inputs. They will stay as inputs until the first output call or set_tris call that sets them to outputs. It is advised that all unconnected GPIO pins are set as outputs (and driven low, though that doesn't matter much) rather than left as inputs as unconnected inputs have a very high input impendance and can float resulting in higher power consumption.

Something like this caused me a lot of headaches once when I was trying to find out why an FPGA (not my department) attached to an ARM processor (my bit) mysteriously locked up randomly typcially after several minutes operation. Naturally, as these things so often do, suspicion fell on me and my code. What had I done wrong? Well, I looked, and tested and checked and found no problems: my code was, I felt strongly, working well. I carried on testing and eventually found (no one else was looking into their bits as "obviously" such a problem had to be firmware...) that the FPGA, an SRAM based design that had to be loaded at power up, had a floating global reset input. So after many weeks, a simple pull-up resistor fixed what everyone except me was sworn blind had to be a firmware problem.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jan 17, 2018 6:38 am     Reply with quote

I agree stay with standard_io() ! It'll keep you out of trouble. I've only needed fast_io() ONCE in 20+ years of PICking. That project was both time and space critical. By using fast_io() I got to properly communicate with the 'other device' and saved a few bytes of code space. Back then PICs ran slower and didn't have a lot of memory.
If, and that's a BIG if, you need 'tight timing', then use fast_io() just be sure to comment what EACH pin is for as it's all too easy to make one an input when it needs to be an output at say, 2AM, 3rd pot of coffee......
Jay
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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