Pumpkin, Inc.

Pumpkin User Forums

PICC18 bss limitations and mem.c

For issues specific to Microchip's PICmicro® MCUs, including compilers (e.g. HI-TECH PICC & PICC-18, Microchip MPLAB®-C18) and IDEs (e.g. Microchip MPLAB®).

PICC18 bss limitations and mem.c

Postby jtemples » Wed Nov 27, 2002 7:42 am

I just added a 15th task to my project, and got a "couldn't find xxx words for segment bss" linker error from PICC18 8.20PL2, though I have several hundred bytes of free RAM. I remembered item 97 from Hi-Tech's FAQ, which was the problem: one module can have no more than 256 bytes of bss, and mem.c was violating this requirement.

I have worked around this by creating a "mem2.c" and moving OStcbArea from mem.c to mem2.c. I'm not sure if this is valid, given the comments in mem.c related to OScTcbP.

I think mem.c will have to be split up into many files in order to be used with large projects.

jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Re: PICC18 bss limitations and mem.c

Postby aek » Wed Nov 27, 2002 8:14 am

Library or source-code build?
-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: PICC18 bss limitations and mem.c

Postby jtemples » Wed Nov 27, 2002 8:15 am

Source build.
jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Re: PICC18 bss limitations and mem.c

Postby aek » Wed Nov 27, 2002 8:22 am

quote:
I have worked around this by creating a "mem2.c" and moving OStcbArea from mem.c to mem2.c. I'm not sure if this is valid, given the comments in mem.c related to OScTcbP.
Since the PIC18's RAM space is essentially a linearly addressed one (despite banking), I don't think it's an issue. Also, since the only qualifier (by default) for OSLOC_ALL is persistent, that means that 16-bit pointers are used as data pointers, and again, there's only one RAM location with address 0. So I don't think you have anything to worry about ...

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

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

Re: PICC18 bss limitations and mem.c

Postby aek » Wed Nov 27, 2002 8:33 am

In that FAQ there is also mention of a bigbss psect -- can you put the whole of the original mem.o in there?

If placing mem.o into bigbss is possible, then there is no real limit to the number of tasks and events with PICC-18. O/wise the limit is that neither the tcb array nor the ecb array can exceed 256 bytes ...

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

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

Re: PICC18 bss limitations and mem.c

Postby jtemples » Wed Nov 27, 2002 8:40 am

quote:

In that FAQ there is also mention of a bigbss psect -- can you put the whole of the original mem.o in there?

I'm guessing that's not possible, since they don't suggest it as a workaround in the FAQ.

quote:

O/wise the limit is that neither the tcb array nor the ecb array can exceed 256 bytes

My understanding is that if a single object exceeds 256 bytes, it is automatically placed in bigbss. So if all of the Salvo arrays were encapsulated in a single structure, for example, this problem wouldn't come up.

jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Re: PICC18 bss limitations and mem.c

Postby aek » Wed Nov 27, 2002 8:44 am

OK, now I think I understand how PICC places large arrays in memory ... so, it looks like to avoid any problems with large numbers of tasks, events, etc., you'll need to create mem2.c, mem3.c, etc. each with just a single Salvo array in it (e.g. mem2.c has OStcbArea[], mem3.c has OSecbArea[], etc.). This should enable the compiler to place any arrays larger than 256 bytes into the bigbss psect.

Note that with this arrangement, you do have to be careful when new versions of Salvo are released, in case mem.c has been changed ... maybe there's an elegant way for us to provide a set of mem2.c, mem3.c, etc. that one could use in these cases in place of the current mem.c ...

Regards,

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

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


Return to PICmicro MCUs

Who is online

Users browsing this forum: No registered users and 1 guest

cron