If an array fits inside a single bank, you can put the entire array inside of that bank by qualifying it with the PIC C bankn directive. See Pumpkin's App Note AN-3 for more info.
Another possibility would be to use the external RAM and use table read/write operations -- there is an app note on HI-TECH's web site addressing that issue.
Additionally, regardless of what you do, you need to ensure that operating on your large array does not change the Salvo control structures. You can "isolate" them to a degree by using the OSLOC_XYZ configuration options, e.g. by setting them all to be bank3.
Lastly, by using Salvo's OSLOC_XYZ configuartion parameters (and therefore changing from the default of RAM Bank 0) you will see additional memory freed up in Bank 0, which the compiler uses for parameter passing, etc.
Or alternatively, could I use two different messages to signal the same task. Does the WaitMsgQ function handle this sort of thing or do I need to do something else. Each message would point to an array of data in one of two different banks. What is the best way to do this?
First off, since you're passing pointers to arrays, I strongly suggest you investigate the whole PIC17 PIC C FAR pointer issue -- that may end up being really simple.
If that doesn't work, I think you'll have an easier time going with the first method, and using a message that points to a structure. The struct would look something like this:
bank1 char * bank1ArrayP;
bank2 char * bank2ArrayP;
I.e. the structure contains a pointer to banked info, as well as additional information on which bank the pointer points to. While I haven't tried this, if the compiler accepts it, then it ought to work. What you do is initialize the struct with the array pointer and a bank index (say, 1 or 2), and then signal the task. Then the task that waits the message does a switch() on <bankIndex> and then assigns one of two local pointers (each one declared to be of the appropriate type, as above) to the pointer part of the struct in the message, and then off you go.
Think about what's happening in the compiler -- pointers are only 8 bits, and so there's no way to distinguish between GPRAM @ location 143 in bank1 or bank2. I suspect FAR pointers are 16 bits, of which only 10 bits are actually used. When you declare a pointer with a bank qualifier, it basically tells the compiler to add in bank switching to the pointer code.
Your alternative solution (disjunctive event signaling as you've described) won't work in Salvo v2.1.x.
Users browsing this forum: No registered users and 0 guests