OStcbArea greater than 256 bytes

[calluml]

Is there an easy way to get an OStcbArea array greater than 256 bytes, using mcc18. My project requires the creation of over 20 tasks, each with an extension. Can the standard LKR files be modified to allow this, or must it be handled in code.

FYI, I have the source code version of Salvo.

Thanks.

[calluml]

I now have this working.

Modified LKR file to define large enough section and #pragma in mem.c

A case of RTFM!

[aek]

OK, just for clarification:

You were able to create a larger-than-256-byte section in the linker file, locate one or more individual Salvo global objects to that section, and then have it all build and execute without problems?

From what I understand, getting it to build successfully shouldn't be a problem once you modify the linker file. My worry is runtime -- specifically (from what I've gleaned on Microchoip's forums) elements of an array of greater than 256 bytes need to be accessed (only) via a pointer.

For Salvo's array elements, pointers are used exclusively, IIRC. My concern is that some of the non-array Salvo global objects, like the queue pointers, are often accessed directly, and not as a member of an array. So if one of those objects were "past" a 256-byte boundary in a section that's larger than 256 bytes, then it's not clear to me whether it will be accessed correctly by the compiler.

The "safe" solution (and probably also the more efficient solution) is to place Salvo's global array objects in sections that are greater than 256 bytes, but leave the "individual ones" (like OScTcbP, or OSeligQP) in a normal / unspecified section, which will be of length 256 or less. After all, they don;t cause problems, anyway.

Any insight you can add would be appreciated.

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

[aek]

For anyone else reading this thread, it concerns Microchip PIC18's and Microchip's MPLAB-C18 compiler ...

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

[calluml]

Sorry for the delay in responding.

To confirm, here is what I have done.

I noticed that mem.c 's data section was growing beyond 256 bytes when my app reached 20 tasks + events etc.

Steps

Split mem.c into 2 files, mem.c & mem2.c
- mem2.c contains OSecbArea[] & OSefcbArea[] arrays (no special #pragma)
- mem.c contains everthing else, including OStcbArea[]. A #pragma at the start to assign udata to 0x100.

Changed LKR file
- defined two protected sections, one 0x100-0x2FF and another 0x300-0x4FF (second one to hold another big array)

Compiled as usual, small code, large data model.

Run, and test, various sections of code accessing array crossing 256 border by pointer and index.

All seems to be working fine.

I also saw something about large arrays and the need to use pointers on the microchip forums. Am I just lucky, should I expect this to break at some point?

Thanks,

Callum

[aek]

quote:

---

Am I just lucky, should I expect this to break at some point?

---

I suspect all will be fine. But I would recommend that you move all the non-array elements still in mem.c over to mem2.c, and have just OStcbArea[] in mem.c. If your ecb's or efcb's get big, then I'd dedicate a new module to them, with a new section.

In fact, if you're really picky, you could put the most-used Salvo global objects (the small ones from mem.c, like OScTcbP and OSeligQP, etc.) in their own module, and place them in access RAM.

I suspect the deal is that in a C18 array, objects beyond the 256th byte must be accessed via pointer. Does that mean by index, too? Probably, but I'm not sure. I suspect other accesses are no big deal, even when something is in a large section. The easy way to test would be to look at the access to a single-byte objects that the linker has located beyond the 256th byte of a section -- if it appears that the PIC18 is using enough address bits to span all of RAM as it accesses that byte, then I think most of our worries are moot.

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