Anything wrong with $99 CCS pic C compiler?

[thaque]

A few things about this compiler is driving me crazy.
1) A program with just a serial port and a PWM turns out to be 4KB long????
2) I add one increment command, such as , variable++, the number of bytes jumps up by 200 bytes.
3) In many situations, I cannt download the hex codes into my PIC16F877. For example, if i use printf command with %c format, but works with %X.

Any one knows what's going on here?
TH

[PCM programmer]

I think you are using floating point.

Solution: Don't do that. Use integers.

[thaque]

No, that's not it. No floating point here. A simple program, writing and reading back a single byte into an external eeprom (2464), when compiled with PIC C, the hex file becomes 4K byte long. Is this normal? I use +O8 +Y9 compiler options. Will any other setup reduce the size? I think PIC16F877 has only 8K flash. What should i do? look for another compiler?
TH

[dyeatman]

It would appear something is wrong with what you are doing. I have written DOZENS of programs for the 16F876/866 and have not seen any of the kind of thing you are describing.

What version of compiler are you using? Is it the demo?

Post the program you are using so we might be able to spot any problems..

[thaque]

No, its not evaluation version. I bought it for $99. Here are the codes. Dont worry about whether it does anything meaningful. I have 2 include files, "16f877.h" and "2464.c" , where all the eeprom functions are. When compiled, its size becomes around 4K. Other problem that's bothering me is the line "write_ext_eeprom(address+i,msg[i]);". When I use '+i' to increment the address, the size jumps up by 200 bytes than when I dont use.
Thanks.

init_ext_eeprom();
output_high(PIN_C0);
address = 0x10;
do
{
printf("\r\nRead or Write: ");
cmd=getc();
putc(cmd);

if(cmd=='W')
{
for(i=0;i<5;i++)
{
write_ext_eeprom(address+i,msg[i]);
}
}
if(cmd=='R')
{
value=read_ext_eeprom(address);
printf("\r\n %X",value);
}
} while ( (cmd=='R') || (cmd=='W') );

[PCM programmer]

Below, I've posted a test program based upon your posted code.
When compiled with PCM vs. 3.214, the Hex file is 2767 bytes.
The actual ROM usage, as shown at the top of the .LST file, is not much:

[Guest]

Thanks a lot guys for your responses. I'm using CCS PCM C compiler version 3.077. You are right. I should've looked at LST file sooner. My list file says, ROM used 602 bytes, RAM used 20 bytes. But my hex file size is 3340 bytes. This raises more questions.
1) Where do the remaining 2738 bytes go? what are they used for? for programmer? but I use a third party programmer. This extra 2738 bytes are sent to my programmer for absolutely no reason.
2) I compile my program inside MPLAB. Can I compile outside MPLAB? will that help?
3) The list file also generates Assembly codes. If I piece them togethter, can I use the Assembler to make the hex file? My programmer is writen for Hex codes generated by assembler, not C compiler. Does this matter? I had no trouble before when I used assembler. For programming convenience i'm trying move to C.

Please one more response will be enough for me. Thanks again.
TH

[PCM programmer]

I can test it with vs. 3.077 on Monday and give you an answer
about the Hex file size then.

[dyeatman]

I did a Google search and found a link in a forum about DsPIC that should cover your issues about the Intel hex file size. I am including the link below:

http://forum.microchip.com/tm.asp?m=61920


BTW I searched on "hex file format" to find the link....

regards,

[drh]

The .HEX file contains address and record type information. It will always be larger than ROM size. If you search the internet for "Intel Hex File", you will find more info.
Here is one example www.cs.net/lucid/intel.htm
_________________
David

[John P]

Are you just looking at the size of the .HEX file as reported by your computer, in bytes? It's not a very useful guide because:

Intel hex format needs 2 bytes to store one byte of code data, and 4 bytes to store a single 14-bit data word for this type of processor.

The file encodes data in text lines, and although there are only 8 data words per line, each line starts with a colon (one character), a number of bytes (encoded as 2 characters) an address (4 characters) a code (2 characters) then the data (8 * 4 characters, if it's a full line) and a checksum (2 characters) and then a linefeed. Written down without going to check, so I may have got it wrong! But anyway, the hex file isn't efficient on space, but you aren't supposed to care. So stop caring.

[thaque]

PCM Programmer, no thanks, you donot have to try with version 3.077. I think I got a better picture of my problem after discussing with you all. Yes, i am aware of Intel Hex file format. But one explanation doesn't seem right. There are 6 bytes of start, number, address, type, and checksum, in one line of intel format. But one line also includes 16 bytes of data. Therefore, the number of data bytes will always be higher than extra bytes. As opposed to one explanation. Just a thought. Thanks to you all.
TH

[PCM programmer]

Alright, I'll skip the 3.077 test. With regard to your other questions:

[John P]

The need for arguing about the topic may no longer exist, but this is very misleading: "one line [of the hex file] also includes 16 bytes of data..."

Yes, it's true that there are 16 data bytes in most lines (but if there aren't that many, all the overhead still exists). However, each text character in the hex file encodes only 4 bits, and the '877 processor uses a 14 bit data word. Each word (WORD, not BYTE) is therefore stored as 2 bytes, and each byte is broken down to 2 characters. Because of the 14-versus-16-bit mismatch, the top 2 bits of the character containing the highest-order 4 bits will always be 0, and that character will therefore always be 0, 1, 2 or 3. To make things even more fun, the two characters that encode a byte are written with the high-order character at the left, just as numbers are normally written, but the BYTE containing the highest-order data in a WORD is written at the right, because the file is "Intel little-endian" in format. Programming a computer to read a hex file isn't too difficult, but trying to do it yourself will have you screaming quite quickly.