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 CCS Technical Support

How to start with high output pin?

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



Joined: 17 Oct 2005
Posts: 98

View user's profile Send private message

How to start with high output pin?
PostPosted: Thu Nov 08, 2007 3:48 pm     Reply with quote

Hello,

Simple question: How can a PIC pin start as high output right after selecting the pin as output?

I use PIC12F629 and v.4.057.

I have this code in the beginning of main():

Code:
   GP0 = 0;
   GP1 = 0;
   GP4 = 1;
   GP5 = 1;

   GP0IO = 0; // Make GP0 an output
   GP1IO = 0; // Make GP1 an output
   GP2IO = 1; // Make GP2 an input
   GP4IO = 0; // Make GP4 an output
   GP5IO = 0; // Make GP5 an output


But when the program runs, only GP5 is high. I need both these pins to be high, because they are connected to the gates of a MOSFET H-bridge and the MOSFET gates are driven high by pull-ups as long as the PIC pins are high impedance. So if any of the GP4 and GP5 pins are low the moment they turn from inputs to outputs, the H-bridge will short circuit.

The pin names and directions are declared like this:

// GPIO REGISTER
#byte GPIO = 0x05
#bit GP5 = GPIO.5 // GP5 Pin Data bit
#bit GP4 = GPIO.4 // GP4 Pin Data bit
#bit GP3 = GPIO.3 // GP3 Pin Data bit
#bit GP2 = GPIO.2 // GP2 Pin Data bit
#bit GP1 = GPIO.1 // GP1 Pin Data bit
#bit GP0 = GPIO.0 // GP0 Pin Data bit

// GPIO TRISTATE REGISTER
#byte TRISIO = 0x85
#bit GP5IO = TRISIO.5 // GP5 Data Direction bit
#bit GP4IO = TRISIO.4 // GP4 Data Direction bit
#bit GP3IO = TRISIO.3 // GP3 Data Direction bit
#bit GP2IO = TRISIO.2 // GP2 Data Direction bit
#bit GP1IO = TRISIO.1 // GP1 Data Direction bit
#bit GP0IO = TRISIO.0 // GP0 Data Direction bit


Any ideas?


Last edited by Futterama on Thu Nov 08, 2007 3:57 pm; edited 1 time in total
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Nov 08, 2007 3:56 pm     Reply with quote

Specify the INTRC_IO fuse.
Futterama



Joined: 17 Oct 2005
Posts: 98

View user's profile Send private message

PostPosted: Thu Nov 08, 2007 3:58 pm     Reply with quote

PCM programmer wrote:
Specify the INTRC_IO fuse.

These are my fuses:

Code:
#FUSES NOWDT                    //No Watch Dog Timer
#FUSES INTRC_IO                 //Internal RC Osc, no CLKOUT
#FUSES NOCPD                    //No EE protection
#FUSES NOPROTECT                //Code not protected from reading
#FUSES NOMCLR                   //Master Clear pin used for I/O
#FUSES PUT                      //Power Up Timer
#FUSES NOBROWNOUT               //No brownout reset
#FUSES BANDGAP_HIGH             //Highest bandgap voltage for BOD and POR


Actually, I also just discovered it's not only the GP4 thats a problem. The GP0 and GP1 should be low when they turn from inputs to outputs, but somehow they are high.

By the way: The output latch state is unknown on reset.

Shouldn't I be able to write to the output latch even though the pins are still inputs?
Ttelmah
Guest







PostPosted: Thu Nov 08, 2007 4:24 pm     Reply with quote

Do three things.
1) Make sure you have fast_io. If this is not the case, the compiler will add TRIS control statements for you.
2) Update the entire output in one instruction.
3) Do the same for the TRIS.
On the 12, and 16 chips, there is not a separate accessible output latch, there is only a combined I/O latch. As such, updating any individual port bit, will result in the other bits being read at the same time, and the latch contents updated. When updating any single bit, there must be a delay before the next read operation, to allow the bit to really 'reach' the required state (this is known as the 'RMW' problem on the PICs - read, modify, write). Hence updating the whole port is much safer.
So, I'd perform:
#use fast_io(a)

output_a(0b110000);
set_tris_a(0b001100);

Separately, remember you need to ensure the other I/O functions on the pins are turned off. Personally, I'd always add large value resistors, to ensure the pins are biased to the 'safe' state, until the processor is awake. Otherwise it only takes the pin to be charged to a previous 'on' voltage, to result in unacceptable curent levels during boot...

Best Wishes
Futterama



Joined: 17 Oct 2005
Posts: 98

View user's profile Send private message

PostPosted: Thu Nov 08, 2007 4:39 pm     Reply with quote

What happened to PCM programmers post?

I read it, and he was so right, I didn't think of that (setting on bit at a time with read modify write).

But when I wanted to quote his reply, it was gone Sad
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Nov 08, 2007 4:50 pm     Reply with quote

Just after I made my post about the read-modify-write issue, I saw that
Ttelmah had already posted an answer to it. (I wasn't quick enough on
the composition). Since I didn't want to give the appearance of stepping
on his post, I removed my last reply.
Futterama



Joined: 17 Oct 2005
Posts: 98

View user's profile Send private message

PostPosted: Thu Nov 08, 2007 4:52 pm     Reply with quote

PCM programmer wrote:
Just after I made my post about the read-modify-write issue, I saw that
Ttelmah had already posted an answer to it. (I wasn't quick enough on
the composition). Since I didn't want to give the appearance of stepping
on his post, I removed my last reply.

I liked your version of the explanation better Wink no offence Ttelmah, your reply was good too Very Happy
Ttelmah
Guest







PostPosted: Fri Nov 09, 2007 3:28 am     Reply with quote

Not at all.
PCM programmer, is one of the people here, who generally, is 'firing on all cylinders', and he is much better at some explanations than me.
Sometimes we end up posting multiple answers on the same thread. Usually I have started composing an answer, ge nearly finished, and then get sidetracked (phone call or something), come back and hit 'send', to find that multiple similar answers have appeared (I think the record, stands at seven!...).
Sometimes, it is really 'nice', to see just slightly different versions, since you then get the thing of seeing the problem from a slightly different 'angle', and can learn more stuff yourself. Smile

Best Wishes
avarachan
Guest







12f629 lock out problem
PostPosted: Sat Nov 17, 2007 4:44 pm     Reply with quote

Hi,

I had the same problem of 12f629 lock out. I found a post about brown out fuse here. It solved the problem. I am writing this just in case any one who needs this info can get it.

Scene:I was using 12f629 with GP0 and 1 as unputs, 2 as output. When I power up, sometimes GP2 starts as high, which i dont want to. Bcz I use GP2 to trigger a switch when GP0 and 1 as comparators give a high out. Again, some times when i Power up, the chip locks out, and no response.

Solution: I was having NOBROWNOUT fuse set. I changed it to BROWNOUT. Every thing is fine now.
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