Does a stack level of 2 limit me to 2 nested subroutines?

[Mark Stevenson]

Hello.
I'm truly sorry for asking what will seem to be such a daft question, but I'm very green on PIC programming.

I'm having a problem with a program (written many [many] years ago, by someone who no longer works at the company) that very intermittently fails once only, when first powered on, then working correctly for the rest of the day.

Having re-written the code into what I considered to be a tidier format, with sections of the code moved into individual routines and functions rather than multiple If..Else statements I thought things looked tidier. I included some debug information that if a certain switch is held in at power-up the LED display would show some numeric information indicating the progress of the program, to enable me to determine at what point the failure occurred.

I then decided to replace the 16C57 with some 16F57 reprogrammable devices to save on cost. On comparing the two devices to check this would be possible, I see that this range is specified as having a 'Stack Level of 2'. Having neatly divided my program into individual routines, I quickly realised that if each sub-routine call is placed on the stack, I'm going to be way over 2. Hmm...

Having searched this site, I see reference to checking the .LST file for the stack level. On opening the compiled .LST file for my program I see this:

[ckielstra]

Yes, your stack level is a problem.
It would have been nice when the compiler had given you a warning as the information about the number of stack levels for your chip is available. I haven't checked whether the newer compilers do give this warning.

Using '#inline' for some of your functions could bring down the number of stack levels. It'll take a bit more program memory but you'll keep the nice new program structure.
See the tree file (*.tre) in your project directory for which functions are at each stack level. This will guide you in choosing the functions to #inline.

One other option for you is to change to the PIC16F570, only a few cents more expensive but a newer device with better specifications in many aspects. I didn't check all features, but product number suggests compatibility. Still a stack level of 4 though...
If you can spend another 30 cents then there are lots more processor models you can choose from that have 16 stack levels and lots of other goodies, for example the PIC16F1512.

[PCM programmer]

Those PICs wouldn't work in his board. The PIC16F57 has a really old
pinout. Power and ground are on pins 2 and 4 on the 28-pin DIP package.


If the original program is using #separate above some routines, the
PCB compiler will generate a lot of pseudo-calls to these routines
(instead of inline) by using GOTO's. It will count each of these pseudo-
calls as a stack level in the summary at the top of the .LST file.
In other words, it may only use two nested CALL instructions and be OK.
The PCB compiler is really clever about working with only two stack levels.

I think you have to carefully study the .LST file to see if it's making a
mistake. Or run the code in MPLAB simulator. It should throw a
stack overflow error if one exists.

[RF_Developer]

Mark, do you actually know what the original problem was? Did you solve it? Was it some initialisation timing problem perhaps? Could it, as you suggest, even have been stack overflow?

I ask as its very tempting as a new broom to come in and sweep clean, but in so doing, i.e. by rearranging the code, you've opened up a can of worms and introduced a lot of uncertainty. It's clearly going to take a lot of coding and testing just to get back the where the code was when you started.

My approach to this would have been to deal with the code as it was and find and solve the problem. Then, having sorted that, and fully understanding the failure mechanism, do any code rearrangement and/or migration to an newer PIC as a second, and separate stage.

Later PICs are generally a lot easier to deal with than the early types. They have more of everything, including stack. Early PICs needed much more careful and experienced programming, and weren't so easy for inexperienced PIC coders to use. But we all muddled through somehow, learning from our mistakes. You sound to be a proficient programmer, but just not used to PICs. That can make this new broom tendency worse, as you'll be tempted to bring in best practice from other programming environments; but these are sometimes not suitable for PICs, especially earlier, more limited ones.

The 'C57 and 'F57 have the same levels of stack. As far as I can see, code written for the 'C57 should work with minimal changes on the 'F57. I'm assuming you've already sorted out the device programming hardware differences... or are you developing this code on a simulator?

[Mark Stevenson]

Thanks for all your replies. If I don't mention your response, it isn't that I have not read it or appreciated it.

Showing my ignorance again, if I use the #inline option are there any knock on effects other than larger memory footprint? Memory I'm not too short of.

All the original functions (bar one) are declared as #separate. All I added also using #separate as I knew no better.

My functions do definitely have nested levels (as written) greater than two. I've got to study the original, to determine if it has. I strongly suspect it has up to three.

I don't know what the original problem is. I have looked at the original code and was struggling to follow the flow of the program. I replaced the 'PIN_C7' type references with 'Clear_Button_Normally_High' for example, to assist me. Then went on to breaking the program into subroutines so I could follow the flow. My compiled program initially appears to run, other than the excessive nested loops.

I've tried to simulate the program, but as it relies on buttons being pressed in and out, with pauses in between, I find that any simulation runs so slowly to be of use. I've not been able to get a simulator to work at all in MPLAB. But that is probably down to me not understanding it.

I'm most experienced programming using Borland's Delphi, which I understood well. I would like to rewrite the software using Revolution Education's PicAxe chips. Their simulator works more like that I'm familiar with from Delphi in that it steps through the actual written code (Basic) line by line, as well as having a 'virtual' chip you can click on to activate the inputs/outputs. Very handy for a fool like me. Still, I'm stuck with the 16x57 chips, and the tools I've got.

I'll study the documentation for the #inline directives and see what I can do.

I am grateful for all the help, many many thanks.

[RF_Developer]

Its best to avoid simulation. Debug on real hardware in real time wherever possible.

The 'F57 has ICSP (In Circuit Serial Programming) for programming and real time debug, the 'C57 does have ISCP for programming, but may not be able to be easily be real time debugged (it requires an emulator). Whether your circuit is compatible with ICSP debugging is another matter, it may not be depending on how the 'C57 was programmed.

When you use #inline, the compiler generates a copy of of the routine for every time its called. ROM usage will be higher. RAM usage will probably be somewhat higher too.

[PCM programmer]