The scheduler is preemptive. SDCC copies data to/from the users stack to
the overlay memory.
Saving and restoring this would be both time and memory wastefully. I
can switch to an event
driven scheme where each task runs to completion and let the interrupt
service routines do more
Your comment on OS functions is right on the mark. I build common
functions such as math and
I/O into the lower PIC flash address space. Then I only burn the tasks
into the upper. Code
for reading tachs, PID, and motor drivers for a small robot can be
flashed in seconds.
Other linkers allow the importation of symbols from another build so
that the application can use the symbols.
The best I have been able to do is link the entire OS and Application
and then hack the resulting hex file
to strip the OS. I suspect it could also be done by the flash burn
utility by specifying a start of burn address.
I have zero expectations that gplink will support anything that is not
first put forth by MicroChip. The other
SDCC ports are fortunate to have their own assemblers and linkers.
In my opinion, the major hole in PIC16 SDCC today is lack of users. Only
by having a large and varied user
base will the product be stressed and the kinks ironed out.
Vangelis Rokas wrote:
>----- Original Message -----
>From: "George M. Gallant" <ggallant571@...>
>Subject: Re: [Sdcc-user] Status of PIC16 port
>>I am using the PIC16 port with 18F252 chips. I use a simple
>>multi-tasking that handles the device initialization and I/O.
>>The only drawback to using SDCC is it does not produce
>>reentrant code which limits me to one "C" task (plan to
>>remove this restriction soon).
>I guess that SDCC isn't preserving registers your OS requires
>in order to be reentrant right? As far as I can remember I always
>tried to create reentrant code throughout the port.
>>Code optimization is very good.
>>Data access suffers from PIC limitations, lots of bank selects.
>There is a primitive bank select elimination support when accessing
>the same variable in sequence.
>I have one question concerning the OS you are using.
>I guess you've written a set of OS functions that you use
>from within your tasks. When you have to update the working
>task, do you update OS functions too?
>Wouldn't it be nice to burn OS specific code once, and just update
>the user tasks every time you need it? (Similar to how a bootloader
>I was thinking of such a feature that could be introduced but needs
>gplink modification. I see it like DLLs (dynamic link libraries).
>Gplink would create an import .cod file which will only contain
>symbol relocation data (no executable code, nor RAM/EEPROM data).
>This import file will be used later to correctly identify all external
>symbols (the OS functions), but no executable code will be inserted
>in the final output.
>So, once you burn the user task in PIC, gplink's relocated OS symbols
>will point to the correct addresses, thus eliminating the need for frequent
>How does this seems to you?
>The SF.Net email is sponsored by: Beat the post-holiday blues
>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>Sdcc-user mailing list