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
Erik, you've gotten so defensive with listing all things that are not the question that you've hidden what the question actually is so well that it took me three readings to find it.
Simple answer: no, one variable never actually has two names. Nor do I agree that
It's just as insane to have two different names for the same object, since that breaks just about the only property a variable name has by itself.
What you're trying to do here does go against the grain of the material (i.e. the programming language). The only choice is which way you're going to rough it.
By far the least intrusive method is to use a union. Put all globals particular to each major module (those 'a', 'b' and 'c') into a struct, and union-ize those structs.
OTOH, the compiler's overlay analysis should already be able to discovers all those overlayable variables by itself --- if you let it.
OTOH, the compiler's overlay analysis should already be able to discovers all those overlayable variables by itself --- if you let it. the overlayable variables is no problem, the linker does that magnificently. the issue is the globals.
Simple answer: no, one variable never actually has two names. not correct, for the XDATA variables I have the definition in an asm module and them as externs in the main .h file.
so two names: name1: ds 0 name2: ds 0100h
voila!
Oh Erik,
You're such a clever boy!
Reinvented wheels always give a much more rounded result!
Who did we got now, to use this new alias?
who cares, an idiot is an idiot, I'll treat them all the same.
PS for the remote possibility that the idiot can understand a simple statement, and hoping this get to him in a moment where the fog in his brain is not too dense: "where did I say that I invented the method".
"where did I say that I invented the method"
You may not have said it, but you're usual style of answer sure did suggest it.
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.
View all questions in Keil forum