I am writting a mapping program for my vex, however robotC does not let me have anything larger than a 15 x 15 array of anything. I figured this was due to memory issues. So I tried using an unsigned data type but that of course isn’t allowed. Why is this? All I need is a decent sized 2d array of single bit data. If theres enough memory for a 15x15 grid with 8bit data then surely a 50 x 50 1 bit data grid is feasable. Is there a way around either of these restrictions?
You might be better off using a different type of micro-controller to do occupancy grid mapping.
You could have VEX act as the low level interface (over the USB-serial adapter) between a laptop or more complex microcontroller that handles all the occupancy grid math operations.
Or you could wait for the new VEX ARM9 modules that would do most of what your interested in doing.
https://vexforum.com/wiki/index.php/VEX_Arm9_Microcontroller
This might seem odd but you could use four different arrays. That would give you a 30x30 grid.
I agree though, why is the limitation 15x15? Wait… 15x15 is actually makes sense. That is assuming there is a 0x0 in there. So you really have a 1-16 x 1-16 grid. 16x16 = 256.
@SmartKid: I like this idea, however wouldn’t that still run over memory? Or is it just preventing me from allocating that much memory to one array? Also how would just 4 arrays give me a 30x30 grid?
I cant wait for a new microcontroller. this is my senior undergrad research proj and the dealines are zooming ever closer.
You can store the single bits in larger words. Remember that a 32-bit int can hold 32 of your bits.
Manipulating the individual bits that are packed into the larger words will be a pain, but you can hide that pain in 2-4 subroutines you write once and then never have to touch again (read, write, flip, compare).
This sort of thing was de rigueur back in the days of punched cards and paper tape, and outrageously expensive online storage; and it probably still occurs in space probes and other devices (like microcontrollers) where someone needs to squeeze every last drop of performance out of a limited hardware suite.
Blake
PS: Be glad for what you have, back when I was young we didn’t even have 1’s. We had to do all of our programming using just 0’s… And it took forever for the wet clay to dry after it came out of the printer… And
PPS: Hey - You are a Senior! - Start using that noggin 
If it was easy everyone would have a diploma 
Awri,
If you have a 15 row, by 15 column, by 8-bits array, you could define the third dimension (bits) to be an index in a sub-array of each cell. If you assign each of the first four bits of each main array address to a location in a 2 by 2 sub-array, you’d get your 30 by 30.
Yes, this will require a bit more math in computing addresses and reading and writing, but think of it as an opportunity to play with the joys of binary math.
Remember, there are only 10 kinds of people in the world: Those who understand binary and those who do not.
Good Luck,
Eric
This was what I was planning on doing. However the ROBOTC doesn’t allow any kind of “unsigned” data types. So, how can I make it so I can access the individual bits.
@esklar81: Thats very clever, however it still leaves the problem of "How do I get access to the bits when I cant have unsigned data types? It would seem there is another way, would someone mind explaining?
@gblake: You mean “back in the day” when I learned to write code?
@awri: As gblake implied, it seems appropriate to leave developing (or researching) the means of reading and manipulating individual bits “as an exercise for the student”. Also, as I’ve never programmed in RobotC, I haven’t any notion as to what functions are available to you. That said, it is possible to do the work with relatively simple arithmetic functions and some means of testing whether two quantities are equal.
Eric
Does it allow this?
if ((1 && Word) == 1) Then bit_0 = TRUE;
if ((2 && Word) == 2) Then bit_1 = TRUE;
if ((4 && Word) == 4) Then bit_2 = TRUE;
If the operations are supported, you would obviously want to “parameterize” this example (or research and reuse some more sophisticated method).
You should be able to conveniently pack all of the bits into 100 or fewer four-byte words.
Blake
I apologize, it wasn’t my intention to cheat or anything of that sort. Just trying to get a better understanding of what I should be trying next as to alleviate any wasted time. In retrospect I can see my wording is a bit flawed.
I assume you are meaning to bitwise “and” the numbers and “word”. If that is the case then yes this is allowed. Thus with this (rather large) hint my mind is beginning to formulate a hypothesis for an algorithm to make this work. Looks as if the “splitting” part will take the most creativity here.
Just so you can see what I mean by “usigned types aren’t allowed”, I’ve attached an image of the warning.
