Pumpkin, Inc.

Pumpkin User Forums

inline compile errors

If you can't make Salvo do what you want it to do, post it here.

inline compile errors

Postby James » Thu Oct 18, 2001 1:39 am

Well, that took care of that problem, thank you. (I do have the full version of Salvo 2.2 and I am compiling the source along with my code.)
Do you happen to know, in the -M map output from PICC would I take the deepest call in the call graph and then add the maximum interrupt call depth for a "worst case" stack depth?
James
 
Posts: 12
Joined: Thu Oct 04, 2001 11:00 pm
Location: San Diego, CA, USA

Re: inline compile errors

Postby James » Thu Oct 18, 2001 9:52 am

I am a little distressed by the 4 stack levels used by Salvo (according to the PICC call graph). So, I changed the values of OSUSE_INLINE_OSTIMER and OSUSE_INLINE_OSSCHED to TRUE but in each case the program will not compile. In the first case the first error is: Error: file c:salvosource imer.c 56 : no identifier in declaration. In the second case I get Error: file c:salvosourcesched.c 74 : no identifier in declaration.
Any ideas?


James
 
Posts: 12
Joined: Thu Oct 04, 2001 11:00 pm
Location: San Diego, CA, USA

Re: inline compile errors

Postby aek » Thu Oct 18, 2001 10:16 am

Hi James.

It's not enough to just change the values in salvocfg.h -- you also have to change your source code and your project, AND it can only be done with the full version of Salvo.

Carefully review the examples for OSUSE_INLINE_OSSCHED and OSUSE_INLINE_OSTIMER in the Configuration Chapter of the User Manual.

For example, instead of calling OSSched(), you have to do it like this:

code:
main()
{
...
for (;;) {
#include "sched.c"
}
}

And you must remove sched.c from the list of nodes in your project (assuming you're doing a full-source build).

In-lining these two functions is done this way because many compilers don't have support for inlining functions via an inline pragma, etc.

Although I have never tried it, I suspect that this can even be done with a library build ... in this case there is no discernable function called OSSched(), and therefore nothing will be pulled in from the library.

Also see salvodemod1main.c for examples of using OSUSE_INLINE_OSSCHED and OSUSE_INLINE_OSTIMER.

Once you get a successful compile, you will have freed up two call levels (one for OSSched() and one for OSTimer()), and if your ISR is simple (i.e. "calls" OSTimer() and doesn't call any functions external to the source code module your ISR is located in), then your ISR will become much smaller and faster.

Regards,

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: inline compile errors

Postby aek » Sat Oct 20, 2001 8:32 am

Hi James.

Re: call depths and map files: Yes, that's correct, with the following caveat.

Looking at the map file, you'll see this "between" OSSched() and your tasks:

code:

_OSSched size 0,0 offset 4
string_table
INDIRECT 88
INDIRECT 88
_TaskDummy->_OSSaveRtnAddr size 2,0 offset 6

If this were the deepest part of the call graph, then the total number of stack levels used by mainline code would be 3 (not 4). That's because (and you can trace this in the Program Memory Window of MPLAB) an indirect function call (i.e. when OSSched() dispatches your task) is a call to string_table, followed by some direct manipulation of PCLATH and PCL (no stack used) followed by a goto (no stack used). The only "real" calls in the tree above are main() calling OSSched() (depth= 1), OSSched() "calling" TaskDummy() via a call-via-pointer (depth = 2), and TaskDummy() calling OSSaveRtnAddr() (depth = 3).

So, to figure out the worst-case stack utilization you use main()'s call graph, and add in whatever the interrupt service routine's callgraph shows. Setting OSUSE_INLINE_OSSCHED and OSUSE_INLINE_OSTIMER to TRUE will reduce each of these, respectively, by 1 stack level.

If you can run salvodemod1sysad1.pjt you'll see that it reports on the maximum stack depth used (by Salvo, not by the whole application) when it dumps Salvo status via a call to OSRpt(). Salvo's stack checking cannot account for the stack level(s) used by interrupts, nor that of your own code. But it does accurately reflect how deep the calls to Salvo services are.

------------------

[This message has been edited by aek (edited October 20, 2001).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: inline compile errors

Postby DHenry » Sun Oct 21, 2001 8:16 am

To all:

And don't forget to factor in any "invisible" call levels created by accessing const data stored in ROM, which is accessed by call/retlw.

DHenry
 
Posts: 18
Joined: Sat Aug 04, 2001 11:00 pm
Location: Boulder, CO, U.S.A.


Return to Coding

Who is online

Users browsing this forum: No registered users and 2 guests

cron