![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
slavka012
Joined: 10 Feb 2012 Posts: 28
|
This is a funny compiler |
Posted: Tue Dec 30, 2014 10:16 am |
|
|
It works ok for most basic language syntax, but try anything slightly more complex and... have fun understanding why your code does not work.
Code: |
struct bat_rec{
uint8 adc_channels[4];
uint8 balancer_ports[4];
};
const struct bat_rec Bat1Record = {{5,6,7,8},{1,2,3,4}};
const struct bat_rec Bat2Record = {{9,10,11,13},{1,2,3,4}};
void ProcessBattery(struct bat_rec* BatteryRecord ) {
for (int i = 0; i < 4; i++) {
printf("Port: %d ", BatteryRecord->adc_channels[i]);
};
}
|
Now if I call ProcessBattery(&Bat1Record) I'm getting this:
Port 0
Port 72
Port 0
Port 2
This compiler can't be trusted, I'm switching to something else. I'm sick and tired of finding such little bugs, working around them and trying to remember not to step on the same landmine again. |
|
![](templates/subSilver/images/spacer.gif) |
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Tue Dec 30, 2014 11:19 am |
|
|
What's your compiler version?
v3, v4 or v5?
v4.134 is the most stable now IMO.
slavka012 wrote: |
This compiler can't be trusted, I'm switching to something else. I'm sick and tired of finding such little bugs, working around them and trying to remember not to step on the same landmine again. |
Good luck with HiTech with their yearly IDE updates ![Wink](images/smiles/icon_wink.gif) _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
![](templates/subSilver/images/spacer.gif) |
slavka012
Joined: 10 Feb 2012 Posts: 28
|
|
Posted: Tue Dec 30, 2014 11:24 am |
|
|
V 5.026 |
|
![](templates/subSilver/images/spacer.gif) |
slavka012
Joined: 10 Feb 2012 Posts: 28
|
|
Posted: Tue Dec 30, 2014 11:25 am |
|
|
Hitech is now Microchip. I'm trying XC now. |
|
![](templates/subSilver/images/spacer.gif) |
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Tue Dec 30, 2014 11:34 am |
|
|
slavka012 wrote: | Hitech is now Microchip. I'm trying XC now. |
MPLAB XC8 PRO Compiler $995.00 (per single license) reasonable but out of budget for a lot of people here. _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Dec 30, 2014 11:39 am |
|
|
It's not working because of the 'const' in the structure declarations.
In CCS, 'const' puts the values in Flash memory instead of RAM.
To make the compiler treat 'const' in the normal way (meaning: read-only),
add the following #device statement:
Quote: | #include <18F4520.h>
#device CONST=READ_ONLY
#fuses INTRC_IO, BROWNOUT, PUT, NOWDT
#use delay(clock=4M)
#use rs232(baud=9600, UART1, ERRORS)
|
It's possible that your code could be made to work as is (with the structs
in Flash). If no one else has a solution, I'll look at it later. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Tue Dec 30, 2014 11:59 am |
|
|
It might well work if the pointer was declared as a pointer to a constant. As it stands, it's using the ROM address of the structure as a RAM address....
It's the two separate memory spaces problem. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Tue Dec 30, 2014 12:05 pm |
|
|
For almost 2 decades, I've been impressed with what CCS has created to use on a chip that originally had 35 instructions! I am NOT a C programmer, nor will ever be 'efficient' in it but am amazed what others have coded.
As for 'landmines', who amongst us hasn't seen the dreaded 'blue screen of death' on a PC?
Given the price/features ratio CCS has a great product, tons of examples, decent manual and this forum. As you quickly found out, people here are willing to help out if they can, even supplying code snippets, patches or knowledge as to how to accomplish the task.
jay |
|
![](templates/subSilver/images/spacer.gif) |
slavka012
Joined: 10 Feb 2012 Posts: 28
|
|
Posted: Tue Dec 30, 2014 12:30 pm |
|
|
Well ok, I'm passing a pointer to const to a function that accepts non-const pointer. This should be a compile time error. It works correctly if I remove const. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Tue Dec 30, 2014 3:39 pm |
|
|
Key here is to understand C.
C has no inherent type checking. Types will be cast as necessary to convert them in use. It allows you (for instance) to declare an integer, and then use this as a pointer etc. etc..
It is perfectly legitimate (for example) to take the number that is the address of a value in memory, then use this to address something else in external EEPROM.
This is effectively what you are doing.
If you switched to running in 'ANSI' mode, then the 'const' keyword would lose it's "I am a constant in ROM" meaning, and instead would just mean a RAM based variable that is designed to not be written (though since there is no hardware address protection, the actual protection is limited).
The reason the old CCS meaning of 'const' is by default retained, is multi-fold. First since it pre-dates the ANSI usage, and secondly since it is very useful on chips with very limited RAM, allowing genuinely 'constant' data to be fully stored in ROM, saving RAM. However with that ability comes the limitation that this data is in a completely separate address space to the RAM. This is the architecture of the PIC, where to give relatively high speed, without the need for a cache, there are two separate memory spaces being addressed at the same time. Address 0 for instance appears once in the ROM, and a second time in the RAM. |
|
![](templates/subSilver/images/spacer.gif) |
Eugeneo
Joined: 30 Aug 2005 Posts: 155 Location: Calgary, AB
|
|
Posted: Tue Dec 30, 2014 8:41 pm |
|
|
This may sound strange, but thinking it's a compiler issue (which is it NOT most of the time) has led me to investigate the assembly listing in detail. This has made me a more proficient at understanding the pic architecture and especially optimizing my code.
My 2 cents worth. |
|
![](templates/subSilver/images/spacer.gif) |
slavka012
Joined: 10 Feb 2012 Posts: 28
|
|
Posted: Wed Dec 31, 2014 1:24 pm |
|
|
I'm fine with const objects being in ROM. It is a good thing. Does not matter though. If we even have "const" in language, it should be supported and efforts should be made to prevent const obects being treated as non-const. In this case compiler ignores assignment of const to non-const, which should be a compile time error.
C is not a static thing, it evolves. Modern standards treat const properly. We don't need to live with first K&R edition in 2014. So I don't see how you can defend the compiler here.
Happy new year, everyone! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Wed Dec 31, 2014 1:52 pm |
|
|
While C is not a static thing , 'constants' are, at least they should be! Having a 'constant' in RAM can be foolhardy as nothing prevents corruption,say from an EMI glitch. Had that happen, amazing how fast a 200W servo can go 'out of control' and destroy $20,000 of materials.
You need to understand the guts of the PIC( the hardware) to appreciate how CCS C has been coded. From it's humble beginnings 20 years ago, CCS has expanded to try to catch up to the near daily evolution on PICs.
While it might not follow the 'standard' of today, it does allow YOU to easily create functions to 'have it your way'.
CCS C is NOT ANSI C or K&R C though a lot of it is similar. I'm NOT a C coder,just a user for 20 years who has always been impressed with the CCS compiled code.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Wed Dec 31, 2014 3:55 pm |
|
|
The other important balancing act, is size.
The key thing is that the PIC is very unusual in using Harvard architecture. The RAM and ROM are completely separate.
Now it is possible to have pointers that could access both spaces, but doing so, makes them larger. By default CCS elect to keep the two memory spaces separate, and limit the size of pointers to just the RAM space. Makes for smaller and faster code, and smaller pointers. The compiler though also allows you to have pointers to the constant data (this is what the 'pass strings in RAM' command does, it temporarily copies ROM data into RAM for use), or you can use the 'rom' keyword, instead of 'const', which then allows pointers to be constructed (though at a cost in code size terms).
It is a distinct difference in the hardware architecture of the PIC's, and CCS allows you to decide whether small size and speed is more important, or pointers to ROM. It just happens that the default method in the compiler mode you have selected, keeps the memory spaces separate. If you want them treated as one space, just use the #ANSI declaration for the compiler. Not exactly hard....
Having the options selectable allows you to choose which route you want. The default is to keep to the hardware architecture of the chip (this is also the default, because quite a lot of the smaller chips physically do not allow indirect addressing of the ROM). |
|
![](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
|