PIC12F675 GPIO problem

[opticalworm]

I’m having trouble simulation my program.
The purpose of the program is to test my new RGB LED.

**broken link removed**

it meant to flick through 8different combination that the LED can produce with Red Green and blue. That all it sound simple but its not.

I’m setting TRISIO = ob00101000 however when I put it through MPLAB simulation is doesn’t do that. And above that The GPIO aren't changing output.
This make me very

Here are my codes.

#define LED GPIO0
#define BLUE GPIO1
#define GREEN GPIO2
#define RED GPIO4
#define BUTTON GPIO3

#include<htc.h>

unsigned char HOLD =0;
unsigned char NEXT =0;


void main()
{
TRISIO = 0b00101000;
LED = 0;
BLUE = 1;
GREEN = 1;
RED = 1;
NEXT = 0;

while(1) /*LEDS starts off*/
{

if(BUTTON == 1)
{
if(HOLD ==0)
{
NEXT++;
HOLD = 1;
}
}
else
{
HOLD = 0;
}
if(NEXT == 0) /* B-OFF G-OFF R-ON */
{

LED = 0;
BLUE = 0;
GREEN = 0;
RED = 0;
}
if(NEXT == 1) /* B-OFF G-OFF R-ON */
{

LED = 1;
RED = 0;
RED = 1;
LED = 0;
}
if(NEXT == 2)/* B-OFF G-ON R-OFF */
{

LED = 1;
GREEN =0;
GREEN = 1;
LED = 0;
}
if(NEXT == 3)/* B-OFF G-ON R-ON */
{

LED = 1;
GREEN =0;
GREEN = 1;
RED = 0;
RED = 1;
LED = 0;
}
if(NEXT == 4)/* B-ON G-OFF R-OFF */
{

LED = 1;
BLUE = 0;
BLUE = 1;
LED = 0;
}
if(NEXT == 5)/* B-ON G-OFF R-ON */
{

LED = 1;
BLUE = 0;
BLUE = 1;
RED = 0;
RED = 1;
LED = 0;
}
if(NEXT == 6)/* B-ON G-ON R-OFF */
{

LED = 1;
BLUE = 0;
BLUE = 1;
GREEN =0;
GREEN = 1;
LED = 0;
}
if(NEXT == 7)/* B-ON G-ON R-ON */
{

LED = 1;
BLUE = 0;
BLUE = 1;
GREEN = 0;
GREEN = 1;
RED = 0;
RED = 1;
LED = 0;
}
if (NEXT == 8) /* B-OFF G-OFF R-OFF */
{
NEXT = 0;
}
}
}

 

[Papabravo]

You are assuming that general purpose IO is the default condition of the GPIO port. It is not! Read the datasheet very carefully to understand how one pin can serve several different functions. Note that in the case of the 12F675 the alternate functions of the GPIO pins are in fact the default behavior when the part comes out of RESET.

Go back to the datasheet and read it very carefully. Here is the link.

https://www.electro-tech-online.com/custompdfs/2006/06/41190c.pdf

Check out Example 3-1 on P.19

 

[opticalworm]

solved.

Thank Papabravo i went back to the datasheet. You are right I need to init
CMCON = 1;
ANSEL = 1;
in order to have digital input. i didn't realise that mistake. i quickly tested it and finally found a change in the inputs like I wanted. Thanks

 

[evandude]

[rant]I don't think I'll ever understand why many of these built in modules are enabled by default. normal I/O are used a lot, random hardware modules are used for specific purposes, and if you actually want to use them then you generally need to manually configure them with various registers ANYWAY, so it wouldn't be any trouble to enable them while you're at it. I have never used the comparator module in the PICs, not even once, in the several dozen projects I've done, but I've used the I/O pins associated with the comparator module many times... and yet Microchip thinks the comparator is important enough to take over those pins by default... and the parallel slave port in the 16F877... give me a break, I have never even heard of that being used. Having them on by default just adds extra steps to every program, even if you just want to do simple things like light up some LED's. It's almost like they just made it the default so that they could trip up beginners, like what happened here. I really think they should make a clear, obvious page at the beginning of the datasheet as a sort of "getting started" guide that lists any modules that are enabled by default (and potentially tells you what value you need to write to what register in order to disable it), all in one spot so you don't have to sift through the datasheet to find that out. After finding out about many of these modules the hard way, lately I have been paranoid and just explicitly disabling every module I can think of at the start of my programs, even if they're not going to be enabled by default, because it's often easier than trying to keep track of which ones I need to worry about.

[/rant]

 

[philba]

ansel should be 0 unless you need analog input on an0. if you aren't using the comparator then turn it off, cmcon = 7

I think you aren't going to see much because the leds will spend most of their time off. You should figure out how to slow it down so that each led stays on for longer than 1 instruction cycle. try writing a delay routine (lots of examples) and do something like this:

next = 0;
for(;;){
    next++;
    if(next & 0x1)  RED = 1;
        RED = 0;
    if(next & 0x2)  BLUE = 1;
        BLUE = 0;
    if(next & 0x4)  GREEN = 1;
        GREEN = 0;
   delay();
}

Also, I would tie the common pin on the LED to gnd rather than GPIO0 like you seem to have.

An even smaller pice of code would be to put r,g and b on GPIO0:2 and then do this:

for(;;){
    next++;
    GPIO = (GPIO & 0xF8) | (next & 0x7);
    delay();
}

when you post code, please use the "code" option, it's hard to read code with out proper indentation.


edti: fix stupid bug.

 

[philba]

[rant]I don't think I'll ever understand why many of these built in modules are enabled by default. normal I/O are used a lot, random hardware modules are used for specific purposes, and if you actually want to use them then you generally need to manually configure them with various registers ANYWAY, so it wouldn't be any trouble to enable them while you're at it. I have never used the comparator module in the PICs, not even once, in the several dozen projects I've done, but I've used the I/O pins associated with the comparator module many times... and yet Microchip thinks the comparator is important enough to take over those pins by default... and the parallel slave port in the 16F877... give me a break, I have never even heard of that being used. Having them on by default just adds extra steps to every program, even if you just want to do simple things like light up some LED's. It's almost like they just made it the default so that they could trip up beginners, like what happened here.

[/rant]

amen! how many man years are wasted trying to figure out whats wrong with the code when ANSEL = 0 was forgotten? I get bit by this more often than I would like. ditto on the watchdog timer...

 

[Papabravo]

It's good to have a place to rant and howl at the moon. I don't necessarily agree or disagree with your position but I applaud your courage for stating your position for God and everybody throw stones at.

Bravo, man!

 

[Pommie]

Reason why pins default to analogue.

There is a very good reason why input pins that are capable of being analogue inputs default as such.

Stated in section 12.3 of the 16F88 data sheet is the following,

2: Analog levels on any pin that is defined as
a digital input (including the RA4:RA0 and
RB7:RB6 pins), may cause the input
buffer to consume current out of the
device specification.

Because of the above, the pins have to default to analogue.

Mike.

 

[philba]

interesting point but it seems to me that anyone who is going to be using analog will figure they have to actually set the pins for analog input. I wanted to use the ADC first time I used the F88 and went looking how to enable analog. I was suprised to discover that the default actually was correct (at least for the pin ADC pins I was using).

Default on digital pins is output. I assume that doesn't cause high current.

 

[Pommie]

interesting point but it seems to me that anyone who is going to be using analog will figure they have to actually set the pins for analog input. I wanted to use the ADC first time I used the F88 and went looking how to enable analog. I was suprised to discover that the default actually was correct (at least for the pin ADC pins I was using).

If you design a circuit that requires analogue inputs and the chip defaulted to digital inputs then damaging currents may flow when it boots up. Hence it has to default to analogue.

Default on digital pins is output. I assume that doesn't cause high current.

All pins default to input.

Mike.
P.S. I have no idea WHY damaging currents would flow.

 

[eblc1388]

I also consider setting the pins to analogue by default is dumb but I later find out it has to be so.

In order to detect analogue signal, the PIC pin must be defined as anlogue input either by default or by user.

Let assume PIC pins default to digital input instead of analogue for the argument.

A pin on the PIC that expects analogue voltage will then have to be defined to be "analogue" after PIC reset but unfortunately the analogue voltage might already be presented when the PIC is reset.

If such voltage is right at the transision level then a digital input pin would not know how to deal with it and there will be large current flowing inside the PIC(why exactly I don't know either). This situation will continue until the pin is defined to be analogue in the program by user.

What's worrying is that the reset signal can be there for a long long time (when external reset signal is used) and the pin would be causing large current drain when the reset signal is present.

This is the best explanation I can come up with.

 

[Pommie]

Having looked at the data sheet, the best explanation I can come up with for why "out of specification" currents would flow is,

Max Voltage on digital input = Vdd
Max Vref = Vdd+0.3
Max Voltage on analogue input = Vref+0.3

So, the maximum voltage allowable on an analogue input is Vdd+0.6 which is above the maximum allowed on a digital input.

I also just noticed that the protection diodes are only present on pins with analogue capability. Edit, looks like all pins have diodes - just they're omitted from the diagrams. Makes me wonder what use they are now.

Mike.

 

[eblc1388]

It is the input voltage in the range of 0.8~2V that will be causing troubles to the digital input pins, should they default to digital after reset.

Digital input pin with Schmitt trigger partly ease this problem.

 

[Pommie]

It is the input voltage in the range of 0.8~2V that will be causing troubles to the digital input pins, should they default to digital after reset.

Where do you get this information from? I remember seeing a Microchip application note where they charged a capacitor and used a digital pin to detect when it goes form 0 to 1 (crude A2D). This would have spent some time in the range you quoted. I cannot find any indication of this limitation in the data sheet.

Mike.

 

[eblc1388]

I did not find this out per se.

It is just the grey area between the highest logic 0 and the lowest logic 1 input voltage for a TTL digital input as specified in the datasheet.

And even within this range, I think only a certain small voltage range would result in the "high current" situation as both output elements of the input buffer conducts. If the voltage on a capacitor rises upon charging, it will pass this small voltage range quickly and would not cause much lasting problem.

Also as I said in previous posting, a schmitt trigger input would be a solution.

 

[mramos1]

I think the mind set for many is. PICs are digital, this one has features, how do I turn them on. Now the defaults are on to make them the new chip you wanted in the first place.

Now, imagine the guy that buys it because he heard that was the latest chip to get, and he is going "I am tring to read the portA and I am getting weird data".. Then CMCON write and all is good (after any hour of playing around, then reads the datasheets.).

 

[Papabravo]

Gentlemen

The inherent nature of CMOS is that the levels on inputs need to be close to Vdd or Vss(GND), and they should make rapid transitions. As the voltage on an input moves toward threshold (Vdd/2) a gate or an input pad buffer is biased into its linear region. In the Complementary MOS output stage (internal to the processor) both the upper P-channel and the lower N-channel FETs are on creating a Vdd to Vss short. That is where the large currents come from. The very worst place for a CMOS input to be for any length of time is a Vdd/2.

 

[Pommie]

In that case, it seems strange that microchip have an application note where they deliberately slow charge a capacitor and monitor the voltage with a digital input. One such application note.

Mike.

 

[eblc1388]

In the application quoted above, it is also unknown why the designer choose to use GP0 instead of GP2 to sense the rising voltage on the capacitor.

GP2 is the pin with Schmitt trigger input configuration.

 

[Nigel Goodwin]

In the application quoted above, it is also unknown why the designer choose to use GP0 instead of GP2 to sense the rising voltage on the capacitor.

GP2 is the pin with Schmitt trigger input configuration.

It doesn't make are real difference, your fears about non-schmitt inputs are unfounded - the capacitor charging technique works just as well (but with different triggering levels) with either.