![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
thaque Guest
|
Anything wrong with $99 CCS pic C compiler? |
Posted: Sat Jan 01, 2005 3:04 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Jan 01, 2005 3:42 pm |
|
|
I think you are using floating point.
Solution: Don't do that. Use integers. |
|
![](templates/subSilver/images/spacer.gif) |
thaque Guest
|
Anything wrong with $99 CCS pic C compiler |
Posted: Sat Jan 01, 2005 9:24 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
Please provide additional info |
Posted: Sat Jan 01, 2005 9:35 pm |
|
|
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.. |
|
![](templates/subSilver/images/spacer.gif) |
thaque Guest
|
Anything wrong with $99 CCS pic C compiler |
Posted: Sat Jan 01, 2005 11:02 pm |
|
|
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') ); |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Jan 02, 2005 2:51 am |
|
|
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:
Code: | ROM used: 483 words (6%) |
If the "+i" is removed in the write_ext_eeprom() line below,
the ROM usage goes down to 478 words. I don't see the
huge code size or the huge changes that you're reporting.
Code: | #include <16F877.h>
#fuses XT, NOWDT, PUT, BROWNOUT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
#include <24256.c>
void main()
{
int16 address;
int8 cmd;
int8 i;
int8 msg[20];
int8 value;
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') );
} |
|
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
Anything wrong with $99 CCS pic C compiler |
Posted: Sun Jan 02, 2005 9:34 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Jan 02, 2005 12:38 pm |
|
|
I can test it with vs. 3.077 on Monday and give you an answer
about the Hex file size then. |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
Posted: Sun Jan 02, 2005 1:05 pm |
|
|
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, |
|
![](templates/subSilver/images/spacer.gif) |
drh
Joined: 12 Jul 2004 Posts: 192 Location: Hemet, California USA
|
|
Posted: Sun Jan 02, 2005 1:14 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Sun Jan 02, 2005 1:53 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
thaque Guest
|
Anything wrong with $99 CCS pic C compiler |
Posted: Sun Jan 02, 2005 2:22 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Jan 02, 2005 2:46 pm |
|
|
Alright, I'll skip the 3.077 test. With regard to your other questions:
Quote: | 2) I compile my program inside MPLAB. Can I compile outside MPLAB? will that help? |
No, it won't help. Use MPLAB.
Quote: | 3) The list file also generates Assembly codes. If I piece them
together, can I use the Assembler to make the hex file? |
I suppose, but there's no point in doing this.
Quote: | 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. |
It will almost certainly work with Hex files generated by a compiler.
The only possible problem would be if your programmer doesn't like
the comment that CCS puts at the end of its Hex files. ie:
Most modern programmers don't complain about this. |
|
![](templates/subSilver/images/spacer.gif) |
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Tue Jan 04, 2005 3:38 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|