[SOLVED] PIC complete discussion for all

[romel_emperado]

thanks bigdogguru,

I have that site also..it's excellent site full of examples.... thanks...:smile:

 

[romel_emperado]

tomorrow is friday... friday afternoon end of my weekly exams... I'l resume my learning here.. hehe

 

[romel_emperado]

guys is it possible to write a wav file in the MMC using uart of PIC18f4550?? (I dont know usb yet.. hehe )

assuming I knew already to read/write to MMC.. hehe

 

[ckshivaram]

PIC18f4550 does not support MDD format i was told that it would be fixed in the next versions.. you can use SPI format for that purpose... its easy.. you just need to need to read and write FAT file system..........

 

[romel_emperado]

PIC18f4550 does not support MDD format i was told that it would be fixed in the next versions.. you can use SPI format for that purpose... its easy.. you just need to need to read and write FAT file system..........

thaks..

this is what I am going to do

MMC <--SPI-->PIC18f4550 <---USART--->PC

I want to read/write in the MMC using SPI protocol then the data to be written is from PC via UART.. is it possible??

the data trying to write is wav file.. is it possible? hehe

 

[FvM]

I want to read/write in the MMC using SPI protocol then the data to be written is from PC via UART.. is it possible??

the data trying to write is wav file.. is it possible?

Yes and yes. But which data format do you intend for the UART transmission? You can of course transmit plain binary wave data, as read from the file. But how will the UART receiver detect start and end of file? A single transmission error can possibly corrupt the wave data. That's why people prefer special encoding and transmission protocols with consistency checks for binary data.

However, the said problem is far beyond this thread's topic. I generally think, people shouldn't encourage the original poster to continue the thread like an off-topic chat or personal blog. Strictly spoken, it's against the forum rules. Just try to imagine a user, who is searching the forum discussion for specific answers. I guess, he'll find threads like this very annoying.

 

[romel_emperado]

A single transmission error can possibly corrupt the wave data. That's why people prefer special encoding and transmission protocols with consistency checks for binary data.

just asking if it is possible...thanks so much

However, the said problem is far beyond this thread's topic. I generally think, people shouldn't encourage the original poster to continue the thread like an off-topic chat or personal blog. Strictly spoken, it's against the forum rules.

I will try to ask favor to some moderators to edit my thread title.....sorry,,,

---------- Post added at 15:38 ---------- Previous post was at 15:27 ----------

@FvM, sorry for the inconvenience..

 

[romel_emperado]

hi have something to ask... hehe

I did a shift right routine as a laboratory exercise of one of my subjects but I think there's another way of writing better than this code...

void shift_right()
{
	 char c;
	 if(P1 == 0x04)
	  {
		P2 = 0xA0;	
		for(c=0; c<3; c++)
		{	
			delay_ms(1000);
			P2 = P2 >> 1;
		}
		  
	  }

}

 

[bigdogguru]

hi have something to ask... hehe

I did a shift right routine as a laboratory exercise of one of my subjects but I think there's another way of writing better than this code...

void shift_right()
{
	 char c;
	 if(P1 == 0x04)
	  {
		P2 = 0xA0;	
		for(c=0; c<3; c++)
		{	
			delay_ms(1000);
			P2 = P2 >> 1;
		}
		  
	  }

}

Hi Romel,

What is the actual purpose of the code snippet?

Is the one second delay within the for loop for display purposes? Is P2 being displayed on LEDs, etc?

 

[bigdogguru]

plz help me i m beginner in pic and MPLab.......in the pic 16f877a i use timer0.....and than i use T0CON (timer0 control). the MPLab complier give the :
Error [192] F:\PIC16F877A\MPLab\test_2.c; 10.1 undefined identifier "T0CON"

plz plz help me.!

You need to reference the appropriate datasheet and header file with the #defines, in this case the "pic16f877a.h":

PIC16F877A Product Page

PIC16F87XA Data Sheet


Reference PIC16F87XA Data Sheet, pg 53, 5.0 TIMER0 MODULE and 5.1 Timer0 Interrupt

5.0 TIMER0 MODULE

The Timer0 module timer/counter has the following
features:
• 8-bit timer/counter
• Readable and writable
• 8-bit software programmable prescaler
• Internal or external clock select
• Interrupt on overflow from FFh to 00h
• Edge select for external clock
Figure 5-1 is a block diagram of the Timer0 module and
the prescaler shared with the WDT.
Additional information on the Timer0 module is
available in the PICmicro® Mid-Range MCU Family
Reference Manual (DS33023).
Timer mode is selected by clearing bit T0CS
(OPTION_REG<5>). In Timer mode, the Timer0
module will increment every instruction cycle (without
prescaler). If the TMR0 register is written, the increment
is inhibited for the following two instruction cycles.
The user can work around this by writing an adjusted
value to the TMR0 register.

Counter mode is selected by setting bit T0CS
(OPTION_REG<5>). In Counter mode, Timer0 will
increment either on every rising or falling edge of pin
RA4/T0CKI. The incrementing edge is determined by
the Timer0 Source Edge Select bit, T0SE
(OPTION_REG<4>). Clearing bit T0SE selects the rising
edge. Restrictions on the external clock input are
discussed in detail in Section 5.2 “Using Timer0 with
an External Clock”.
The prescaler is mutually exclusively shared between
the Timer0 module and the Watchdog Timer. The
prescaler is not readable or writable. Section 5.3
“Prescaler” details the operation of the prescaler.

5.1 Timer0 Interrupt
The TMR0 interrupt is generated when the TMR0
register overflows from FFh to 00h. This overflow sets
bit TMR0IF (INTCON<2>). The interrupt can be
masked by clearing bit TMR0IE (INTCON<5>). Bit
TMR0IF must be cleared in software by the Timer0
module Interrupt Service Routine before re-enabling
this interrupt. The TMR0 interrupt cannot awaken the
processor from Sleep since the timer is shut-off during
Sleep.

TMR0 does not have its own control register, rather setup is accomplished in OPTION_REG, INTCON and TMR0 registers.

You can find the appropriate device header in the include directory, e.g.:

C:\Program Files\HI-TECH Software\PICC\9.81\include

Which contain the correct #defines to refer to Configuration Bits, Registers, etc.

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
#ifndef _HTC_H_
#warning Header file pic16f877a.h included directly. Use #include <htc.h> instead.
#endif
 
/* header file for the MICROCHIP PIC microcontroller
 *  16F877A
 */
 
 
#ifndef __PIC16F877A_H
#define __PIC16F877A_H
 
//
// Configuration mask definitions
//
 
 
// Config Register: CONFIG
#define CONFIG               0x2007
// Oscillator Selection bits
// RC oscillator
#define FOSC_EXTRC           0xFFFF
// HS oscillator
#define FOSC_HS              0xFFFE
// XT oscillator
#define FOSC_XT              0xFFFD
// LP oscillator
#define FOSC_LP              0xFFFC
// Watchdog Timer Enable bit
// WDT enabled
#define WDTE_ON              0xFFFF
// WDT disabled
#define WDTE_OFF             0xFFFB
// Power-up Timer Enable bit
// PWRT disabled
#define PWRTE_OFF            0xFFFF
// PWRT enabled
#define PWRTE_ON             0xFFF7
// Brown-out Reset Enable bit
// BOR enabled
#define BOREN_ON             0xFFFF
// BOR disabled
#define BOREN_OFF            0xFFBF
// Low-Voltage (Single-Supply) In-Circuit Serial Programming Enable bit
// RB3/PGM pin has PGM function; low-voltage programming enabled
#define LVP_ON               0xFFFF
// RB3 is digital I/O, HV on MCLR must be used for programming
#define LVP_OFF              0xFF7F
// Data EEPROM Memory Code Protection bit
// Data EEPROM code protection off
#define CPD_OFF              0xFFFF
// Data EEPROM code-protected
#define CPD_ON               0xFEFF
// Flash Program Memory Write Enable bits
// Write protection off; all program memory may be written to by EECON control
#define WRT_OFF              0xFFFF
// 0000h to 00FFh write-protected; 0100h to 1FFFh may be written to by EECON control
#define WRT_256              0xFDFF
// 0000h to 07FFh write-protected; 0800h to 1FFFh may be written to by EECON control
#define WRT_1FOURTH          0xFBFF
// 0000h to 0FFFh write-protected; 1000h to 1FFFh may be written to by EECON control
#define WRT_HALF             0xF9FF
// In-Circuit Debugger Mode bit
// In-Circuit Debugger disabled, RB6 and RB7 are general purpose I/O pins
#define DEBUG_OFF            0xFFFF
// In-Circuit Debugger enabled, RB6 and RB7 are dedicated to the debugger
#define DEBUG_ON             0xF7FF
// Flash Program Memory Code Protection bit
// Code protection off
#define CP_OFF               0xFFFF
// All program memory code-protected
#define CP_ON                0xDFFF
 
//
// Special function register definitions
//
 
 
// Register: INDF
volatile unsigned char           INDF                @ 0x000;
// bit and bitfield definitions
 
// Register: TMR0
volatile unsigned char           TMR0                @ 0x001;
// bit and bitfield definitions
 
// Register: PCL
volatile unsigned char           PCL                 @ 0x002;
// bit and bitfield definitions
 
// Register: STATUS
volatile unsigned char           STATUS              @ 0x003;
// bit and bitfield definitions
volatile bit CARRY               @ ((unsigned)&STATUS*8)+0;
volatile bit DC                  @ ((unsigned)&STATUS*8)+1;
volatile bit ZERO                @ ((unsigned)&STATUS*8)+2;
volatile bit nPD                 @ ((unsigned)&STATUS*8)+3;
volatile bit nTO                 @ ((unsigned)&STATUS*8)+4;
volatile bit IRP                 @ ((unsigned)&STATUS*8)+7;
volatile bit RP0                 @ ((unsigned)&STATUS*8)+5;
volatile bit RP1                 @ ((unsigned)&STATUS*8)+6;
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    C                   : 1;
        unsigned    DC                  : 1;
        unsigned    Z                   : 1;
        unsigned    nPD                 : 1;
        unsigned    nTO                 : 1;
        unsigned    RP                  : 2;
        unsigned    IRP                 : 1;
    };
    struct {
        unsigned                        : 5;
        unsigned    RP0                 : 1;
        unsigned    RP1                 : 1;
    };
} STATUSbits @ 0x003;
#endif
 
// Register: FSR
volatile unsigned char           FSR                 @ 0x004;
// bit and bitfield definitions
 
// Register: PORTA
volatile unsigned char           PORTA               @ 0x005;
// bit and bitfield definitions
volatile bit RA0                 @ ((unsigned)&PORTA*8)+0;
volatile bit RA1                 @ ((unsigned)&PORTA*8)+1;
volatile bit RA2                 @ ((unsigned)&PORTA*8)+2;
volatile bit RA3                 @ ((unsigned)&PORTA*8)+3;
volatile bit RA4                 @ ((unsigned)&PORTA*8)+4;
volatile bit RA5                 @ ((unsigned)&PORTA*8)+5;
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    RA0                 : 1;
        unsigned    RA1                 : 1;
        unsigned    RA2                 : 1;
        unsigned    RA3                 : 1;
        unsigned    RA4                 : 1;
        unsigned    RA5                 : 1;
    };
} PORTAbits @ 0x005;
#endif
 
// Register: PORTB
volatile unsigned char           PORTB               @ 0x006;
// bit and bitfield definitions
volatile bit RB0                 @ ((unsigned)&PORTB*8)+0;
volatile bit RB1                 @ ((unsigned)&PORTB*8)+1;
volatile bit RB2                 @ ((unsigned)&PORTB*8)+2;
volatile bit RB3                 @ ((unsigned)&PORTB*8)+3;
volatile bit RB4                 @ ((unsigned)&PORTB*8)+4;
volatile bit RB5                 @ ((unsigned)&PORTB*8)+5;
volatile bit RB6                 @ ((unsigned)&PORTB*8)+6;
volatile bit RB7                 @ ((unsigned)&PORTB*8)+7;
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    RB0                 : 1;
        unsigned    RB1                 : 1;
        unsigned    RB2                 : 1;
        unsigned    RB3                 : 1;
        unsigned    RB4                 : 1;
        unsigned    RB5                 : 1;
        unsigned    RB6                 : 1;
        unsigned    RB7                 : 1;
    };
} PORTBbits @ 0x006;
#endif
 
// Register: PORTC
volatile unsigned char           PORTC               @ 0x007;
// bit and bitfield definitions
volatile bit RC0                 @ ((unsigned)&PORTC*8)+0;
volatile bit RC1                 @ ((unsigned)&PORTC*8)+1;
volatile bit RC2                 @ ((unsigned)&PORTC*8)+2;
volatile bit RC3                 @ ((unsigned)&PORTC*8)+3;
volatile bit RC4                 @ ((unsigned)&PORTC*8)+4;
volatile bit RC5                 @ ((unsigned)&PORTC*8)+5;
volatile bit RC6                 @ ((unsigned)&PORTC*8)+6;
volatile bit RC7                 @ ((unsigned)&PORTC*8)+7;
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    RC0                 : 1;
        unsigned    RC1                 : 1;
        unsigned    RC2                 : 1;
        unsigned    RC3                 : 1;
        unsigned    RC4                 : 1;
        unsigned    RC5                 : 1;
        unsigned    RC6                 : 1;
        unsigned    RC7                 : 1;
    };
} PORTCbits @ 0x007;
#endif
 
// Register: PORTD
volatile unsigned char           PORTD               @ 0x008;
// bit and bitfield definitions
volatile bit RD0                 @ ((unsigned)&PORTD*8)+0;
volatile bit RD1                 @ ((unsigned)&PORTD*8)+1;
volatile bit RD2                 @ ((unsigned)&PORTD*8)+2;
volatile bit RD3                 @ ((unsigned)&PORTD*8)+3;
volatile bit RD4                 @ ((unsigned)&PORTD*8)+4;
volatile bit RD5                 @ ((unsigned)&PORTD*8)+5;
volatile bit RD6                 @ ((unsigned)&PORTD*8)+6;
volatile bit RD7                 @ ((unsigned)&PORTD*8)+7;
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    RD0                 : 1;
        unsigned    RD1                 : 1;
        unsigned    RD2                 : 1;
        unsigned    RD3                 : 1;
        unsigned    RD4                 : 1;
        unsigned    RD5                 : 1;
        unsigned    RD6                 : 1;
        unsigned    RD7                 : 1;
    };
} PORTDbits @ 0x008;
#endif
 
// Register: PORTE
volatile unsigned char           PORTE               @ 0x009;
// bit and bitfield definitions
volatile bit RE0                 @ ((unsigned)&PORTE*8)+0;
volatile bit RE1                 @ ((unsigned)&PORTE*8)+1;
volatile bit RE2                 @ ((unsigned)&PORTE*8)+2;
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    RE0                 : 1;
        unsigned    RE1                 : 1;
        unsigned    RE2                 : 1;
    };
} PORTEbits @ 0x009;
#endif
 
// Register: PCLATH
volatile unsigned char           PCLATH              @ 0x00A;
// bit and bitfield definitions
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    PCLATH              : 5;
    };
} PCLATHbits @ 0x00A;
#endif
 
// Register: INTCON
volatile unsigned char           INTCON              @ 0x00B;
// bit and bitfield definitions
volatile bit RBIF                @ ((unsigned)&INTCON*8)+0;
volatile bit INTF                @ ((unsigned)&INTCON*8)+1;
volatile bit TMR0IF              @ ((unsigned)&INTCON*8)+2;
volatile bit RBIE                @ ((unsigned)&INTCON*8)+3;
volatile bit INTE                @ ((unsigned)&INTCON*8)+4;
volatile bit TMR0IE              @ ((unsigned)&INTCON*8)+5;
volatile bit PEIE                @ ((unsigned)&INTCON*8)+6;
volatile bit GIE                 @ ((unsigned)&INTCON*8)+7;
volatile bit T0IF                @ ((unsigned)&INTCON*8)+2;
volatile bit T0IE                @ ((unsigned)&INTCON*8)+5;
#ifndef _LIB_BUILD
volatile union {
    struct {
        unsigned    RBIF                : 1;
        unsigned    INTF                : 1;
        unsigned    TMR0IF              : 1;
        unsigned    RBIE                : 1;
        unsigned    INTE                : 1;
        unsigned    TMR0IE              : 1;
        unsigned    PEIE                : 1;
        unsigned    GIE                 : 1;
    };
    struct {
        unsigned                        : 2;
        unsigned    T0IF                : 1;
        unsigned    : 2;
        unsigned    T0IE                : 1;
    };
} INTCONbits @ 0x00B;
#endif
...
...
...

---

I am assuming you are using the Hi-Tech PICC Compiler, if you are using another compiler make appropriate changes.

You may also find the following tutorials very helpful:

**broken link removed**

These tutorials cover both baseline and midrange PICs using Assembler and Hi-Tech C Compiler, the PIC16F877A is a midrange device.


Hope the info helps in your endeavors.

 

[romel_emperado]

Hi Romel,

What is the actual purpose of the code snippet?

Is the one second delay within the for loop for display purposes? Is P2 being displayed on LEDs, etc?

yes. It's just being displayed on 8 LEDs connected to P2.

---------- Post added at 00:16 ---------- Previous post was at 00:09 ----------

plz help me i m beginner in pic and MPLab.......in the pic 16f877a i use timer0.....and than i use T0CON (timer0 control). the MPLab complier give the :
Error [192] F:\PIC16F877A\MPLab\test_2.c; 10.1 undefined identifier "T0CON"

plz plz help me.!

Hi fawadbutt,

we have also a discussion here about timer0 of pIC but it's quite longer discussion.. hehe

you may also reffer to this simple code I made before for using timer0.. this is for PIC16f628 but it just almost the same.. just reffer to datasheet of your device for some changes..

#include<pic.h>

__CONFIG(0x3F38); //for Internal oscillator

char count;

void interrupt timer0()
{
	
    
	if(T0IF == 1)
	{
	    T0IF = 0;
	    count++;
		if(count == 15)
		{
			RA2 ^= 1;  //toggle LED
			count = 0;
			
		}
		
	}
	T0IE = 1; //Disables the TMR0 interrupt
}


void main(void)
{

	TMR0 = 0;
	OPTION_REG = 0b0111;  // set prescaler to timer 0 and 1:256 prescaler..
	T0CS = 0;  // timer 0 Internal clock source
	T0IE = 1;  // enable timer 0 interrrupt
	GIE =1;    // Enable global interrupt 
	TRISA2 = 0; //set bit 1 of portB as output.

	while(1);

}

This site also is very nice. you will learn from here..

PIC16F877 Timer Modules tutorials | PIC timer0 tutorial

hope it helps..

 

[bigdogguru]

yes. It's just being displayed on 8 LEDs connected to P2.

Well, it's as good a time as any to start learning/using shadow registers!

When ever you base a calculation or routine on a previously known state (value) of a volatile register, e.g. PORT2, it is good policy to store the last KNOWN state of this volatile register in what is referred to as a "shadow register."

The technique of using shadow registers, prevents unforeseen changes in the state of a volatile register, e.g. PORT2, from corrupting the calculation or routine's outcome.

The unforeseen event, in the case of a PORT on a MCU, maybe a device attached to the PORT bus pulling one or more pins high or low unexpectedly. In the real world, this can be if not a common occurrence, one that happens more often than the system designer would like.


Your Original Routine

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
void shift_right()
{
     char c;
     if(P1 == 0x04)
      {
        P2 = 0xA0;    
        for(c=0; c<3; c++)
        {    
            delay_ms(1000);
            P2 = P2 >> 1;
        }
          
      }  
}

---

Modified Routine Using Shadow Register

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
void main(void)
{
   unsigned char  sP1;     // Shadow Copy of P1
   unsigned char  sP2;     // Shadow Copy of P2
 
 ...
 ...
 ...
 
   void shift_right()
   {
        unsigned char c;
 
        if(sP1 == 0x04)
        {
           sP2 = 0xA0;
           P2 = sP2;
    
           for(c=0; c<3; c++)
           {    
               delay_ms(1000);
               sP2 = sP2 >> 1;
               P2 = sP2;
           }
          
         }  
   }
}

---

If you study the modified code above you will notice that all calculations are based on the value stored in the shadow register, rather than blindly retrieving an unknown value directly from the PORT. The technique helps prevent the PORT from entering an unknown state, e.g. invalid value, which would further corrupt an future calculation or routine's outcome. Only when a new state (value) is obtain is it transferred to the actual PORT and the last known state (value) is retained in the shadow registers for future calculations or routines to utilize in the future.

Hope the mini lesson helps you in the future.

 

[romel_emperado]

The technique of using shadow registers, prevents unforeseen changes in the state of a volatile register, e.g. PORT2, from corrupting the calculation or routine's outcome.

thanks I understand now the importance of shadow register technique..

 

[bigdogguru]

I should also point out the importance of signed and unsigned variable declarations.

You may or may not have noticed that I changed the declaration of variable "c" in your code snippet from char to unsigned char.

The C99 standard leaves the default signness of char up to the compiler. Therefore char could either be signed or unsigned by default depending on the compiler implementation. In the case of your snippet, this is not a problem due to the range of "c" is limited to (0,3). However, if char is signed by default, then "c" range is limited to (-128, 127) and if used in a loop with a iteration count greater than 127, now you have a problem. Debugging these types of issues can be challenging at times, especially for the beginner. Also code portability is now an issue, the snippet may work with Hi-Tech's compiler, but what happens is you transfer the code to a CCS compiler? Who knows?

It's all ways good coding policy to explicitly declare the signness of a variable, if the variable is never intended to contain a negative value, declare it unsigned.

void shift_right()
{
     [COLOR="#FF0000"]char c; // unsigned char c;  A good policy[/COLOR]
     if(P1 == 0x04)
      {
        P2 = 0xA0;    
        for(c=0; c<3; c++)
        {    
            delay_ms(1000);
            P2 = P2 >> 1;
        }
          
      } 
}

 

[romel_emperado]

thanks bigdogguro,

thanks poiting it out again to me. Honestly I read tha data types of section of my compiler few weeks ago and i found it very useful.

By the way, in other instance if i want to save memory unsigned char uses more memory space than signed char right?

---------- Post added at 06:49 ---------- Previous post was at 06:44 ----------

bigdogguru, your very good in explaining things. Hehe thanks.

 

[bigdogguru]

No,

Both an unsigned char and signed char use exactly one byte of storage, this is why the range of an unsigned char is (0,255) and a signed char is (-128, 127), if the most significant bit of the signed byte is set the number is negative.

Discussion on Twos Complement:

Two's Complement

By the way, the compiler's minimum and maximum values for each variable type are listed in the limits.h header file located in the include directory:


Hi-Tech C Compiler for PIC 10/12/16 - limits.h

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/*  Characteristics of integral types */
 
#define CHAR_BIT           8            /* bits per char */
#define CHAR_MAX    127         /* max value of a char */
#define CHAR_MIN    -128            /* min value of a char */
#define SCHAR_MAX   CHAR_MAX        /* chars are signed */
#define SCHAR_MIN   CHAR_MIN
#define UCHAR_MAX   255         /* max value of an unsigned char */
#define SHRT_MAX    32767           /* max value of a short */
#define SHRT_MIN    (int)-32768     /* min value of a short */
#define USHRT_MAX   65535           /* max value of an unsigned short */
#define INT_MAX     32767           /* max value of an int */
#define INT_MIN     (int)-32768     /* min value of an int */
#define UINT_MAX    65535           /* max value of an unsigned int */
#define SHRTLONG_MAX    8388607         /* max value of short long */
#define SHRTLONG_MIN    (short long)-8388608    /* min value of a short long */
#define USHRTLONG_MAX   16777215        /* max value of an unsigned short long */
#define LONG_MAX    2147483647      /* max value of long */
#define LONG_MIN    (long)-2147483648   /* min value of a long */
#define ULONG_MAX   4294967295      /* max value of an unsigned long */

---

And did you notice it this case, the Hi-Tech C Compiler, char is signed by default, range (-128,127). Good to know!

 

[romel_emperado]

HI bigdogguro,

I did an experiment to distinguish the difference of unsigned and signed data types in some instance where you need to specify to declare whether its signed or unsigned in your specific task.. but in the definition it's clearly stated the difference I just wanna experience where I need to specify this things up... hope you understand what I wanna experience or what is in my mind... lol hehe

I dont know how to tell the difference but I will just explain my experience now.. hehe I read the two's complement that is why I bothered to do an experiment..

check this small code:

The initial value to be shifted is in the most significant bit of the port (0x80). The shifting is working well when I declared as unsigned char but if i declared as signed char the previous value of the MSB will not be cleared and the port remains HIGH after the shifting is done even If I always do clearing the port as PORT2 = 0x00;

void main()
{
	//working code
	unsigned char i;
	P2=0x00;

	while(1)
	{
	
		
		delay_ms(1000);
		P2 = 0x00; // to clear the previous value of port
		i=i>>1;
		if(i==0)
		i=0x80;
		P2=P2|i;
		

	
	}
}

void main()
{
	//problematic code. hehe
	signed char i;
	P2=0x00;

	while(1)
	{
	
		
		delay_ms(1000);
		P2 = 0x00;
		i=i>>1;
		if(i==0)
		i=0x80;
		P2=P2|i;
		

	
	}
}

 

[bigdogguru]

Hi Romel,

Reference the Hi-Tech C Compiler User Manual, pg 345, Section A.5.5:

A.5.5 The result of a right shift of a negative-valued signed integral type (6.3.7)

The right shift operator sign extends signed values. Thus an object with the signed int value 0x0124 shifted right one bit will yield the value 0x0092 and the value 0x8024 shifted right one bit will yield the value 0xC012. Right shifts of unsigned integral values always clear the most significant bit of the result. Left shifts (<< operator), signed or unsigned, always clear the least significant bit of the result.

This illustrates another reason to use only unsigned integral types; the variable contents will never have a valid reason to represent a negative value.

Hope this clears things up for you.

 

[romel_emperado]

thanks... I understand now..

I like the way you explain things.. hehe

you have always a reference as a prof.. hehe

by the way did you read all this things up before?

 

[bigdogguru]

you have always a reference as a prof.. hehe

by the way did you read all this things up before?

Yes,

It's wise to read all the datasheets for the devices used in your design and study your compiler or assembler user manual.

You may not remember everything, but you might recall that an issue, when it comes up, was mentioned or discussed in the docs. Also, as you learn and apply recommended guidelines/procedures to programming, such as the one you just learned, you tend to avoid a lot of pitfalls.


Any other challenges, up your sleeve?