i am facing a wierd problem.. My MCU P89V51RD2BN resets during Execution... i am a college student and a beginner Here so i dont know the Advanced Programming methods i would also inform that..
i have a recursive function , a warning is issued by the compiler for the same. but....
earlier this was not a problem but since i have modified some of the Sub-Routines for 16Bit Data this Problem has come up, i need those functions to be 16 bit because of the limitation of the ALU i was earlier using 8bit and leaving most of the Task to Assumption which i cannot do so now..
i would also state that the Problem occurs in a fumction at a point when i call 2 functions in the same code, these themselves call around 5 sub-routines each but that wasnt a problem earlier (before i used the 16bit return type sub-routines).
now i found something in the manual stating reentrant Functions, but i really dont know how to use it
i used it like this
void Home_Screen_Instance() reentrant { ------------ } Do i need to use the keyword "reentrant" in the Function Decleration too? but that didnt help either but the compilers shows an error Home_Screen_Instance : redefinition. Target Not Created
this was the first of a kind problem that i encountered, my MCU is resetting itself for sure(i checked that with a dummy subroutine of blinking LED) and it is not because of the watchdog timer, i am sure about that too..
so whats the Problem here?
is the Stack overflowing??? or there is any other reason behind this? should i revert back to the 8bit versions of my subroutine (without any other choice)? is it because of the recursive nature of the function H0me_screen_instance?
Related Data:
The Program is Display intensive, i mean there are a lot of Strings to be displayed and they are stored beforehand in XDATA, message shown during sucessfull compilation, (still resets) Program Size: data 9.4 xdata 252 code 9514 creating hex-----blah blah blah---- 0 Error(s) 65 Warning(s)
thank you for your time erik!
i found out during the development that 8051 was not a good choice while performing 16bit operations and other Processor Heavy operation... However its simplicity made it the first choice for me..also its the first microcontroller ive tried...
and as far as the Problem goes it has been rectified...
Turns out it was one of the most common mistkes of all "a typo" i had changed the function name in the definition but not in the decleration, i corrected it and it worked but it still shows the warning about the recursive functions and all... and i still cant use the Reentrant Keyword
anyways what would you suggest me for the next MCU platform after 8051 AVR,MSP430,PIC,Freescale HSC012,STM32 or ARM. im just a student so would prefer easy availability of tutorilas and support forums etc, along with cheap development boards
i found out during the development that 8051 was not a good choice while performing 16bit operations and other Processor Heavy operation... WRONG! the '51 is "not a good choice" when you, against common sense, approach it with a "C is C" mentality. I have done a multitude of '51 projects with "heavy load" and "16 bit operations". There is no need for float, RTOS, reentrancy, recursion, malloc, function pointers .......
it still shows the warning about the recursive functions and all... and i still cant use the Reentrant Keyword why oh why do you fool around with reentrant and recursive? are you trying to impress someone instead of writing code that works.
anyways what would you suggest me for the next MCU platform after 8051 AVR,MSP430,PIC,Freescale HSC012,STM32 or ARM.
absolutely the ARM; however, before you switch LEARN to 'think embedded" which you clearly has not.
Erik
have i missed something here? i understand your point of not thinking in embedded,i have tried my best in that way and have always come back to "not thinking Embedded", i will accept my inabilities here , i cant think embedded. The C and C++ compilers available now have made the job really easier and more like the Programming experience for the x86 Platform, as i said this was the first micro controller that i tried, i was too wary of trying Assembly and started with the Embedded C, this although gave me a jumpstart, i know that i have missed many of the intricacies which i would have acquainted programming in assembly .my Programming mindset for the 8051 has been almost the same as that of the regular 'C' for the desktop platform.
anyways the Recursive/Reentrant was not for impressing anyone, but it gives an annoying warning after every compilation... i think it shall be best to take care of all warnings except those of "Uncalled Segments"
anyways, thank you for your suggestion regarding the next platform to learn "ARM"
have i missed something here
In a word: yes. What makes this simple fact so astonishing is that you go on listing a comprehensive of exactly what you did, in fact, miss. So how can you know what you missed, but not that you missed it?
anyways the Recursive/Reentrant was not for impressing anyone, but it gives an annoying warning after every compilation...
So instead of taking that warning --- and Erik's advice --- at face value, you took it upon yourself to ignore it and keep on using recursive functions on a platform that simply isn't any good at doing recursion in C.
i think it shall be best to take care of all warnings except those of "Uncalled Segments"
And on what hard-earned experience would you be basing the belief this warning can be safely ignored, just like that? Yours, which is esentially none at all? You're kidding, right?
No, a '51 is not a PC, and you're doing yourself a disservice ignoring that fact.
i wasnt ignoring that warning... i am still figuring out a way to eliminate it... i was just ignoring the warnings of "uncalled Segments" now what you say? i am a novice here should i ignore the "uncalled Segments" warning or not?
you guys are clearly in a better position than me to answer this
"i am still figuring out a way to eliminate it..."
Wouldn't removing the recursion help out? Or does that feel like a too simple solution?
Note that any recursive algorithm can be rewritten into a non-recursive.
If you are not setting up your recursive function with the recursive keyword, it will not work. Now it may appear to work, and may do what you want. But if there is any local data used it will overlay and corrupt the earlier calls. No Overlay-able data and it works fine. So Design or chance?
"i think it shall be best to take care of all warnings except those of "Uncalled Segments"" You are ignoring it. OK, do you understand the penalty? The Compiler will assume the functions do get called, But can not figure out how. So it will reserve RAM for each function without overlaying. This wastes RAM.
thanks neil!! i was ignoring the uncalled segments as the warning states that it was "ignored for overlay Process"
and another thing, my recursive function has no local DATA, it just Prints Text on an LCD, and calls another sub-routine depending upon the input from a keypad,
again its a student Project and i am completely new to embedded C Programming.
Don't you think i know the limitation of an embedded Processor...
and if i could have written the code in non-recursive form i would have written it... moreover i understand what you are trying to convey.
my recursive function has no local data, so the stack shall have return adresses only i suppose...
im still working on a way to write the code in a non recursive format!!
and please be a little "encouraging", just because you have so much knowledge about a platform doesn't mean you come hard on those who dont.
"my recursive function has no local DATA, it just Prints Text on an LCD, and calls another sub-routine depending upon the input from a keypad,"
I'm not sure we are using the same definition of "recursive function".
A recursive function is a function that calls itself, or calls other functions in a call chain where one of the directly or indirectly called functions will call the original function again.
So recursion means that the call chain forms a loop. With a non-recursive design, you can still call several levels deep, but the call sequences just forms trees.
The compiler/linker explicitly analyses the call sequences by the code, to figure out the branches of the call tree - functions that are never part of same path from root (main) to leaf of the call tree can use the same memory locations for storing local data or parameters. So the variables/parameters gets overlayed in global data space because the 8051 don't have a real stack powerful enough.
With more general processor architectures, the compiler don't need to perform this optimization. It's enough to just push parameters and local (auto) variables on the stack, and pop when the function returns.
"Don't you think i know the limitation of an embedded Processor..."
No, I don't think you do. Or you wouldn't have used the term "an embedded processor". There aren't "one" embedded processor. Different processors have different limitations. And no - I do not thing you have grasped all limitations of the 8051 architecture yet - and exactly what it implies to C code or what steps a C compiler has to take to try to circumvent some of the limitations.
"and if i could have written the code in non-recursive form i would have written it..." In this case, I'm not even convinced you know the difference between recursive or non-recursive, based on your comments in a different post.
If I'm wrong and you really do use a recursive algorithm - please tell which. As I said - all recursive algorithms can be rewritten as non-recursive. If nothing else, then by the use of an array to store state information - i.e. the code itself stores the current state. An example is how a recursive-descent parser recursively calls higher-prioritized functions to process expressions. Compared to a state-driven parser that looks at current state and current token(s) to decide if more state should be pushed, or if enough information have been retrieved that one or more state entries could be reduced.
We just can't help you based on what information you do not post.
All we can do is see what you do post - and you do tell us that you are ignoring issues found by the compiler.
we are using the same definition of recursive function
i have got a "chain" in which one function calls another and so on till one another function in the chain calls the initial function... so let me put the code here
home_Screen() { --------- Lock_Screen(); ------- -------- }
Lock Screen() //Checks the Password { if(yes) Main_Menu(); else return; }
main_menu() { --------- --------- switch() { ---- --- - - - -- case 4:Home_Screen(); //when user presses the "Home" Button
// Here is the recursion. this is just one of the recursion,s there are other functions too } }
i am working on getting this code into a non-recursive format... and once more im just a beginner in embedded C, i am not as learned as you guys !!
Your issue is that you mix the code for displaying a menu with the code that processes it.
So you handle one menu, then jump to screen-lock then have the screen-lock once more call the function to handle the same menu, after unlock. That is wrong.
With the draw function separated, you don't need a recursive call to redraw the main menu after unlock.
current_display = x; wanted_display = y; locked = false; pwd_input_state = 0; void handle_display() { if (idle_time > AUTO_LOCK) { locked = true; pwd_input_state = 0; } if (locked) wanted_display = DISP_LOCKED; if (current_display != wanted_display) { switch (wanted_display) { ... case DISP_LOCKED: saved_display = current_display; draw_screen_lock(); break; case DISP_MAIN: draw_screen_main(); break; case DISP_SUBMENU_1: draw_submenu_1(); break; default: ; // should not happen - do some repair } current_display = wanted_display; } input = check_input(); if (input) { clear_idle_time(); switch (current_display) { ... case DISP_LOCKED: if (is_unlock(input)) { wanted_display = saved_display; } break; case DISP_MAIN: switch (input) { case BUTTON_1: do_main_1(); break; case BUTTON_2: do_main_2(); break; ... } break; case DISP_SUBMENU_1: switch (input) { ... } break; default: ; // should not happen - do some repair } } } void main() { for (;;) { ... handle_display(); } }
So you handle one menu, then jump to screen-lock then have the screen-lock once more call the function to handle the same menu, after unlock. That is wrong. wrong whether embedded or not, it is just bad design
"wrong whether embedded or not, it is just bad design"
It's more interesting than that. What if the second stacked main menu also gets a timeout and locks the screen. Or the 100th nested call to the main menu? Then we have the situation: menu -> lock -> menu -> lock -> menu -> lock -> ....
Any processor with a finite state storage area would run out of state space (wither a hw stack or a software-implemented stack) for such a design.
Any processor with a finite state storage area would run out of state space (wither a hw stack or a software-implemented stack) for such a design. I have actually seen that one, a frustrated used pressing the button umpteen times and SPLASH!