leifindr 
I used Codevision around 2006 in a project using ATmega32, don't remember the version I used then. Now, when I try to compile the project in CVAVR 2.60, I get an Error message saying
a value of type 'enum <unnamed>' can't be used to initialize an entity of type "flash unsigned char"
The code line in question is
flash char* flash HeatModeIdle[] = { OFF, ON, AUTOMATIC, H1, H2, H3, H4 };
Any help on this will be highly apreciated!
jgmdesign 
Codevision has a helpdesk. Might want to give them an email. Pavel answers back pretty quick.
Version 2.6 is pretty old. And the code you tried to compile is older than that?
I have Version 3.4 here. OThers on this site might have newer versions. But I am sure one of them can answer your question better than I so I will leave it with them.
I do suggest you reach out to CV directly though..
Jim
leifindr And the code you tried to compile is older than that
I think the compiler used at that time was 1.23.9b Standard. Since it's close to midnight here now (CET) I'll wait until tomorrow morning before I contact Pavel.
Any help on this will be highly apreciated!
What language are you compiling? What "any help" are you expecting to receive if you are not even bothering to say what programming language you are trying to use??? Is it C? Or is it C++?
a value of type 'enum <unnamed>' can't be used to initialize an entity of type "flash unsigned char"
You are making something up. The code you presented declares an array of `char *`. It is `char *` elements you are trying to initialize. Yet the message you quoted talks about `unsigned char`. I can live with that extra `unsigned`, but there's no way the compiler would omit that `*` in the error message.
The code is obviously wrong. You cannot initialize `char *` objects with non-zero integer constants, period. The code has always been wrong. It never compiled properly. It is quite possible that the previous compiler issued a mere "warning" for the same error, which you simply ignored. And the new compiler issues a full-blown error.
leifindr What "any help" are you expecting to receive if you are not even bothering to say what programming language you are trying to use??? Is it C? Or is it C++?
Sorry for my ignorance, I thought Codevision compiler was for C and that it was obvious in this grop. If it offended you I hereby ask for forgiveness. That said, I apreciate the explanation you gave at the end of you message. It is probably the reason for the error code I get on the 2.16 version of CVAVR.
C-coding is not what I do on a daily base, I consider myself more or less as a newbie.
david.prentice I used Codevision around 2006 in a project using ATmega32, don't remember the version I used then. Now, when I try to compile the project in CVAVR 2.60, I get an Error message saying
a value of type 'enum <unnamed>' can't be used to initialize an entity of type "flash unsigned char"
The code line in question is
flash char* flash HeatModeIdle[] = { OFF, ON, AUTOMATIC, H1, H2, H3, H4 };
Any help on this will be highly apreciated!
I think the compiler used at that time was 1.23.9b Standard
Well, v1.23.9b is extremely old. And v2.60 is pretty old too. Current CVAVR is v3.48
There is nothing illegal with your "offending" line. But it is unlikely that you actually want to obey that statement.
Codevision has made significant changes over the years. With a much stricter scrutiny of code syntax.
I think that your best bet is to post the original source code. Then we can attempt to compile with modern CV. And also with v2.60
I guess that this is one legacy project and you don't want to upgrade your Codevision version from v2.60.
David.
C-coding is not what I do on a daily base, I consider myself more or less as a newbie.
Well, while your line of code is illegal from a formal standpoint, it is rather unusual for a typical C compiler to report this is as an error and abort compilation. C compilers traditionally report such errors as a "warnings" and continue to compile the code, unless you request very strict error checking. It is quite possible that in the new version they simply tightened down error checking in the compiler settings. Just a guess.
But in any case, why is this code trying to initialize `char *` pointers with integers? What is the intent? Do you know the answer to this question?
leifindr There is nothing illegal with your "offending" line. But it is unlikely that you actually want to obey that statement.
David, English is not my native tongue. Please bear with me if I use some odd statements. I was only asking for some helpful hints, not the kind og reply I got from AndreyT. Regarding posting of the complete code, I cannot do that since it's not my property and actually runs in a commercial product sold today.
clawson 
Are you SURE this has not identified a bug in the original code? Surely the line:
flash char* flash HeatModeIdle[] = { OFF, ON, AUTOMATIC, H1, H2, H3, H4 };was presumably supposed to have been:
flash char* flash HeatModeIdle[] = { "OFF", "ON", "AUTOMATIC", "H1", "H2", "H3", "H4" };It's not unusual to do this as a debug technique. If you have something like:
typedef enum {
OFF,
ON,
AUTOMATIC,
H!,
H2,
H3,
H4
} state_e;
state_e switch_state();
state_e state;
flash char* flash HeatModeIdle[] = { "OFF", "ON", "AUTOMATIC", "H1", "H2", "H3", "H4" };
void main(void) {
state = switch_state();
printf("New state = %s", HeatModeIdle[state]);
}Where you use the char* array to "visualise" the contents of an enum variable.
But assigning enum states as elements in a char* array can never have been the intended behaviour?!?
And apologies for the abruptness of some previous posts - I guess not everyone was having the happiest of days yesterday ?
Moderator.
david.prentice You can either PM the code to me or compile it with v1.23.9 (or v1.24)
If the original HEX is running in a commercial product you would just run the same HEX in a new device.
However, I suspect that you have the original source code but want to make some changes. Hence you want a new HEX for the new device.
I can make a pretty good guess as to what you want to do and the correct C syntax.
As I said in #6. It is very unlikely that your statement is what you want. v1.23.9 did not check it strictly.
David.
There's still a matter of the error message. How come the error message does not match the code, as I noted above in my curt but ultra-useful answer? Is something misquoted here? And if it is, then what? The code or the error message?
david.prentice The oldest CV that I have is v1.24 from February 2005.
From memory it was a little cavalier with flash, flash pointers etc.
It worked pretty well but was not perfect C.
If it is just a question of generating the original HEX from the original source code you would just use the original CV version. i.e. v1.23.9
Or find the original HEX that was used by the production of your commercial item.
But for any new HEX I would strongly advise using an up to date CV compiler and complying with strict C syntax.
Yes, from memory converting v1.24 code to v2.x.x required care. v1.24 was not standard C
v2.x.x code should work fine on v3.x.x
David.
leifindr You can either PM the code to me or compile it with v1.23.9 (or v1.24)
Just sent the C-source by PM, David. Hope you can figure it out.
theusch 
Just sent the C-source by PM, David. Hope you can figure it out.
I'm also interested. The snippets given so far don't give enough context to point directly. Was it indeed that ON really meant "ON"? I did a LOT of programming with 1.x, and indeed some menu systems and similar needed to be cleaned up when going to 2.x. From early 2.0x rev history:
the compiler now makes distinction between the ‘const’ type qualifier and the ‘flash’ memory
attribute. In order to maintain compatibility with V1.25.x projects, the Project|Configure|C
Compiler|Code Generation|Store Global Constants in FLASH Memory must be checked. If this
option is not checked, identifiers declared with the ‘const’ type qualifier will be placed in RAM
Maybe I never tried the hinted "shortcut". Why don't you cut it down to a complete test program that demonstrates the symptoms? Then we can all play along with the home game.
N.B. The version I kept to make tweaks to historical code was 1.25.9a. I do not remember if that was the last 1.x and there is no posted rev history for 1.x that I can see.
leifindr Was it indeed that ON really meant "ON"?
OFF, ON etc. are just enumerated constants,
enum { HEATER_PROGRAM,
USERS,
AUTOMATIC,
H1,
H2,
H3,
H4,
ON,
OFF,
EOF
};
I will PM you the code, theusch.
I will PM you the code, theusch.
The purpose of a public forum is to a large degree (of even larger degree) to help other people who might encounter the problem in the future. For which reason solutions based on "PMing" some invisible code around are of little value here. You don't have to dump your entire code into the forum, but as other have already noted above, it should be simple to craft a small artificial example triggering the same error message.
OFF, ON etc. are just enumerated constants,
enum { HEATER_PROGRAM,
USERS,
AUTOMATIC,
H1,
H2,
H3,
H4,
ON,
OFF,
EOF
};
Then I'm on the side of CodeVision. It's an error.
const flash char HeatModeIdle[] = { OFF, ON, AUTOMATIC, H1, H2, H3, H4 };Would make more sense to me.
<edit> Having had 2nd thoughts about this (nothing more than a convoluted cast would make this code OK) perhaps this shouldn't be an error; instead a severe reprimand should be administered.