[SOLVED]Shortening code...

Is there anyway to shorten your code?
Im making a Led matrix and would like to shorten

digitalWrite(ledPin2, HIGH);

into someting like this...

led2on

or

led2on;

I have tried using define and even though it would compile the led wouldn't turn on... >:(

EDIT: I would be happy to get a source that has something like this that i can modify

What you are looking for are called functions.

You can replace repeated sections of code with a function.

Gordon

Thank you! :smiley:

I have tried using define and even though it would compile the led wouldn't turn on...

Using #define should have worked, presuming that you got the #define statement right.

That it did not is proof that you didn't. Post the code, and we'll help you figure out what was wrong.

Functions are useful, but #define statements are processed before the compiler runs, so the resulting overhead of a function call (very small though it is) is avoided.

You can always declare a function as "inline". Then it should compile like a macro. With the additional benefit of type safety.

Unless of course the IDE messes with the prototypes.

Udo

ok so i decided to use functions but it did not make my project smaller it got bigger in fact by about 500 bytes

I would post the before and after codes but it doesnt fit in this box...

I ordered a atmega328 a few days ago so once i get it size wont matter, im almost at the max size fore a 128. at least it will be easier to code thank you guys for your help... :slight_smile:

1. Create a new sketch.
Paste this in. This is the original Blink sketch

int ledPin =  13;    // LED connected to digital pin 13

void setup()
{                
  pinMode(ledPin, OUTPUT);     
}
void loop()                     
{
  digitalWrite(ledPin,HIGH);
  delay(1000);
  digitalWrite(ledPin,LOW);
  delay(1000);
}

Compile it and run it. The LED blinks, as expected, and in Arduino I see
Binary sketch size: 896 bytes (of a 30720 byte maximum)

2. Create a new sketch.

Past in the following. This is a macroized Blink sketch:

#define ledon  digitalWrite(ledPin,HIGH)
#define ledoff digitalWrite(ledPin,LOW)

int ledPin =  13;    // LED connected to digital pin 13

void setup()   {                
  pinMode(ledPin, OUTPUT);     
}

void loop()                     
{
  ledon;
  delay(1000);
  ledoff;
  delay(1000);
}

Compile it and run it. The LED blinks, as expected, and in Arduino I see
Binary sketch size: 896 bytes (of a 30720 byte maximum)

3. Create a new sketch.

Past in the following. This is a functionalized Blink sketch:

int ledPin =  13;    // LED connected to digital pin 13

void setup()
{                
  pinMode(ledPin, OUTPUT);     
}
void loop()                     
{
  ledOn();
  delay(1000);
  ledOff();
  delay(1000);
}

inline void ledOn(void)
{
  digitalWrite(ledPin,HIGH);
}
inline void ledOff(void)
{
  digitalWrite(ledPin,LOW);
}

Compile it and run it. The LED blinks, as expected, and in Arduino I see
Binary sketch size: 896 bytes (of a 30720 byte maximum)

So they all "work" the same. (Of course if you are using a '168 instead of a '328, the maximum memory allowed will be less, but the three will be the same size.)

Furthermore...

The code created by the compiler is exactly the same in all three cases. (Yes, exactly.) Same size, same performance. Exactly.

Which do you prefer? It's your program and your decision.

In other words: Chacun à son goût.

Regards,

Dave

Thanks dave I got it to work already but im going to use your example of define instead of functions.

Heck,if you like macros, why not go macro-all-the-way:

#define ledon  digitalWrite(ledPin,HIGH)
#define ledoff digitalWrite(ledPin,LOW)
#define wait_a_second delay(1000);

int ledPin =  13;    // LED connected to digital pin 13

void setup()
{                
  pinMode(ledPin, OUTPUT);    
}

void loop()                    
{
  ledon;
  wait_a_second;
  ledoff;
  wait_a_second;
}

Now the loop() function is self-documenting and doesn't even look like C or C++ code.

Hmmm...
Is that a blessing? (loop() is self documenting---once you know that the macros are correct, the loop code itself is easily determined to be "correct at a glance..")

Or is it a curse? (loop() doesn't look like a program---may anger the gods of C++, and you really (really) don't want to annoy the gods, right?)

Regards,

Dave

For a very short sketch like this a function wont save very much.
but as your code gets longer abstracting your code into functions will help and make it easier to maintain and extend.

Modifying Daves example:

int ledPin =  13;    // LED connected to digital pin 13

void setup()
{                
  pinMode(ledPin, OUTPUT);    
}
void loop()                    
{
  ledState(HIGH);
  ledState(LOW);
}

void ledState(boolean state)
{
  digitalWrite(ledPin,state);
  delay(1000);
}

Binary sketch size: 888 bytes (of a 30720 byte maximum)
A saving of 8 bytes in this very short example.
As your sketch gets longer the savings will increase with the complexity of your code.

int ledPin1 =  13;    // LED connected to digital pin 13
int ledPin2 =  12;    // LED connected to digital pin 12

void setup()
{                
  pinMode(ledPin1, OUTPUT);
  pinMode(ledPin2, OUTPUT);  
}
void loop()                    
{
  ledState(ledPin1, HIGH);
  ledState(ledPin1, LOW);
  
  ledState(ledPin2, HIGH);
  ledState(ledPin2, LOW);
  
}

void ledState(int ledPin, boolean state)
{
  digitalWrite(ledPin,state);
  delay(1000);
}

Binary sketch size: 938 bytes (of a 30720 byte maximum)
Here we now have 2 led's changing state and one function handling both led's.

Instead of

int ledPin1 =  13;    // LED connected to digital pin 13
int ledPin2 =  12;    // LED connected to digital pin 12

void setup()
{                
  pinMode(ledPin1, OUTPUT);
  pinMode(ledPin2, OUTPUT);  
}
void loop()                    
{
  digitalWrite(ledPin1,HIGH);
  delay(1000);
  digitalWrite(ledPin1,LOW);
  delay(1000);
  digitalWrite(ledPin2,HIGH);
  delay(1000);
  digitalWrite(ledPin2,LOW);
  delay(1000);
}

Binary sketch size: 952 bytes (of a 30720 byte maximum)

So we saved 14 bytes over this non function code.

When you get a bit more confident with coding look up refactoring and abstraction methods.

Gordon

If you would go for direct port manipulation this would most likely shorten the code a lot.

The comments on why this is a bad idea do not apply if you wrap these manipulations in meaningful functions. If you define them as inline, then you get the best of both worlds.

Udo