Hi,
This post is about the classic problem creating pointers to function using the overlay procedure.
The reference in the manual suggest the OVERLAY directive to modify the call tree that is automatically generated by the linker. But what happeneds if we don't know the name of the indirect function the pointer calls? Yes this is true.
Consider the possibility of someone who try to build a lib. And this lib provide a function(funA) that calls an afterwards user defined procedure unknown by the lib function(funA). Here an example
//lib_file.h // ... typedef void (* Tpfun)(void); void module_init (Tpfun pf); void module (void); // ... //lib_file.c static Tpfun pfun; //-------------------------------- void module_init (Tpfun pf) { pfun = pf; } //---------------------- void module (void) { //code // ... pfun(); // code }
In this simple program there is no call to module_init(&..) and it is impossible to know the address/name of the indirect function and so it is also impossible to use the OVERLAY directive(i think). We know only the pointer to function "pfun". We also don't know if the indirect function call other functions. The only way to know the name of the indirect function is when the lib user decide to use the module and initializes the module using the module_init(&..);
But how can we build the lib so the user uses it???
The question is:
1)Is there a way to modify the call tree that is automatically generated by the linker in order to include the indirect function? And if there is no way. 2)How can someone enable the normal way of function call using the stack?
I'm using the eval version C51 8.08
But what happeneds if we don't know the name of the indirect function the pointer calls? Yes this is true.
Then you've just stuck yourself between a rock and a very hard place --- and for no particularly good reason, either. Think really hard if you have to go there.
Not all techniques that work well for keeping big software systems under control are equally applicable for small microcontrollers, particularly the 8051. Passing around pointers to callback functions is definitely one of those. It seriously gets in the way.
Thanks to all for the prompt answer.
I have to say that the way Andy Neil suggests is the way I'm already doing it. But for someone who try to translate code from a compiler to another(like me) is a very difficult procedure. I'm working in education and i find the keil debugger user/student friendly, but still the translation of a library and the whole documentation is a nightmare.
The end user that supplies the callback is the one that builds the complete program, and thus the one that needs to fix up the call tree.
This is true, but i believe that a library must be complete for the end user. How can the user modify the call tree if he doesn't know how the library works. He is just the user.
If the library is written for '51 purposes (no function pointers) the call tree is not the end users job but the linkers.
Erik
But the library is complete!
This "callback" function (or whatever it is) must always be supplied by the end user.
The only thing in question is: how should the library gain access to this user-provided function? The 2 choices are: 1. By name; 2. By a pointer.
Since the pointer is a Really Bad Idea for an 8051, that really only leaves 1 option...
If the library is written for '51 purposes (no function pointers but calleable by name) the call tree is not the end users job but the linkers.
Andy, we DO agree. even if "you say tomahtos and I say tomatoes"
... but i believe that a library must be complete for the end user. How can the user modify the call tree if he doesn't know how the library works. He is just the user.
When i say "complete" i mean that if you are the end user "you don't need to add or modify anything". Not even the call tree. It's a bad idea to ask for the user to know how your library works. And even if you know how to trick the call tree, probably one year later you will not. That's why i choose to use the name of the calleable function and not a pointer to it.
But what is so difficult about pointer to functions and x51. Is it that hard for the linker? In contrast with KEIL i see it like a flaw...
It has NOTHING to do with Keil (well in a way it does - if they had chosen a horrible implementation, there would be no call tree)
It has EVERYTHING to do with the '51 architecture. The '51 is extremely limited re stack space (and fetches via the stack pointer are very processor heavy), and if the call tree had not been implemented you would have a bunch of stack overflows and a very sluggish performance.
Thus, because of the ARCHITECTURE of the '51 you "In contrast with KEIL i see it like a flaw" that Keil did the most effieient inplementation possible.
So, as often said before if you do not want to be concerned with processor architecture, stay away from the '51
View all questions in Keil forum