I am working on a project that is a rudimentary form of motion tracking or proximity detection. Short form is that it outputs a visual display to a LED matrix (10x10).
The point is that I'm working on a code that uses arrays of unsigned int's and bitWrite and bitRead functions to condense the memory occupied by each of the arrays, and i was looking to see if anyone else had experimented with this.
Anyways the code is too long to post in this window, so I've attached it as a .txt file.
The current version (1.0) of this compiles using only 6,282 bytes program space and 336 bytes of dynamic memory. Which is fairly impressive considering it contains at least 3 or 4 100 character arrays.
Unfortunately, I wont have the whole thing running for about another week, and i haven't ran this (version) yet to see how well it works or how epically it fails.
Whenever you number variables x1, x2, x3 and so on, I wonder why you don't replace those different variables with an array. So, in general, where you are doing that.
In general i have tried to avoid using arrays of int type since each declared value within the array then contains 16 bits of memory space.
If each variable in the array is an int type with 16 bits @ 10 per array * 10 arrays to store the data from one 10x10 matrix it runs to 1600 bits per matrix.
Where as using this method i am able to define the entire 10x10 matrix within an array (which is used for addressing) of 10 unsigned ints each occupying 16 bits.
The major difference is that each bit in the variables x0, x1, ... xn corresponds to a matrix address vs having an int type of 16 bits do the same thing.
I have used some arrays throughout the code to index the variables, however that section was declaring constant values for use in the xy coordinate comparator (which i wrote early on and will likely revise to increase speed).
The other main reason for trying to compress the data is to increase communication speed, since i will be using another arduino to control the physical led matrix.
lol. it would be simpler. I wanted to compare the bit arrays (which i think i can do with bitwise& rather than the declared comparitor) rather than directly writing to it.
Although if i declared a function to write to Matrixn(x,y) it would clear that code up a lot. Probably cut it in half. Good point thanks for the idea.
I use exactly that method in the matrix keypad library. Several people have used the library to implement 101 key keyboards and another used it to decode and array of 192 relays. Memory usage is a scant few bytes and relative to the physical world it is very fast.
However, you must take care not to impede it by the use of delays() anywhere else in your code. Also, be careful of loops (both while and for) which can make your bit-matrix reads/writes seem sluggish.
Awesome, thanks for the example. I can see how adding a subroutine to bitWrite to the (x,y) would clear this up. It would also remove the for loops im using to write values. Which is pretty much pointless now that i think about it.
Since i set the yNew to 0 at the end of every cycle there is no point in using for loops to write from 0 to n bits with value 0 until i write the 1 value that actually matters.
christrevisiol:
Since i set the yNew to 0 at the end of every cycle there is no point in using for loops to write from 0 to n bits with value 0 until i write the 1 value that actually matters.
Exactly. So this is one case where adding code could actually speed things up. By testing for a 1 in call_addressing_WRT() before calling bitWrite you eliminate all the 0 writes.
You could also use a variation of the same method in call_comparitor(). If it makes sense you can directly compare the values of yNew and yLST before deciding if you even want to do a bit-for-bit comparison.
Most of them implement the plot(x,y) sort of function for the convenience of the "application" code, and some sort of bulk byte-wide access for actually dumping to the display.