 |
 |
| View previous topic :: View next topic |
| Author |
Message |
paul
Guest
|
| compiler 4.008 and data |
 Posted: Fri Sep 08, 2006 9:35 am |
 |
|
Hello,
I have used with alll previous version of CCS compiler data table for
CRC ( in PIC16F876) coded as
const char Table_CRC_Hi[256]={
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,..............
}
they worked fine, now upgrading to 4.008 I'have got the error
message "data item too big", i used also an org direttive but we no success...
someone may help? it seems to be a bug in the compiler..
thanks in advance |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Sep 08, 2006 1:01 pm |
|
|
I don't have the PCM compiler for 4.008 (didn't renew my maintenance)
but I do have PCH for that version. I made a test program and it
compiles without error. Try compiling the program below for the 16F876:
| Code: |
#include <18F452.h>
#fuses XT,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
int8 const array[] =
{
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,
0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,
0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,
0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x1E,0x1F,
0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,
0x28,0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,
0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,
0x38,0x39,0x3A,0x3B,0x3C,0x3D,0x3E,0x3F,
0x40,0x41,0x42,0x43,0x44,0x45,0x46,0x47,
0x48,0x49,0x4A,0x4B,0x4C,0x4D,0x4E,0x4F,
0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,
0x58,0x59,0x5A,0x5B,0x5C,0x5D,0x5E,0x5F,
0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,
0x68,0x69,0x6A,0x6B,0x6C,0x6D,0x6E,0x6F,
0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x77,
0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,
0x88,0x89,0x8A,0x8B,0x8C,0x8D,0x8E,0x8F,
0x90,0x91,0x92,0x93,0x94,0x95,0x96,0x97,
0x98,0x99,0x9A,0x9B,0x9C,0x9D,0x9E,0x9F,
0xA0,0xA1,0xA2,0xA3,0xA4,0xA5,0xA6,0xA7,
0xA8,0xA9,0xAA,0xAB,0xAC,0xAD,0xAE,0xAF,
0xB0,0xB1,0xB2,0xB3,0xB4,0xB5,0xB6,0xB7,
0xB8,0xB9,0xBA,0xBB,0xBC,0xBD,0xBE,0xBF,
0xC0,0xC1,0xC2,0xC3,0xC4,0xC5,0xC6,0xC7,
0xC8,0xC9,0xCA,0xCB,0xCC,0xCD,0xCE,0xCF,
0xD0,0xD1,0xD2,0xD3,0xD4,0xD5,0xD6,0xD7,
0xD8,0xD9,0xDA,0xDB,0xDC,0xDD,0xDE,0xDF,
0xE0,0xE1,0xE2,0xE3,0xE4,0xE5,0xE6,0xE7,
0xE8,0xE9,0xEA,0xEB,0xEC,0xED,0xEE,0xEF,
0xF0,0xF1,0xF2,0xF3,0xF4,0xF5,0xF6,0xF7,
0xF8,0xF9,0xFA,0xFB,0xFC,0xFD,0xFE,0xFF
};
//====================================
void main()
{
int8 i;
int8 c;
c = array[i];
while(1);
} |
|
|
|
Ttelmah
Guest
|
|
| Posted: Fri Sep 08, 2006 2:30 pm |
|
|
I was going to make the comment 'what do you expect', since the bug level with the V4 compilers is still 'off scale', but in fact PCM's demo program compiles fine for me, modified to use a 16F876, using compiler 4.008.
In fact it generates the identical list file, to 3.249.
It _fails_ if you define the array size, in V4.008, but is accepted in 3.249 with this.
I think the 'key' here is that 4.008, is doing extra error checking, and 'knows' that an int8 (maximum allowable index for a const, in the 16 chips), cannot 'hold' the value 256, so incorrectly complains (since an int8, _can_ address 256 values, using 0...255.
I have proved this hypothesis, by recompiling for the 18F452, where inserting '256', also fails, but putting '256L' (with the 18 chips,you can have more than 256 elements), it compiles OK...
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
