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.
I decided to start a new thread since this problem is different than the original one. When I compile the attached code, I get four L13: Recursive Call to Segment Warnings. One of the functions called out in the warnings is this one:
BYTE process_Help(char xdata *cmdBuf) { printf("\r\nP2_CMDHELP\r\n"); printf(cmdBuf); cmdBuf[0] = '\0'; printf( "\r\nHelp Message\r\n" return TRUE; }
// First two lines of corrected reg530.h #ifndef _REG530_H #define _REG530_H . . . #endif // Last line of corrected reg530.h
I already posted an answer under RE: More Pointer Problems w/ Formatted Code. It has nothing to do with the function, but rather it is a generic function pointer problem.
Wow, that actually got rid of the warnings, I must admit I didn't try what you suggested before becuase it didn't make very much sense to me. I'm very confused, why does moving the table inside the function as opposed to declaring it in global space fix the problem? Thanks, Chris
Look at Kiels app note named "Function Pointers". My method of declaring the function pointers in the function that calls them gets around that mess. If you have question after reading the app note, post another message.
I read the app note and thought that the way I was doing things took all of that into account. I moved the declaration of the function pointer table out of the function and into global space in the bootUart.c file (instead of bootCommands.c) and that also got rid of the warnings, so it doesn't have to be declared in the function, just in the file. Why would it make any difference which file the table is declared in? Thanks, Chris
It's a while since I looked at this stuff, and it wasn't quite applicable in my case, but I seem to remember something about it making it easier for the compiler/linker to make correct "guesses" about the pointers?
That's it exactly. But, since this is explained pretty well in the app note, I shall not preach! :-) Jon
The Kiel compiler/linker is not stacked based w.r.t. to local variables. The linker makes a call tree for the functions and statically allocate variables, overlapping them whenever possible. So it is imperative that the linker can create this tree error free, else you can get incorrectly overlapped variables. (That error is great fun to debug.) Things work fine until you get to fn ptrs. In your case the fn ptrs values were declare in the "constants" space of one particular file. To get the program to link correctly, you have to remove this association to this "constants" space of the particluar file and remap it to the correct function. I find this a high maintenance way of doing things (and difficult to explain). I perfer to move the fn ptr declarations into the proper function (even if I have to make a helper function). At that point it is a no brainer, which is something I can handle.
Thanks for all the help guys, this looks like one thing Keil can work on making better in a future release...
looks like one thing Keil can work on the warning message or the use of function pointers? I certainly think there's loads of room for improvement in the Errors helpfile; it's a brilliant idea with the description, then Symptoms, Cause, and Example - but often poorly implemented or just left blank. A missed opportunity so far, I think. It's certainly high time they got the F1 message help to work properly!