next topic »

[on:]

    Hello everyone,

I'm an electronics & microcontroller newbie but do have a decent coding background. Something that I am used to doing, is using defines for configuration values that only need to be set at compile-time. Imagine, for simplicity, that I have a "LED" class and I want to be able to override the default LED_PIN on a per-sketch basis -- you can imagine something like this in the relevant .h file:

Code:

#ifndef LED_PIN
#define LED_PIN 13
#endif

...and wanting to compile that with a -DLED_PIN=7 for situations that require it.

I don't like to reserve variables for a thing that does not change and is really only used once. (I'm old school and prefer small memory footprints.)

I searched through the Arduino IDE (v0022) code, but there seems to be no facility to actually pass some CFLAGS down to the command that compiles the library .cpp file.

Simplest solution seemed to hack Sketch.java to include a getCompilerFlags() routine and Compiler.java to call it, so it'll search for a "cflags.txt" file in the sketch's folder, read that file's contents, and pass that as-is appended to the compile commands. (A hacky 5m job -- but it works like a charm.)

Now, having just done this; I wonder if I just re-invented the wheel [I am known to do that].

Perhaps there are existing enhancements or patches available that already accomplish the same, in a more elegant manner?

Also, I am "happily unaware" of any unexpected consequences this change could have, although it does seem that every time a sketch compiles, the libraries are also re-compiled, so it seems safe. Or is there perhaps something that I really should know?

Thanks for your time!

[Reply #1 on:]

Now, having just done this; I wonder if I just re-invented the wheel [I am known to do that].

Sort of.  A similar feature is planned for "Arduino 1.0".  The plan is to allow CFLAGS to be defined in boards.txt.  Selecting a different board would potentially select a different set of CFLAGS.

Perhaps there are existing enhancements or patches available that already accomplish the same, in a more elegant manner?

I'm not aware of any.

Also, I am "happily unaware" of any unexpected consequences this change could have, although it does seem that every time a sketch compiles, the libraries are also re-compiled, so it seems safe. Or is there perhaps something that I really should know?

Seems like a reasonably good solution to me.

[Reply #2 on:]

CB, what's "Arduino 1.0"

______
Rob

[Reply #3 on:]

The first official release of the Arduino IDE.  And the irony of having 22 versions already released is not lost on me.

[Reply #4 on:]

So just curious...  If you're ok with cflags.txt in sketch dir, why not config.h and put your defines in there??

[Reply #5 on:]

How would a library source file include "config.h" from the Sketch directory?

[Reply #6 on:]

How would a library source file include "config.h" from the Sketch directory?

Oh I see, I didn't read the OP carefully enough.  He wants to override the LED value on a per-sketch basis for a LIBRARY.  Using cflags for that seems especially convoluted.  The way I'd consider 'normal' for this is to let the LED class take a constructor parameter for which pin it is.  Then when he declares his LED in the sketch, pass it along.

Code:

LEDClass led(13);

[Reply #7 on:]

The side-effect is bigger slower code.  For an application that is teetering on the Flash limit or is especially time critical, being able to trim and optimize library code can make a huge impact.

Another example... Applications that minimize power consumption are common.  The analog-to-digital converter is a big power consumer.  Currently, for an application that does not use the analog-to-digital converter, it must be disabled in the Sketch (setup).

A much better solution is to simply not enable the analog-to-digital converter.  Currently, this can only be accomplished by directly modifying the code in wiring.c.  I'm sure you can imagine the problems this could cause for the developer.  If the analog-to-digital initialization code is wrapped in a conditional compile and hugo75's modification is made to the IDE, the developer need only create a cflags.txt file.

[Reply #8 on:]

I have another use-case where providing cflags support would really help. Details at http://arduino.cc/forum/index.php/topic,58660.0.html

@hugo75
While we wait for "Arduino 1.0", have you uploaded the patched jar somewhere, which I can use without setting up Java and trying the compile the code myself? Thanks.

[Reply #9 on:]

For an application that is teetering on the Flash limit or is especially time critical, being able to trim and optimize library code can make a huge impact.

I've been thinking more about this lately...  If an application is teetering on the flash limit or needing to shave a few instruction cycles, or optimizing library code, I suggest that it's time for that application writer to graduate from the IDE and move to a makefile.  There, a whole universe of configuration options await.  Arduino's brilliance is its simplicity.

On the other hand, now that I've been writing more libraries, I find plenty of times where it would be useful give a regular user some control over how the library is consumed.  So to do this well, I would approach from the angle of, "How could the system let library designers give users of all experience levels the ability to configure their libraries?"

One idea is to allow a file named for the library in the current sketch directory, which is included at the top of each compilation unit in that library.  For example, I like to tune the I2C buffer length used by the Wire library.  So I might have...

Wire.txt:

Code:

#define BUFFER_LENGTH 66
#define TWI_BUFFER_LENGTH 66

And then Wire.h would look like this:

Code:

#ifndef BUFFER_LENGTH
#define BUFFER_LENGTH 32
#endif

By using the code users are already used to writing, they don't have to learn a whole new syntax (command line options).

Alternately, the IDE could go the route of most IDE's and have a project file, in which configuration settings are saved, and then add UI screens to change them.  The project file could be made optional.