Andrew,


> >This is what I have calculated as RAM requirement per task:
> >- TCB 5 bytes (id,stackptr,link to next)
> >- SW-stack of 128 bytes or so. (31+hwstack bytes for context saving +
> >normal stack)
> >
> >This way my application's memory would look like this:
> >
> >768 bytes for software stacks
> >512 byter for dynamic memory
> >128 bytes for kernel (approximation, probably will take less)
> >128 bytes for other application variables
> >
> >I would like to have more ram available to have more stacks, but I must
> >work with what I have. I can tune the stack sizes after the tasks are
> >ready and I can begin testing.
>
> Does your "normal stack" include enough space for the parameters
> you're passing?

Hopefully :)

I tend to use functions with only one pointer parameter or two byte
parameters.

> If your 31 refers to function call depths, it's actually 31*2 or even
> 31*3, depending on how your compiler does function pointers (16 bits
> or 20 bits). Or did you mean the IAR-specific "accumulator" et. al.?

17 accumulator + some registers (TBLPTR,FSRs...) make that 31 bytes. I
will also only save 16-bit rom-pointers as the highest byte is never
used in 18C452. (Yes, I know...I should think upward compatibility...)

> One thing  that hasn't been mentioned in this discussion is the
> impact on the application's size due to the ability of the compiler
> to pass parameters on the stack. IAR and MPLAB can do it, and
> therefore also support recursion and reentrancy. PICC-18 does it
> differently, by maintaining a "parameter area" that allows the
> generated code to directly access the variables in question instead
> of via the stack pointer, etc.  This has a major impact on code size.
> Admittedly, the PIC18 has the potential for a very large number of
> instructions -- but right now its memory sapce (the 18C452's, 16K) is
> just double that of a PIC16C77 (8K). What you'll find is that with
> applications that do a lot of parameter passing, you may be surprised
> at how large the output of the stack-based compilers is.

I agree that the way PICC18 does the parameter passing suits well to
small microcontrollers. Anyway, they should not call it ANSI-C
compatible. As my code now takes the 8k offered by 16c77 (orginally our
product was 16C77-based), I would be very surprised, if using C instead
of assembler and adding an RTOS would bloat it over 16k.

> I'm not suggesting that any one compiler is better than the other.
> I'm merely pointing out that if you can get the job done without the
> compiler passing parameters on the stack, then your application may
> be a whole lot smaller. After all, the parameter-passing overhead is
> not insubstantial.

Yes, I know. Have already tried and failed. Our application is very
complex.

Regards,

Kari Lehikko

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body