PicC 9.50 dsPIC Manual.pdf

Map FilesLinker and Utilitiesshown at the far left of the call graph. This indicates that it is the root of a call tree. The run-timecode has the FNROOT assembler directive that specifies this. The size field after the name indicatesthe number of parameters and auto variables, respectively. Here, main() takes no parameters anddefines no auto variables. The offset field is the offset at which the function’s parameters and autovariables have been placed from the beginning of the area of memory used for this purpose. Therun-time code contains a FNCONF directive which tells the compiler in which psect parameters andauto variables should reside. This memory will be shown in the map file under the name COMMON.Main() calls a function called init(). This function uses a total of two bytes of parameters(it may be two objects of type char or one int; that is not important) and has three bytes of autovariables. These figures are the total of bytes of memory consumed by the function. If the functionwas passed a two-byte int, but that was done via a register, then the two bytes would not be includedin this total. Since main() did not use any of the local object memory, the offset of init()’s memoryis still at 0.The function init() itself calls another function called ports(). This function uses two bytesof parameters and another two bytes of auto variables. Since ports() is called by init(), itslocal variables cannot be overlapped with those of init()’s, so the offset is 5, which means thatports()’s local objects were placed immediately after those of init()’s.The function main also calls sprintf(). Since the function sprintf() is not active at the sametime as init() or ports(), their local objects can be overlapped and the offset is hence set to 0.Sprintf() calls a function putch(), but this function uses no memory for parameters (the charpassed as argument is apparently done so via a register) or locals, so the size and offset are zero andare not printed.Main() also calls another function indirectly using a function pointer. This is indicated by thetwo INDIRECT entries in the graph. The number following is the signature value of functions thatcould potentially be called by the indirect call. This number is calculated from the parameters andreturn type of the functions the pointer can indirectly call. The names of any functions that have thissignature value are listed underneath the INDIRECT entries. Their inclusion does not mean that theywere called (there is no way to determine that), but that they could potentially be called.The last line shows another function whose name is at the far left of the call graph. This impliesthat this is the root of another call graph tree. This is an interrupt function which is not called by anycode, but which is automatically invoked when an enabled interrupt occurs. This interrupt routinecalls the function incr(), which is shown shorthand in the graph by the -> symbol followed by thecalled function’s name instead of having that function shown indented on the following line. This isdone whenever the calling function does not takes parameters, nor defines any variables.Those lines in the graph which are starred with * are those functions which are on a criticalpath in terms of RAM usage. For example, in the above, (main() is a trivial example) considerthe function sprintf(). This uses a large amount of local memory and if you could somehowrewrite it so that it used less local memory, it would reduce the entire program’s RAM usage. Thefunctions init() and ports() have had their local memory overlapped with that of sprintf(), so102