Conventions Question

I've just been playing with some basic POV stuff, and in looking at examples, came across an example where a guy wrote out his alphabet with each letter defined by a 35-element array of ints. He ran into trouble at the letter O, having filled up his RAM at that point.

I was defining my message as an array of ints, with each element's bit values determining the on-off state of 8 LEDs. At this rate I could have almost 512 columns, or a little less than 100 characters at 6 columns per character. I realized I could scale this back to an array of bytes, as I only had 8 LEDs to define, and halve the space needed to store my message.

I then started noticing all the other "wasted" ram I was using up on ints. Using ints to hold pin numbers where a byte would do, or again using ints for a for-loop counter that wasn't going past 255. But these I had been doing having learned to do so from the tutorials.

I understand that a handful of ints where bytes would do isn't likely to break a program, that the above example is pretty extreme, and that ints are nice and intuitive. But wouldn't it do the learner some good to be shown such a fundamental concept right from the beginning, by establishing bytes as the convention for storing pin numbers? Even the MEGA doesn't need more than a byte to store a pin number as it's got well fewer than 256 IO pins.

That's just my thought. What are yours?

If you're not going to change the pin #'s at runtime use a #define for them.

that ints are nice and intuitive

But such a variable size... :frowning:

That's just my thought. What are yours?

Just like yours! :slight_smile:

I've made some threads about this in the past actually.
This is one that went kindof overboard. But the reason I created the thread was becuase of my frustration of the monopoly of ints in arduino.

Datatypes are wonderful, embrace them :slight_smile: Hehe.

Hoo, boy, I've been playing with different variable types and values, just to make sure I understand them, and I'm getting odd results. The following:

unsigned long var;

void setup(){
Serial.begin(9600);

var = 2147483647;
Serial.println(var, DEC);

var += 1;
Serial.println(var, DEC);
}

void loop(){}

Gives the output

2147483647
-2147483648

I would expect

2147483647
2147483648

As var is supposed to be an unsigned long. But it seems not to be losing its sign. It's doing this in 0012 and 0016. I have a Duemilanove with a 168. Help?

It looks like the print method that takes the DEC parameter treats the value as a signed long. If you want to print unsigned longs, use Serial.println(var);

Does the 35 ints per letter equate to 35 pixels?

If each pixel only has two states then you should be able to store it in 35 bytes, or 5 bytes.

So your entire alphabet could sit in a 130 byte array.

Coding complexity just went up though. Still sometimes it's fun and vaguely practical to do such things.

mem wrote:

It looks like the print method that takes the DEC parameter treats the value as a signed long. If you want to print unsigned longs, use Serial.println(var);

Hmm, indeed. Take the DECs out, and it works. I put them in because I was getting garbage without them earlier.

edit: fixing quote bbcode

You would need them to print the decimal values of 8 byte variables, but ints and longs will print the decimal value by default.

edit: as AlphaBeta points out, that should say bits not bytes

You would need them to print the decimal values of 8 byte variables, but ints and longs will print the decimal value by default.

I think mem meant to say 8 bit variables. :slight_smile:

Does the 35 ints per letter equate to 35 pixels?

If each pixel only has two states then you should be able to store it in 35 bytes, or 5 bytes.

So your entire alphabet could sit in a 130 byte array.

Coding complexity just went up though. Still sometimes it's fun and vaguely practical to do such things.

Me, I'm using one byte for an eight-LED column of message. I'm not defining an alphabet, so as to be able to do uppercase, lowercase, pictures, whatever, without needing to define everything. I'm using the bitRead function to pull the on-off states. I don't think this function existed for the fellow in the example, at the time he was writing it, but it seems like it wouldn't be too bad to hand-code. Especially if it let you "compress" your alphabet by a factor of 14.

Just store your array in EEPROM.