# Little help with how MPLAB X IDE reads code (C).

#### TestSubjectNR97

Joined Sep 30, 2017
2
I'm familiar with how programming works but this is just confusing.
C:
/*
* File:   newmain.c
* Author: TestSubjectNR97
*
* Created on September 30, 2017, 12:10 PM
*/

#include <stdio.h>
#include <stdlib.h>
#include <xc.h>

#pragma config WDTE = 0;  /* Watchdog timer OFF */

int main(int argc, char** argv) {
TRISC = 0b00000000;

TRISB = 0b01100000;

ANSEL  = 0b00000000;

ANSELH = 0b00000000;
int n;
while(1){
if(n<0){
PORTC = 0b00000010;
}else{
PORTC = 0b00000000;
}
n=n+1;
}
return (EXIT_SUCCESS);
}
So when i run this code i get a blinking diode witch is good. but idont understand how to code works. i have to use this code because it was in the assignment. So i get that n is an integer. starts with 0 and theN goes n = n+1 every time the while loop loops to infinity. the thing is. the led is supposed to light only when n is bellow 0
"if(n<0){
PORTC = 0b00000010;
}"
and n never goes down below 0. so why am i getting the led blinking ? How does this program read code or how does the microcontroller read the code ?
The code is in C language. Im using a PICKIT 3 with PIC16F690.

#### joeyd999

Joined Jun 6, 2011
4,477
I'm familiar with how programming works but this is just confusing.
Code:
/*
* File:   newmain.c
* Author: TestSubjectNR97
*
* Created on September 30, 2017, 12:10 PM
*/

#include <stdio.h>
#include <stdlib.h>
#include <xc.h>

#pragma config WDTE = 0;  /* Watchdog timer OFF */

int main(int argc, char** argv) {
TRISC = 0b00000000;

TRISB = 0b01100000;

ANSEL  = 0b00000000;

ANSELH = 0b00000000;
int n;
while(1){
if(n<0){
PORTC = 0b00000010;
}else{
PORTC = 0b00000000;
}
n=n+1;
}
return (EXIT_SUCCESS);
}
So when i run this code i get a blinking diode witch is good. but idont understand how to code works. i have to use this code because it was in the assignment. So i get that n is an integer. starts with 0 and theN goes n = n+1 every time the while loop loops to infinity. the thing is. the led is supposed to light only when n is bellow 0
"if(n<0){
PORTC = 0b00000010;
}"
and n never goes down below 0. so why am i getting the led blinking ? How does this program read code or how does the microcontroller read the code ?
The code is in C language. Im using a PICKIT 3 with PIC16F690.
Do you know how ints are represented? If not, learn that. Then you'll understand.

#### TestSubjectNR97

Joined Sep 30, 2017
2
so do i understand correctly. n starts with a 0 and goes upp till it hits 32.767 then jumps to -32.767 ?

#### joeyd999

Joined Jun 6, 2011
4,477
so do i understand correctly. n starts with a 0 and goes upp till it hits 32.767 then jumps to -32.767 ?
Close, assuming 16 bit ints and 32.767 == 32,767 in my locale.

Write out the binary representation and convert. Things will become clear quickly.

#### Papabravo

Joined Feb 24, 2006
15,729
so do i understand correctly. n starts with a 0 and goes upp till it hits 32.767 then jumps to -32.767 ?
No this is not quite correct. After incrementing the largest possible positive (aka non-negative) number you can have in signed 2's complement notation, 0x7FFF == 32767, you get 0x8000 == -32768. The correct specification of the range of an "int" is [-32768,...,32767]. On a smaller scale of three bits you have [-4, -3, -2, -1, 0, +1, +2, +3] == [0b100. 0b101, 0b110, 0b111, 0b000, 0b001, 0b010, 0b011]. This all happens because 0 is not a negative number and there needs to be equal numbers of negative and non-negative numbers.

#### Raymond Genovese

Joined Mar 5, 2016
1,658
so do i understand correctly. n starts with a 0 and goes upp till it hits 32.767 then jumps to -32.767 ?
I think that you have it after understanding the -32768 issue which was hinted at by @joeyd999 and spelled out by @Papabravo.

If you imagine the time it takes to increment ‘n’ from 0, until it is 0 again, you can see that for half of the time, the led will be lit and for the other half it will not be lit.

The point that I want to add is that there is no immutable law that says that a variable of type int has to be 16 bits (be it signed or unsigned). It depends on the compiler (and normally the decision is influenced by hardware architecture). This is true for all of the variable types that a compiler offers.

It is worthwhile to check and keep that in mind. So, for example, Microchip’s C18 compiler, lists the variable types and sizes in the User's Guide, page 11, Table 2-1.

#### Papabravo

Joined Feb 24, 2006
15,729
I think that you have it after understanding the -32768 issue which was hinted at by @joeyd999 and spelled out by @Papabravo.

If you imagine the time it takes to increment ‘n’ from 0, until it is 0 again, you can see that for half of the time, the led will be lit and for the other half it will not be lit.

The point that I want to add is that there is no immutable law that says that a variable of type int has to be 16 bits (be it signed or unsigned). It depends on the compiler (and normally the decision is influenced by hardware architecture). This is true for all of the variable types that a compiler offers.

It is worthwhile to check and keep that in mind. So, for example, Microchip’s C18 compiler, lists the variable types and sizes in the User's Guide, page 11, Table 2-1.
It is also worthwhile noting that the same configuration of bits can be typecast without changing the actual bits. The example is and "int" and an "unsigned int". If i and ui are an int and an unsigned int respectively, then the relational expression (ui < 0) will always be false. Similarly the expression (((unsigned int) i)<0) will also always be false. Now ((int) ui) might be less than zero or greater than zero depending on the specific bits.

Writing little test programs to print numbers in decimal and hexidecimal and testing them with respect to zero can be illuminating. It can also reveal things about how big an int really is on a given compiler.
Her is a cute little program:
1. Initialize a numeric variable, n, of some type to 1
2. While (n !=0)
3. {
4. printf("%d %x\n",n,n) ;
5. n <<= 1;
6. }
The last non-zero value will tell you about how the compiler defines the type in question, because eventually the single bit will be shifted off the left end of the word containing the numeric quantity.