From the PIC MPLAB port for 18F4520 thread…
Re-state in as few words as possible? What are you trying to say?
I think I may be on my own, but here’s my issue. John Franklin’s attempt to solve this problem is in the FreeRTOS doc’s along with a link to his solution. I don’t see how his solution can work, and suspect that it worked for him by fluke. This, I hope, means I don’t understand it, not that it won’t work.
The issue is specific not to PIC18 peripherals but to the PIC18’s internal RAM. Memory is organized in 256 byte banks. The manual for the linker (MPLINK, not the C18 compiler) specifically says not to combine banks as the compiler won’t generate code that can navigate across a bank boundary. For instance a 32-bit variable might live at 0x1fe:0x201.
Here’s what I’m hoping for: If you must combine banks into a large section, you can protect the space (use PROTECTED keyword in linker command file) and allocate it to the heap with the right #pragma directives and section assignments wrapped around said heap declaration. This will allow pointers and arrays to grow past 256 bytes with proper addressing.
Where I see it going pear-shaped is that the heap is not a single array, but a space into which variables are allocated. If this is the case, I can’t see how this will ever work, other than by providence. Is there something I don’t get about how space is allocated to variables on the heap? I’m really struggling to understand this.
OK, so I failed to keep it short, it’s not that easy of a problem to explain.