Bob,

> You might be trying to do too much. You don't need (and probably don't want)
> dynamic RAM allocation in a simple preemptive multitasking kernel for a PIC.

My application (ISDN) needs large buffers, up to 260 bytes long. Only
way to make my application to fit in the RAM of 18C452 is to use dynamic
memory. And don't say that I should consider moving to another
processor... I know that already :) My boss just don't want to change to
anything non-pin-compatible with 16C77, because we lose the possibility
to upgrade old devices.

> > Have you considered the context changing routine? I suppose I must copy
> > the hardware stack byte-by-byte to software stack and then copy another
> > task's stack back in... It would be so much easier with software call
> > stack...
>
> There are two possibilities here.
>
> 1: As you say, copy each tasks stack to a save area when that task isn't
> active. This is very costly in time and RAM.
>
> 2: Allocate a subset of the hardware stack to each task (and perhaps another
> to the interrupt handler(s)). Now when you change tasks all you have to do
> is adjust the stack pointer register. A task's context consists of only the
> stack pointer and whatever registers you want to save (W, STATUS, FSRs,
> etc). The downside of this, of course, is that you can only have a limited
> number of tasks, and they have to be careful about stack depth.

Hmm... haven't though of that, thanks!

> > > Unfortunately, it would be very surprising if the runtime code provided
> by
> > > any PIC C compiler is reentrant.
> >
> > MPLAB-C18 and IAR EWPIC18 at least claim to have re-entrant functions.
> > Code generated by MPLAB-C18 seems to be re-entrant...
>
> Ok, I am surprised. Although, when you get to thinking about it, if you
> define a large enough set of registers to be 'task context' then almost any
> compiler would qualify. In general, PIC compilers tend to use a collection
> of file registers as an 'accumulator', especially with floating point
> libraries. These registers would have to be included in the task context to
> maintain reentrancy.

In my opinion, the IAR compiler has the best approach to this problem.
They define that the compiler will use 17 bytes from access memory as
accumulator. Also, they have stated that every fuction can freely change
any or all of these bytes and all processor registers. Calling task must
save all registers that need to be saved before calling the function. I
just must include these 17 registers in the task context. That makes 32
bytes all together, one less than in AVR with 32 registers. Only extra
feat in PIC is saving the hardware stack.

Regards,

Kari Lehikko (Mr)
Software Designer
H.Vesala Ltd.
Finland

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads