Hi all,
referring to my post "Compiling Error of AVR-V4 FlowCode files in V5" (http://wwww.matrixmultimedia.com/mmforu ... 46&t=10928)
ther came up a quite worse problem:
FC seems to have limtations for the length of internal variables (I think it's about 20 characters, afaik not documented). Please tell me, if I'm wrong!
If you exceed this size, the compiler isn't able to recognize the variable itself and shows a lot of unspecific erros.
The automatic conversion of the syntax of internal variables names from FC4 to FC5, by adding the macro name to the variables name, now crashes the whole file!!
Here is an example:
void FCM_ISR_TachoDir_IN()
{
//Local variable definitions
MX_UINT8 FCL_ISR_TACHODIR_IN_I;
MX_FLOAT FCL_ISR_TACHODIR_IN_TACHOREALTEMP;
}
As you see FCL_TACHOREALTEMP (FC4 variable, without the macro name included: length=13 char) changes to FCL_ISR_TACHODIR_IN_TACHOREALTEMP (new FC5 variable, with macro name included: length=28 char)
This couldn't be corrected by a user that easy, as you have the internal limitations on the length of the variables names, and I'm really not able to work the whole big code of my complete projects over and find short names for macros and variables that match the length restriction.
I really hope there is a way to make a fix for this.
And I'd really appreciate any feedback from matrix, as I'm not able to use FC5 at the moment, working this way.
Many thanks,
Niro
Worse Compiling Problem after variable conversion V4 -> V5
Moderator: Benj
- JonnyW
- Posts: 1230
- Joined: Fri Oct 29, 2010 9:13 am
- Location: Matrix Multimedia Ltd
- Has thanked: 63 times
- Been thanked: 290 times
- Contact:
Re: Worse Compiling Problem after variable conversion V4 ->
Hello.
This will be fixed in the upcoming release (v5.4).
The reason this was added was the introduction of constants in v5 which use C #defines. These are not localized to a macro so we needed a way to make sure they would not clash between macros. I have implemented an alternative method in v5.4 which should hopefully fix this issue.
The update will most likely be released at the end of this week.
Jonny
This will be fixed in the upcoming release (v5.4).
The reason this was added was the introduction of constants in v5 which use C #defines. These are not localized to a macro so we needed a way to make sure they would not clash between macros. I have implemented an alternative method in v5.4 which should hopefully fix this issue.
The update will most likely be released at the end of this week.
Jonny
- Steve
- Matrix Staff
- Posts: 3433
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
Re: Worse Compiling Problem after variable conversion V4 ->
I've just tried to replicate this issue in V5.3 of Flowcode for AVR and I have a local variable which is 65 characters in length and there is no problem.
Can you please post your program and we'll have a look here becasue it looks like there is no limit on the variable length.
Can you please post your program and we'll have a look here becasue it looks like there is no limit on the variable length.
- Steve
- Matrix Staff
- Posts: 3433
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
Re: Worse Compiling Problem after variable conversion V4 ->
Hi Niro,
Thanks for providing a sample file (via PM).
The issue with the PORTWIDTH being set wrong (you mentioned this in another topic) is, I believe, because you are using a customised FCD file (one modified for an SMD package). Because I did not have this FCD file, I imported your program so it used a standard Flowcode target and I did not receive these errors.
As for the multiple errors listed in this post, it looks like the issue is not the length of the variable name. All of the problems are in 9 C code icons where you are referencing local variables. These have changed (the macro name is also added to the name), but this will also change again back to how it worked in V4. The icons with errors are presented in the "icon lists" window in the "error results" tab.
You could use the search and replace feature that's new in Flowcode V5. But note that you'll probably need to change them back again when V5.4 of the AVR variant is released. A better solution would be to avoid C code where possible and let Flowcode produce the appropriate code - this will make it much more portable between Flowcode versions, different compilers, and different chip families.
I've looked at all of these C code icons and it seems like they could all be replaced by standard Flowcode input and calculation icons. Doing this means Flowcode will always use the correct variable name. I strongly recommend that you change these C icons to standard Flowcode icons.
The only problematic C icon is one where there are many "if (RXIDX==1) {myvar=5; mystring="blahblah"; var2=var1} else..." statements. This can be done using the "switch" icon in Flowcode, but will take maybe an hour to rewrite.
If you need any specific help or advice with making this change, we'll be happy to help.
Regards,
Steve.
Thanks for providing a sample file (via PM).
The issue with the PORTWIDTH being set wrong (you mentioned this in another topic) is, I believe, because you are using a customised FCD file (one modified for an SMD package). Because I did not have this FCD file, I imported your program so it used a standard Flowcode target and I did not receive these errors.
As for the multiple errors listed in this post, it looks like the issue is not the length of the variable name. All of the problems are in 9 C code icons where you are referencing local variables. These have changed (the macro name is also added to the name), but this will also change again back to how it worked in V4. The icons with errors are presented in the "icon lists" window in the "error results" tab.
You could use the search and replace feature that's new in Flowcode V5. But note that you'll probably need to change them back again when V5.4 of the AVR variant is released. A better solution would be to avoid C code where possible and let Flowcode produce the appropriate code - this will make it much more portable between Flowcode versions, different compilers, and different chip families.
I've looked at all of these C code icons and it seems like they could all be replaced by standard Flowcode input and calculation icons. Doing this means Flowcode will always use the correct variable name. I strongly recommend that you change these C icons to standard Flowcode icons.
The only problematic C icon is one where there are many "if (RXIDX==1) {myvar=5; mystring="blahblah"; var2=var1} else..." statements. This can be done using the "switch" icon in Flowcode, but will take maybe an hour to rewrite.
If you need any specific help or advice with making this change, we'll be happy to help.
Regards,
Steve.
Re: Worse Compiling Problem after variable conversion V4 ->
Dear Steve,
many thanks for your support!
Yes you are right, I'm using a customised FCD File for the ATMEGA328 with QFP package, because this one has 2 additional AD-Ports compared to the "normal" ATMEGA328. I simply took the original ATMEGA328.fcd file, added the 2 missing pins and changed the pin names and ports, according to the ATMEL specification. I'm working at this software for about 2 years and the hardware with the QFP chip works quite fine.
Attached you will find my ATMEGA328_QFP.FCD file. Maybe you could have a look at it and tell me, if I made something wrong or something is missing.
As I wasn't able to find any documentation about FCD-files, maybe you you have some useful information about the structure, that helps avoiding errors building own FCDs.
According to my c-code, I'm hopeing to avoid most of this, using FC5, as there are really many improvements e.g. for data types.
As of course you can't totally avoid c-code, as for the example you took .."if (RXIDX==1) {myvar=5; mystring="blahblah"; var2=var1} else..." , these lines are produced automatically by an EXCEL-file which contains the complete definitions of a memory map. I'm using this to access or modifiy programm variables or EE via rs232, what is a truly complicated and difficult procedure (the rs232 communication was missing in the test file I provided to you).
If there is a more easy way, I would really appreciate any information.
Now I'm really looking forward to the new release!
Best regards,
Niro
many thanks for your support!
Yes you are right, I'm using a customised FCD File for the ATMEGA328 with QFP package, because this one has 2 additional AD-Ports compared to the "normal" ATMEGA328. I simply took the original ATMEGA328.fcd file, added the 2 missing pins and changed the pin names and ports, according to the ATMEL specification. I'm working at this software for about 2 years and the hardware with the QFP chip works quite fine.
Attached you will find my ATMEGA328_QFP.FCD file. Maybe you could have a look at it and tell me, if I made something wrong or something is missing.
As I wasn't able to find any documentation about FCD-files, maybe you you have some useful information about the structure, that helps avoiding errors building own FCDs.
According to my c-code, I'm hopeing to avoid most of this, using FC5, as there are really many improvements e.g. for data types.
As of course you can't totally avoid c-code, as for the example you took .."if (RXIDX==1) {myvar=5; mystring="blahblah"; var2=var1} else..." , these lines are produced automatically by an EXCEL-file which contains the complete definitions of a memory map. I'm using this to access or modifiy programm variables or EE via rs232, what is a truly complicated and difficult procedure (the rs232 communication was missing in the test file I provided to you).
If there is a more easy way, I would really appreciate any information.
Now I'm really looking forward to the new release!
Best regards,
Niro
- Attachments
-
- ATMEGA328_QFP.fcd
- (6.79 KiB) Downloaded 279 times
- Steve
- Matrix Staff
- Posts: 3433
- Joined: Tue Jan 03, 2006 3:59 pm
- Has thanked: 114 times
- Been thanked: 422 times
Re: Worse Compiling Problem after variable conversion V4 ->
Hi Niro,
Attached is a quick attempt to fix your FCD. Basically, I compared your old one with the V4 original and then made the appropriate edits to the equivalent V5 file.
Another major advantage in avoiding C code blocks (which I forgot to say earlier) is that we cannot simulate the C code itself. So if you want to test your program before downloading to a chip, then avoid C code.
For that large C code block, you could instead use the Flowcode "switch" icon (not the "switch component!). But you cannot simply add it in by copying the Excel file result.
If I remember correctly, your C code looks something like this:
The switch icon is limited to 10 choices, so you would need to do this in multiple stages (i.e. you would need another switch icon on the else branch of the first one). But the code that sets the variables could be put into one calculation icon in each branch of the switch.
I hope this helps.
Attached is a quick attempt to fix your FCD. Basically, I compared your old one with the V4 original and then made the appropriate edits to the equivalent V5 file.
Another major advantage in avoiding C code blocks (which I forgot to say earlier) is that we cannot simulate the C code itself. So if you want to test your program before downloading to a chip, then avoid C code.
For that large C code block, you could instead use the Flowcode "switch" icon (not the "switch component!). But you cannot simply add it in by copying the Excel file result.
If I remember correctly, your C code looks something like this:
Code: Select all
if (x==1) {var1 = 5; var2 = var3; strcpy(str1, "text1"); var4 = 9} else
if (x==3) {var1 = 15; var2 = var5; strcpy(str1, "text2"); var4 = 19} else
if (x==4) {var1 = 22; var2 = var7; strcpy(str1, "text3"); var4 = 29} else
if (x==5) {var1 = 25; var2 = var9; strcpy(str1, "text4"); var4 = 53} else
if (x==10) {var1 = 23; var2 = var0; strcpy(str1, "text5"); var4 = 6} else
...etc...
I hope this helps.
- Attachments
-
- ATMEGA328_QFP.fcd
- (9.83 KiB) Downloaded 281 times
Re: Worse Compiling Problem after variable conversion V4 ->
Dear Steve,
with the new FCD-file FC5 opens without errors. Many Thanks!!
The complete code I'll check with FC5, when the new release is out and keep you informed.
Best regards,
Niro
with the new FCD-file FC5 opens without errors. Many Thanks!!
The complete code I'll check with FC5, when the new release is out and keep you informed.
Best regards,
Niro