C4PICs V3 & multiprogrammer board (T0IF problem)

For C and ASSEMBLY users to post questions and code snippets for programming in C and ASSEMBLY. And for any other C or ASM course related questions.

Moderators: Benj, Mods

Post Reply
jvj
Posts: 2
Joined: Wed Feb 01, 2006 1:29 pm
Contact:

C4PICs V3 & multiprogrammer board (T0IF problem)

Post by jvj »

Hello:

I am working on the C course via the eblocks route. It appears that the
course was written for a different processor and a different board. Even the
simplest of programs yields complile and assembly errors when the target
is the 16F88, and works OK for the 16F84. I get a symbol not defined error
for the following line of code:
bcf INTCON, TOIF
The 16F88.inc file does not set a value for TOIF.

If I get a 16F84 for the mutliprogrammer board will the E-blocks support
the C course work?

Thanks Jules

Ian
Posts: 110
Joined: Thu Sep 29, 2005 10:53 am
Location: Matrix Multimedia
Been thanked: 1 time
Contact:

Post by Ian »

Go into the C2C options and un-tick the 'insert default interrupt handler' box.
This stops C2C putting in the bit of code that causes this issue.

User avatar
Steve
Matrix Staff
Posts: 3418
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Post by Steve »

An alternative approach may be to add the "T0IF" definition into the "INTCON" section of the 16F88.INC file as follows (the INC files will be located somewhere in the "MPASM" or "MPLAB" directories depending on which version of MPLAB you have installed):

Code: Select all

.
.
.
;----- INTCON Bits --------------------------------------------------------
GIE                          EQU     H'0007'
PEIE                         EQU     H'0006'
TMR0IE                       EQU     H'0005'
INTE                         EQU     H'0004'
RBIE                         EQU     H'0003'
TMR0IF                       EQU     H'0002'
T0IF                         EQU     H'0002'
INTF                         EQU     H'0001'
RBIF                         EQU     H'0000'
.
.
.
If you do this, make sure the "0" is the number zero, not a capital letter "O".

jvj
Posts: 2
Joined: Wed Feb 01, 2006 1:29 pm
Contact:

Thanks

Post by jvj »

Steve and Ian

Thanks for the help.

Jules

tgartlan
Flowcode V4 User
Posts: 4
Joined: Mon Sep 25, 2006 4:12 pm
Contact:

C exercises 2.3 2.4 2.5 do not work on pic16f88

Post by tgartlan »

Hi
I also am going thru the C programming exercises and ran into the T0IF problem. The soultion suggested here works fine, however I now find that even though exercise 2.3 2.4 and 2.5 seem to download correctly they simply do not work. 2.1 and 2.2 work fine. If I change the chip to a pic16f84A then the exercises work. However I would like to get the exercises working with the 16f88 chip since the suite of boards I bought for my class all contain 16f88 chips. Any ideas?
Thanks

User avatar
Steve
Matrix Staff
Posts: 3418
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Post by Steve »

I've just had a look at these programs, and I can see why there might be problems. I'm not 100% sure, but the problem could be with these lines:

Code: Select all

        /* if the light is on turn it off  */
        if (input_pin_port_a(0)) {
            output_low_port_a(0);
        }
        else {
            /* if the light is off turn it on  */
            output_high_port_a(0);
        }
The problem with this approach is that it depends on the electrical characteristic of the pin on the PICmicro and of the external electronics.

For example, if just an LED is connected to the pin then this will add a path to ground via a current-limiting resistor. If the LED is switched on (because of a previous "output_high" function call), then the "input_pin" function call will set the pin to be a high-impedence input, and then read the state of the pin.

At the point between changing to an input and actually reading the state of the pin, the voltage on the pin will be changing from high (because of its previous state) to low (because the pin is essentially pulled down to ground). How fast this happens will depend on the capacitance internal and external to the pin, and on how fast the code is executing.

It just may be that the 84A has a higher pin capacitance than the 88, and this causes this transition to be slower.

The author has adopted this approach because it doesn't involve variables and is conceptually easier. The course was originally written around a set chip (84A) and hardware (our v2 dev board). But unfortunately, it may not always work with other hardware setups.

Probably the simplest solution to this is to buy a load of 84A chips for your students - this is what we generally recommend.

Alternatively, (depending on the ability of your students) this problem could be used as a discussion point or investigation (could the actual capacitance be calculated from an oscillator trace?). Perhaps the brighter students will come up with a better solution to the program (e.g. using a variable to remember the output state).

tgartlan
Flowcode V4 User
Posts: 4
Joined: Mon Sep 25, 2006 4:12 pm
Contact:

Post by tgartlan »

O.K Thanks Steve...I'll look into this...At least I know it's a real problem

J. van Stijn
Posts: 8
Joined: Sun Oct 03, 2010 12:17 pm
Location: Arnhem, The Netherlands
Has thanked: 1 time
Contact:

Re:

Post by J. van Stijn »

Steve wrote:I've just had a look at these programs, and I can see why there might be problems. I'm not 100% sure, but the problem could be with these lines:

Code: Select all

        /* if the light is on turn it off  */
        if (input_pin_port_a(0)) {
            output_low_port_a(0);
        }
        else {
            /* if the light is off turn it on  */
            output_high_port_a(0);
        }
The problem with this approach is that it depends on the electrical characteristic of the pin on the PICmicro and of the external electronics.

...
Hi.

I'm currently working through the Matrix Course Viewer as part of my education and I bumped into the same problem.
However, I'm using the BoostC toolsuite with a PIC16F887A.

If I interpret correctly; It seems the code used for exercise isn't really well thought out... which worries me.
Here we are 4 years later and the problem is still present in the current course. According to the course viewer the exercises are written for a PIC16F88. The microcontroller which suffers from the same problem according to previous posts.

If something as simple as this hasn't been worked out properly. What else will I encounter on the remainder of the course?

User avatar
Steve
Matrix Staff
Posts: 3418
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Re: C4PICs V3 & multiprogrammer board (T0IF problem)

Post by Steve »

We've checked this particular issue and it works fine within the course on a 16F88 with E-blocks. We cannot guarantee that it will work with the 887 device. Have you had problems with these programs using a 16F88 on E-blocks or the HP488 dev board?

The technique used by the author is valid but as I explained in the previous post, differences in the hardware used could possibly affect the results. Variables are a difficult concept to understand for a beginner programmer and the code as it is written avoids the need for variables.

J. van Stijn
Posts: 8
Joined: Sun Oct 03, 2010 12:17 pm
Location: Arnhem, The Netherlands
Has thanked: 1 time
Contact:

Re: C4PICs V3 & multiprogrammer board (T0IF problem)

Post by J. van Stijn »

I'm using the E-blocks kit but with the PIC16F887A device, not the PIC16F88. (I don't even know what a HP448 dev board is) However tgartlan reported the exercises wouldn't work either on the PIC16F88 (see couple of posts back).

In the supplied documentation by my school it explicitly states we should use the PIC16F887A for this course. So I guess this is where it all went wrong. I shall address the problem at the proper people of the education.

For the problem at hand I've found a simple variable will do the trick indeed. Just perform all the operations on the variable and at the end of the algorithm shoot the value of the variable to the designated port. IMHO variables are a basic propery of the language C and should be known when starting with C4PIC. It will obviously help with some of the portability issues such as the one we are discussing right now.

Thanks for the help and happy holidays!

User avatar
Steve
Matrix Staff
Posts: 3418
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Re: C4PICs V3 & multiprogrammer board (T0IF problem)

Post by Steve »

I don't know why the 16F887(A) is mentioned. Are you sure it's not the 16F877A?

J. van Stijn
Posts: 8
Joined: Sun Oct 03, 2010 12:17 pm
Location: Arnhem, The Netherlands
Has thanked: 1 time
Contact:

Re: C4PICs V3 & multiprogrammer board (T0IF problem)

Post by J. van Stijn »

Steve wrote:I don't know why the 16F887(A) is mentioned. Are you sure it's not the 16F877A?
You are right. My bad. Type-O.

J. van Stijn
Posts: 8
Joined: Sun Oct 03, 2010 12:17 pm
Location: Arnhem, The Netherlands
Has thanked: 1 time
Contact:

Another issue

Post by J. van Stijn »

As I'm working through the course I got stuck at exercise 6.5 at a problem probably related to the one mentioned above.
I'm not sure if I should open another topic for it or just reply overhere, but here goes.

Exercise 6.5 doesn't seem to work with my PIC16F877A.
After some investigation I've concluded the problem resides in this function call:

Code: Select all

unsigned char key ( void ) 
{
    unsigned char count = 0 ;
    unsigned char oldv, newv ;
    oldv = porta & 0x01 ;
    while ( count < 20 ) {
        newv = porta & 0x01 ;
        if ( oldv == newv ) 
        {
            count++ ;
        }
        else 
        {
            count = 0 ;
            oldv = newv ;
        }
    }
    porta |= 0x04; /* Debugging code added by me */
    return oldv ;
}   

As you can see I've added a line of code for the purpose of debugging. The idea behind it is I use the remainder of the port A pins as debugging output which light up as the program progresses by simply switching bits on (not switching them off).
Because of these debug leds I can safely conclude the program is stuck in this function call which is called by this:

Code: Select all

        /*  wait for keypress         */
        while ( key() == 0 ) random () ;
        porta |= 0x08; /* Debugging code added by me */
After this function call bit 4 should come on which never does. So I can safely asume the key() function never returns a value other than 0.

Here is a piece of the mind boggle. The LED D2 (bit 3 of port A) is only glowing which indicates it is being turned on and off very fast (like PWM). According to my code bit 3 should only be turned on and never gets turned off. Nowhere in there is a line which writes directly to the port A only per bit so it cannot be turned off by another line in the program.

The second part which isn't clear to me is why there never is a return value other than 0.

J. van Stijn
Posts: 8
Joined: Sun Oct 03, 2010 12:17 pm
Location: Arnhem, The Netherlands
Has thanked: 1 time
Contact:

PORT A odd behaviour...

Post by J. van Stijn »

Sort of a break through here which I cannot fully explain other than 'weird behaviour' at Port A on my PIC16F877A.

I've written some debounce code of myself as replacement of the key() function in exercise 6.5

Code: Select all

 
#define MAXIMUM 20

unsigned char key ( void ) 
{

unsigned char input, output;
static unsigned char integrator=0;

        input = porta & 0x01; /* Attach the current value of pin 1 of port A to the variable */
        
        if (input) /* Pin 1 is high */
        {
                porta|= 0x04; /* Debugging outputs to determine the state of the key() function*/
                porta &=~0x08; /* Ditto */
                if(integrator >= MAXIMUM) output = 1; /* The integrator has reached maximum debounce time, thus input is high */
                else integrator++; /* The integrator has not yet reached maximum debounce time, thus should be increased */
        }
        else /* Pin 1 is low */
        {
                porta |=0x08; /* Debugging outputs to determine the state of the key() function */
                porta &=~0x04; /* Ditto */
                if(integrator > 0) integrator --; /* The integrator has not yet reached maximum debounce time, thus should be decreased */
                else output = 0; /* The integrator has reached the maximum debounce time, thus the input is low */
        }

        return output;
        
}
This code is quite basic so it should work, right? It doesn't on Port A, it does on another port like Port C!
The behaviour displayed when using port A is that bit 4 on Port A will glow very dim and is unresponsive to button pressing on bit 1 of port A.
Both things I simply cannot explain by just staring at the code and using logics.
So the question has become: What is wrong with Port A? Is my PIC busted or is it inherent behaviour of the PIC16F877A where Port A has other properties than on a PIC16F88?

Upon browsing through the datasheets of the PIC16F877A and the PIC16F88 I am unable to find anything noteworthy other than the lack of the ANSEL register at the PIC16F877A. But then again... I hardly know what I'm talking about. ;-)

User avatar
Steve
Matrix Staff
Posts: 3418
Joined: Tue Jan 03, 2006 3:59 pm
Has thanked: 114 times
Been thanked: 422 times
Contact:

Re: C4PICs V3 & multiprogrammer board (T0IF problem)

Post by Steve »

Pin A4 on a 16F877a is an "open drain" output and therefore needs an external pull-up for this pin to drive a load.

But neither piece of code in your previous email seems to reference this pin - 0x04 is pin 2 and 0x08 is pin 3.

You are correct that there is no ANSEL register in the 16F877a code. Instead, you need to use the ADCON1 register to select which pins are analogue and which are digital. If a pin is set to be an analogue input, you will not be able to use it as an output.

You also need to ensure that you set the TRISA register appropriately.

J. van Stijn
Posts: 8
Joined: Sun Oct 03, 2010 12:17 pm
Location: Arnhem, The Netherlands
Has thanked: 1 time
Contact:

Re: C4PICs V3 & multiprogrammer board (T0IF problem)

Post by J. van Stijn »

Steve wrote:Pin A4 on a 16F877a is an "open drain" output and therefore needs an external pull-up for this pin to drive a load.

But neither piece of code in your previous email seems to reference this pin - 0x04 is pin 2 and 0x08 is pin 3.

You are correct that there is no ANSEL register in the 16F877a code. Instead, you need to use the ADCON1 register to select which pins are analogue and which are digital. If a pin is set to be an analogue input, you will not be able to use it as an output.

You also need to ensure that you set the TRISA register appropriately.
Hi Steve,

Thank you very much! The adcon1=0x07 works! Apparently Port A is in analogue mode upon startup and only setting the TRISA register didn't quite do the trick it.

Post Reply