Variables overlap with PCD 4.092

[Andre]

I'm using a CCS PCD 4.092 with a dsPIC33FJ256GP710.

When I call a function, the parameter variable in the called function will overlap one local variable in calling function.

Ex,

[Ttelmah]

The reason here, is that CCS, will try to re-use memory space, if a function has finished with it.
Your first function, has a void return type. CCS, does not support the 'late typed' style of void, from ANSI, but treats void as null. Therefore the compiler sees the function, as having no further use for the varable, and re-uses the space. Change the do_check_temperature declaration to int16, and the overlap should disappear.
However also study how many problems there are with the DSPIC's and CCS at present.....

Best Wishes

[Aneben]

Hi there,

Sorry, the code wasn't correct.
Consider this instead:

[FvM]

[Ttelmah]

What is posted, is again perfectly reasonable action.
The optimiser looks at what you are doing.
The 'temp_ok' variable, is only ever read, and in current 'C' useage, corresponds to the bottom bit of the value being passed (historically, C in the past, did a conversion from a int16, to a bit, by perfroming a logic test on the whole variable, but current - ANSI compatible _ conversion, is done by simply testing the bottom bit). Since the bit is never written, the compiler just makes the local variable map to the same place as the bottom bit of the source variable.
The optimiser is trying to minimise data movement, that is not needed.

Best Wishes

[Guest]

Thanks for trying to help.

It seems like my examples aren't the best.

Consider this:

[FvM]

I tried to achieve a similar behaviour, but I didn't succed in overlaying do_check_temperature.value or another variable, that has to be persistent during set_module_temp_ok() execution with set_module_temp_ok.temp_ok. I also used PCD V4.092. I guess, there must be something special in your application, not visable from the shown code, a setting different from compiler default (e.g. in optimization level) or another special condition. Have you tried, to extract a minimal example from your code, that reproduces the problem?

It may be the case, that you can't reproduce it after removing part of your application, but then you possibly get insights in the conditions that are necessary to generate it.

[Guest]

Okey, thanks for your time.

I'll try that later.