I haven't bought an Arduino yet. I can't decide between a microcontroller or a microcomputer.
Anyway, I've been wondering how the hardware addresses X, Y, Z coordinates. Say that someone wanted to build an LED cube & wanted to illuminate a single LED in the center of the cube. Would the software have to specify an X, Y, Z coordinate in order to illuminate the single LED? How would that work?
I've been thinking about how to do that & I have an idea. I don't know if this is how it is done or not. If one wants to build a 4x4x4 LED cube, that's 64 LEDs when you multiply 4x4x4. One could wire up an 8x8 matrix. It can be "broken down" into four 4x4 sub-matrices. Is that how it is done?
Anyway, I've been wondering how the hardware addresses X, Y, Z coordinates.
It doesn't. Coordinates are a software concept.
Say that someone wanted to build an LED cube & wanted to illuminate a single LED in the center of the cube. Would the software have to specify an X, Y, Z coordinate in order to illuminate the single LED?
No. The software would have to set the correct pins, based on the row, column, and level.
Say that someone wanted to build an LED cube & wanted to illuminate a single LED in the center of the cube. Would the software have to specify an X, Y, Z coordinate in order to illuminate the single LED? No. The software would have to set the correct pins, based on the row, column, and level.
OK. That helps. So, it's still sort of an X, Y Z coordinate system. X & Y for the row & column & Z for the level. I'll have to spend more time watching the YouTube videos. Soon, I will get an Arduino or something.
An 8x8 matrix does not have any obvious logical mapping to a 4x4x4 cube, so that would be a bad choice. It would just confuse you.
A somewhat better choice would be to consider single 4x4 layer of the leds in the cube. You could number those leds 1 to 16 ( or 0 to 15 ). You would then have four of those layers, so your data structure would be 16x4 . Those layers could be horizontal or vertical slices.
An 8x8 matrix does not have any obvious logical mapping to a 4x4x4 cube, so that would be a bad choice. It would just confuse you.
I agree that it would not be logical & would be confusing. Columns 0 to 3 & rows 0 to 3 make up one 4x4 sub-matrix. Columns 4 to 7 & rows 0 to 3 make up another sub-matrix. Columns 0 to 3 & rows 4 to 7 make up another sub-matrix. Columns 4 to 7 & rows 4 to 7 make up another sub-matrix.
I'm just trying to think of alternatives to row, column & level. It might be more confusing to program than to use row & column & level.
Say that someone wanted to build an LED cube & wanted to illuminate a single LED in the center of the cube. Would the software have to specify an X, Y, Z coordinate in order to illuminate the single LED?
Well, it COULD. But there is no obvious hardware that understands "X, Y, Z", so probably the software has to continue onward to converting that XYZ into something else that the hardware DOES understand.
In a hypothetical trivial 444 led cube, you could have each LED addressed individually, 0 to 63, and you could covert XYZ to LEDnumber with a simple lookup table:
byte LEDnumber[4][4][4] = { ... };
For a more practical setup, your LEDs might be wired in an 8x8 multiplexed arrangement. Then you would need to convert XYZ to a row number and a column number that match the wiring:
There's a logical mapping from 8x8 to a 4x4x4 cube - think recursion and oct-tree encoding.
I've heard of oct-trees & I understand recursion but how does one code oct-trees? With an array? Please elaborate on how one recurses from 8x8 to 4x4x4.
A more complicated scheme might translate XYZ into driver chip address, port and bit numbers...
With the Arduino?
OK. I've got a good question for you. Let's say that I wanted to arrange LEDs into a sphere. To keep it simple, it's only one layer of LEDs. Not nested spheres. I'd still use an XY matrix, but how would I illuminate a single LED or LEDs opposite one another or a row or column of LEDs representing the diameter?
Let's say that I wanted to arrange LEDs into a sphere. I'd still use an XY matrix, but how would I illuminate a single LED or LEDs opposite one another or a row or column of LEDs representing the diameter?
Well, the "natural" schemes for spheres would be your mathematical spherical coordinates (R, theta, phi: radius and two angles, and maybe a stack of rings (R, Theta, Z.) For one shell, R would disappear. This makes calculations like "opposite" simple (well, "traditional geometrey", anyway. It can be a little unnerving how fast simple geometry gets mathematically complex.)
LED2 = (Rled1, ThetaLED1 + PI, PhiLED1 + PI), I think.
For an AVR and moderate numbers of LEDs, you'd probably want to rescale everything into integers with 2*PI = 256.
One of the key points is that there are essentially two ways to transform "virtual" coordinates into real-life info. One way is to use some sort of algorithm: For example, you can go from 4x4x4 to 8x8 just by taking each of the two bits used for the Z coordinate and tacking it on to X and Y:
The other way is to use a table. Tables can be bigger, and might be slower (depending on the complexity of the algorithm, and the complexity of your initial coordinates, and ... stuff.) But once you're using a table (and it fits), your transformation becomes completely arbitrary. Made a mistake and swapped two LEDs in your physical construction? You can fix that in the tables...
Macnerd:
I agree that it would not be logical & would be confusing.
I am tempted to say that you think that because you are a beginner. Anyway you are very wrong.
You do not need to hold this mapping in your head, the lookup table does it for you, then you simply drive the device with the coordinates that you let you express what you want.
As an example of this look at my Hexome project:- http://www.thebox.myzen.co.uk/Hardware/Hexome.html
If you down load the code and the manual you will see there are several coordinate systems implemented for making the operating of it simple.
The translation between the system you want to use and the real underlying hardware is something that you should not have to worry about once you have built the system. It is not a day to day concern.
For your sphere example again you have your own coordinate system, perhaps latitude and longitude expressed by two angles in the center of the sphere. Then a look up table translates this into the x - y matrix for you.
Wow! The math for spherical coordinates is complicated! Can the Arduinos handle the math or is the task more suited for a microcomputer than a micro-controller? I can imagine what the code is like to map the spherical coordinates to the pins on the micro-controller.
Macnerd: There's a logical mapping from 8x8 to a 4x4x4 cube - think recursion and oct-tree encoding.
I've heard of oct-trees & I understand recursion but how does one code oct-trees? With an array? Please elaborate on how one recurses from 8x8 to 4x4x4.
oct trees have 8 slots for the 8 octants of a 2x2x2 cube. A 4x4x4 cube is 8 2x2x2 cubes
arranged in a 2x2x2 cube, so the addressing scheme uses 1 3 bit index to select the
sub-cube, the next to pick the LED from the sub-cube using the same indexing convention.
A more complicated scheme might translate XYZ into driver chip address, port and bit numbers...
With the Arduino?
OK. I've got a good question for you. Let's say that I wanted to arrange LEDs into a sphere. To keep it simple, it's only one layer of LEDs. Not nested spheres. I'd still use an XY matrix, but how would I illuminate a single LED or LEDs opposite one another or a row or column of LEDs representing the diameter?