Deleting unused variables

echase · Post by **echase** » Sun Sep 16, 2007 10:41 am

1) What is the simplest way to purge out variables that are not actually being called? Can delete one by one and see if it gives an error message saying itβ€™s actually used, but still don't know which bit of code is actually using them. Is there a quicker way?

2) I have managed to generate some strange unused variables with names like β€variable.variableβ€™ and β€variable.Return.β€™ when setting up interrupt macros, but when I list the variables and try to delete or rename them they are unselectable for change. Why? What to do? Interesting that they are only listed when calling a list of variables in the macro where they were first generated. Other lists of variables, apart from when running the simulation, do not list them

Donβ€™t know if there is any connection with all this and error messages I get when compiling. Do I need to be worried about any of these? Software seems to work OK despite them, although there are occasional corrupt characters on the LCD because it sometime rewrites the display before the last macro has finished writing the LCD. I am not worried about that as long as it clears itself, which it does.

Warning: Recursion may cause call stack overflow in function:'FCM_Pump_on_or_off'
Caution: argument of 'delay_10us' calls must have a value of 1 or more
Caution: Delay inaccurrate: 'delay_10us', Delay overhead:0.352ms, Unit delay:0.016ms, Delay resolution:8 units

.

Warning unreferenced functions removed:
FCD_LCDDisplay0_GetDefines in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_LCDDisplay0_PrintASCII in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_LCDDisplay0_Command in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_LCDDisplay0_RawSend in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_ADC0_ReadAsInt in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_ADC1_ReadAsInt in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_ADC2_ReadAsInt in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_ADC3_ReadAsInt in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_ADC4_ReadAsInt in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
FCD_ADC5_ReadAsInt in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c
LCD_591656_Dummy_Function in: C:\Documents and Settings\Chase\My Documents\PIC programmes\886v6.c

Building CASM file
Serious Warning: Call stack usage exceeds:8!

Call Stack Usage Report
=======================
main and Task(s): hw used:7, exceeded by:0
interrupt: hw used:6, exceeded by:0
Serious Warning: Possible sw stack corruption, function 'FCM_Turn_power_up' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)
Serious Warning: Possible sw stack corruption, function 'FCD_LCDDisplay0_PrintNumber' called by more than one asynchronous thread (main/Task, interrupt, interrupt low)

Post by **Benj** » Mon Sep 17, 2007 9:29 am

Hello Echase

1) The easiest way is to create variables as you use them. Apart from this there is no simple way of removing obsolete variables. However the compiler will automatically do this for you so the unused variables will not end up being programmed onto the hardware.

2) Variable.variable referrs to variables that are local to software macro routines. To edit the list of these variables you will need to open up your software macro by going to macro and show macro. Then you can click macro and edit macro to change the variables and return type.

3) You are getting two individual warning messages.
A) Unreferenced functions removed.

This means that functions to drive hardware etc are not being called and therefore they are being removed from the compiled code. This is fine and you should not worry about this.

B) Recursion may cause call stack overflow

This means that the same function is being called twice eg once from the main and again from an interrupt. This means that a piece of code eg a LCD controller might get half way through, The chip interrupts and then enters the LCD driver again, after the interrupt the code will resume the LCD routine. This can cause corruption on the external device. It is wise to either disable interrupts before doing code that is repeated in the interrupt routine, or to only use the code via the interrupt routine.

Hope that this helps.

echase · Post by **echase** » Mon Sep 17, 2007 9:42 am

Thanks. And what does this error message mean? Is it because my clock speed, at 125KHz, is too slow to correctly do short delays?

'Caution: argument of 'delay_10us' calls must have a value of 1 or more
Caution: Delay inaccurrate: 'delay_10us', Delay overhead:0.352ms, Unit delay:0.016ms, Delay resolution:8 units

Post by **Steve** » Mon Sep 17, 2007 12:34 pm

When using interrupts, it is important to keep the interrupt routine as short as possible. For this reason, I would suggest you do not call other macros from within the interrupt routine.

Instead, do the required calculations and/or set a global variable to signal to the main routine to update the display, etc.

Post by **Benj** » Mon Sep 17, 2007 1:19 pm

what does this error message mean? Is it because my clock speed, at 125KHz, is too slow to correctly do short delays?

Yes this is just saying that the delay you are trying to achieve is too fast for the PIC because your clock speed is too low.

If timing is not critical then this is not a problem. If timing is critical then you may need to replace the delay_10us(); with a nop(); or two or you could use a faster crystal.