Go Down

Topic: Arduino building process and per-sketch compiler options. (Read 2 times) previous topic - next topic

Coding Badly

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

maniacbug


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: [Select]

LEDClass led(13);

Coding Badly

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.

Sudar

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.
Checkout some of my Arduino projects and tutorials

maniacbug


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: [Select]

#define BUFFER_LENGTH 66
#define TWI_BUFFER_LENGTH 66


And then Wire.h would look like this:
Code: [Select]

#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.

Go Up