This is a funny compiler

[slavka012]

It works ok for most basic language syntax, but try anything slightly more complex and... have fun understanding why your code does not work.

[ELCouz]

What's your compiler version?

v3, v4 or v5?

v4.134 is the most stable now IMO.

[slavka012]

V 5.026

[slavka012]

Hitech is now Microchip. I'm trying XC now.

[ELCouz]

[PCM programmer]

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:

[Ttelmah]

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.

[temtronic]

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

[slavka012]

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.

[Ttelmah]

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.

[Eugeneo]

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.

[slavka012]

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!

[temtronic]

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

[Ttelmah]

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).