We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
this project has 3 functions (a, b nad c) function g, when running (which will be twice a year) makes function a TOTALLY inactive.
In this memory starved world we '51ers live in I am sharing some global (please it has to be - need no comments on that subject) between functions a and c snce they never will run concurrently and the program is reset after the run of function c (no it is not a bootloader, but the problem would be the same).
I am not asking for a discussion of the relative merits of my current method and do thus not list it.
Obviously, to keep it sane, there need to be a dual name of the variables involved.
So, I solicit your ideas and look forward to seein them.
Erik
XDATA variables I have the definition in an asm module and them as externs in the main .h file.
And by doing that, you're violating all kinds of assumptions built into the C programming language about what a "variable" actually is, and how it works.
You're doing something that is strictly impossible in actual C, so there's no reason for the C compiler to suspect such things would happen. So it won't be prepared for them. As long as you really don't ever mix usage of those variables, you'll probably be OK. But it does put you in "warranty void if seal broken" territory.
Unions or #defines are preferrable over asm hacks or linker tricks for exactly this reasion: they work inside the language, so the compiler knows about them.
When I'm in need of larger amounts of data for short-term use (and can't/won't use dynamic memory) I normally either uses unions or defines a large char array as a one-block heap.
The function that needs access to the memory may then allocate the right to use the block/individual union for a short while before releasing the access lock.
Other parts of the program that has a need for the memory has to poll or busy-wait for it to be available.
Unions or #defines are preferrable over asm hacks or linker tricks for exactly this reasion: they work inside the language, so the compiler knows about them. this can, for all practical purposes, be described as two different programs never running at the same time. Thus there is no 'danger'
You're doing something that is strictly impossible in actual C, so there's no reason for the C compiler to suspect such things would happen. So it won't be prepared for them how is using a union going to avoid an accidental overwrite?. Anyhow since it IS, elsewhere as well, mixed asm and C what is wrong with using the assembler to align xdata? except 'purity' of course. by the way happens to 'purity' once a few modules are written in assembler?
Anyhow, as already posted, I solicit alternatives, not comments on my current method.
so, let us look at the two presented a) union will do nothing to make it 'safer' and only make the variable names become silly.significant. b) #defines are fine, but they do disable my filtering method which can be simplified described as: I start all variable names for group a with AAA and all variable names for group c with CCC. Then I do a global replace of AAA with XXX and compile the group c modules which will reveal any misuse. Then the same for the other group.
Please remember this when YOU write a reply to others. Purile tangents just breed annoyance.
Purile tangents just breed annoyance.
your "Purile tangent" definitely will