Pins high, pins low, pins switching on their own??

[Tony H.]

Ok, this was a stupid little problem for a little experiment.

I had modified ex_sqw.c for two things:

1) to alternate pin B0 at a speed of 1Hz.

2) To alternate pin B1 at a speed of ! .5Hz.

Ok, now I figured I would be able to do this just by modifying the code (yes, I realize the delays aren't quite right and that it won't be exactly 1 hz or .5 hz - but it is close enough for me to see if it works before I start counting instructions to figure the actual delay.

So here is my code...

#include <16f877.h>

#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_A3, rcv=PIN_A2)

main() {
short x;
x=1;
while (TRUE) {
output_high (PIN_B0);
delay_ms(500);
output_low(PIN_B0);
delay_ms(499);
if (x==1)
{
output_high(PIN_B1);
x=0;
}
else
{
output_low(PIN_B1);
x=1;
}
}
}

I created a variable X to be a basic toggle, every loop of the program X is tested (I had tried if(x), and figured maybe it wasn't testing X on a 1/0 basis, so I tried x==1.

In theory this should work. in practice, it doesn't. I had to change it so...

main looked like:

main() {
short x;
x=1;
while (TRUE) {
if (x==1)
{
output_high(PIN_B1);
x=0;
}
else
{
output_low(PIN_B1);
x=1;
}
output_high (PIN_B0);
delay_ms(500);
output_low(PIN_B0);
delay_ms(499);

}
}

Now I also notice that for the first two loops, it works ok, then the led's do something funky, and then they start blinking as they should. I'm not sure what the deal is with that, I'm thinking of trying forcing the pins low first to see if that changes matters.

But, does anyone have any idea why it would only work at the beginning of the while loop rather then the end? At this point, I think it is a tweaking thing of either the project board, or the way it compiles, as the code is sound for what I am trying to do.

-Tony
___________________________
This message was ported from CCS's old forum
Original Post ID: 6059

[Tony H.]

Update:

I called support, and found what was causing my problem with regards to the LED's working for a few alternations, then they "do something funky", then after a bit work normally. This line took care of it:

#fuses nowdt, nolvp

at first, they felt it might be the watchdog timer causing a problem, but after that didn't change matters (left it in for my own piece of mind), they had me add the nolvp fuses, which is some sort of low voltage reset which was causing the problem.
___________________________
This message was ported from CCS's old forum
Original Post ID: 6062

[R.J.Hamlett]

:=Update:
:=
:=I called support, and found what was causing my problem with regards to the LED's working for a few alternations, then they "do something funky", then after a bit work normally. This line took care of it:
:=
:=#fuses nowdt, nolvp
:=
:=at first, they felt it might be the watchdog timer causing a problem, but after that didn't change matters (left it in for my own piece of mind), they had me add the nolvp fuses, which is some sort of low voltage reset which was causing the problem.

Not a 'reset'. The LVP ability, allows the chip to be reprogrammed at low voltage (no sperate Vpp supply), but pin RB3, then becomes the low voltage programming input. This pin _must_ then be held low (or the chip will think you want to reprogram it...). This is what was happening to you.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 6064

[johnpcunningham]

Tony,

When working with microcontrollers it is VERY important to initialize the device to a known state. For example, I always make sure all of the pins are configure as inputs or outputs. Those that are inputs need to be tied high or low if they are not used. Make sure that you set the fuses statements properly such as below:

#fuses HS,NOWDT,NOPUT, NOPROTECT, NOBROWNOUT, NOLVP, NOCPD, NOWRT, DEBUG

////////////////////////////////////////////////////
//////// C Scratch area: 20 ID Location: 2000
//Fuses: LP,XT,HS,RC,NOWDT,WDT,NOPUT,PUT,PROTECT,PROTECT_88\%
//Fuses: PROTECT_50\%,NOPROTECT,BROWNOUT,NOBROWNOUT,LVP,NOLVP,CPD
//Fuses: NOCPD,WRT,NOWRT,DEBUG,NODEBUG
////////////////////////////////////////////////////

If you progam with MPLAB, make sure that settings for the fuses there are set properly caue they override the $fuses setting in the code.

Take a look at these definitions in the manual:

//#use STANDARD_IO (A)
//#use STANDARD_IO (B)
//#use STANDARD_IO (B)
//#use STANDARD_IO (D)
//#use STANDARD_IO (E)

//#use fast_io(a)
//#use fast_io(b)
//#use fast_io(c)
//#use fast_io(d)
//#use fast_io(e)

By using the output_low() and high statement, you are assuming that the TRIS register is set properly. If you use teh STANDARD_IO statement before the code, the compiler is supposed to make sure that the pin you write is an output prior to sending the data. I think it is good practice to set up all of the ports in an initialization routine before running any practical code. Here is an idea:

JC


////////////////////////////////////////////////
//PORT A conntections//
#define ANALOG_PROBE_PIN PIN_A0
#define BATTERY_PIN PIN_A1

//PORT B conntections//
#define CAL_PIN PIN_B0
#define INLET_PIN PIN_B4
#define FLOW_PIN PIN_B5

//PORT C conntections//
#define GRN_LED PIN_C0
#define YEL_LED PIN_C1
#define RED_LED PIN_C2
#define BLUE_STIM PIN_C3
#define WHITE_STIM PIN_C4
#define BATTERY_CHECK_PIN PIN_C5

void init_chip()
{
//SET_UP_PORT PINS

//PORTA
#use STANDARD_IO (A)
output_float(ANALOG_PROBE_PIN);
output_float(BATTERY_PIN);

//PORTB
#use STANDARD_IO (B)
port_b_pullups(TRUE);
bit_set(OPTION_REG, b_INTEDG); // 10 bit left justified
output_float(CAL_PIN);
output_float(INLET_PIN);
output_float(FLOW_PIN);

//PORTC
#use STANDARD_IO (C)
output_high(GRN_LED);
output_high(YEL_LED);
output_high(RED_LED);
output_low(BLUE_STIM);
output_low(WHITE_STIM);
output_low(BATTERY_CHECK_PIN);

//INITIALIZE THE ANALOG PORTION
setup_adc_ports( RA0_RA1_RA3_ANALOG);
setup_adc(ADC_CLOCK_INTERNAL);
bit_set(ADCON1, b_ADFM);// 10 bit conversion left justified


//CLEAR ALL INTERUPT FLAGS
INTCON = 0b01001000; //periph and RB7-RB4 enabled
PIE2 = 0x00;
PIR1 = 0x00;
PIE2 = 0x00;

}
___________________________
This message was ported from CCS's old forum
Original Post ID: 6066

[Tony H.]

Hmm,

so, basically, if I am using low voltages, I either need to make sure

#fuses nolvp

is set, or make sure that RB3 is low.

Ok, now it makes a bit more sense.

-Tony

:=
:=Not a 'reset'. The LVP ability, allows the chip to be reprogrammed at low voltage (no sperate Vpp supply), but pin RB3, then becomes the low voltage programming input. This pin _must_ then be held low (or the chip will think you want to reprogram it...). This is what was happening to you.
:=
:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 6068

[Bill Gates]

:=Hmm,
:=
:=so, basically, if I am using low voltages, I either need to make sure
:=
:=#fuses nolvp
:=
:=is set, or make sure that RB3 is low.
:=
:=Ok, now it makes a bit more sense.
:=
:=-Tony
:=
:=:=
:=:=Not a 'reset'. The LVP ability, allows the chip to be reprogrammed at low voltage (no sperate Vpp supply), but pin RB3, then becomes the low voltage programming input. This pin _must_ then be held low (or the chip will think you want to reprogram it...). This is what was happening to you.
:=:=
:=:=Best Wishes

No, "Low Voltage" Programming means you can program the device in circuit, nothing to do with using "low voltages" so simple turn it of unless you want to program/reprogram the device in circuit.

Cya
___________________________
This message was ported from CCS's old forum
Original Post ID: 6073