I’ve been working on a new autonomous mode for this year’s competition that is reliant on arrays to store the location of way points. I started to wonder whether or not last year’s controller would allow array declarations. I sifted through the data sheet (should be called a data book) but I could not find anything that answered my question and I don’t have access to MPLAB at the moment to try compiling a test program. Has anyone used arrays on the new controller? What are the limits on the number of values stored in an array? Anyway around using arrays if they are not allowed or are too limited because of ram size (such as EEPROM)?
You can use arrays in addition to just about anything supported by ANSI C.
char myArray[2];
or
rom const char myArray[2] = {1, 2};
The size of the array is limited only by the amount of either program or data memory available. I believe the EEPROM is 1Mb. Check out the PIC18F8520 datasheet either from Microchip’s site or through InnovationFIRST.
<edit>
I see that you said you already looked at the datasheet. Did you take a look at the guide for the C18 Compiler?
<edit>
As mentioned above arrays are supported.
If you use ram data space you are limited to 256 bytes of global variables (or static) declared within any one MPLAB file, e.g., “char a[256];”. 120 bytes of variables within a single routine. This doesn’t mean you can’t break the array up into several smaller arrays. A total of 1,343 bytes of ram are available to the user after the IFI overhead.
An array of rom constants (those that use program space) can be larger, but can’t be modified at run time.
EEPROM requires a read/write operation for each value you put in or take out.
That is perfect for what I am writting. I plan to place a maximum of 240 bytes into an array. The values will not change once the program as been written.
Thanks for the help.
Just wanted to mention that while single dimension arrays work as expected, there are some oddities in the mcc18 implementation of C with multi-dimensional arrays, e.g., char abc[10,5]. Especially, differences between how a multi-dimensional array behaves in rom vs. in ram space when passed by address to another routine. If you plan on doing this I suggest experimenting first with a test program.
Mark,
I used multidimensional arrays in ROM space with no issues. I address the array by pointer reference and index from there.
I don’t have any arrays in RAM space so I can’t speak to that… Are you dynamically allocating storage or anything strange like that?
Hi Mike,
I also use multi-dimensional arrays without problems, however, my main programmer coded an algorithm Fall 2003 using a multi-dimensional array in ram to empirically develop some constant values. When he simply changed the declaration to rom after fixing his constants the code choked. No dynamic allocation of memory (especially since it was in rom;) ).
I don’t remember the details (it was almost a year ago), and don’t think those details are germaine to poor scitobor here:). When I debugged the problem I did change how his code used pointer arithmetic, but only because his particular application ran into an odd compiler bug. It generated incorrect assembly (no he wasn’t optimizing – I knew you guys reading this were thinking that). It’s probably gone from the latest version shipped with the KOP this year.
Hence the caution and suggestion that one might benefit from testing a simplified skeleton of an algorithm using rom multi-dimensional arrays. I consider that good practice for the students in any case.
Two possibilities come to mind. Your student may have been using a byte index in RAM and did not change it to a word for ROM. The other is that, if he or she was using pointers, the pointer had to change to ROM CONST also…
At any rate, it sounds like a moot point now. If anyone else has problems, let us know…
Both suggestions are possible. It only took 5 minutes to debug which is why I don’t remember the details, just that it occurred. I was helping him fix other errors at the same time, too. It’s the kind of thing that can drive a student bonkers, but is just fun for us mentors.
I have on my “to do” list an off-season debugging workshop where the more advanced student programmers have to find what’s wrong with a collection of misbehaving projects and code ranging from obvious MPLAB issues to subtle code problems.