pass board type from boards.txt

[GoogleCodeExporter]

What change would like to see?

Something that I think is desperately needed is a way to pass a #define from 
the boards.txt file to the compiler.
For example

    arduino.build.define=BOARD_MEGA1280

And allow for as many of these, then would then be passed to the compiler as 
-DBOARD_MEGA1280

Why?

There are many boards that use the same CPU but have different capabilities. 
This would allow easier pre-processing in the various files

Would this cause any incompatibilities with previous versions?  If so, how
can these be mitigated?

No issues at all.

Original issue reported on code.google.com by mark.l.s...@gmail.com on 30 Jul 2010 at 5:41

[GoogleCodeExporter]

The type of code that needs to be refactored is in two places in Compiler.java. 
Options that code be broken out are gloomed together in one string. For example:

  static private List getCommandCompilerCPP(String avrBasePath,
    List includePaths, String sourceName, String objectName) {
      List baseCommandCompilerCPP = new ArrayList(Arrays.asList(new String[] {
      avrBasePath + "avr-g++",
      "-c", // compile, don't link
      "-g", // include debugging info (so errors include line numbers)
      "-Os", // optimize for size
      "-w", // surpress all warnings
      "-fno-exceptions",
      "-ffunction-sections", // place each function in its own section
      "-fdata-sections",
      "-mmcu=" + Preferences.get("boards." + Preferences.get("board") + ".build.mcu"),
      "-DF_CPU=" + Preferences.get("boards." + Preferences.get("board") + ".build.f_cpu"),
    }));

You can totally get the values you want, but they are all jammed into a giant 
string. I would recommend breaking out the flags, and allowing for them to be 
set in the boards.txt to make what your trying to do easier.

Has anyone else tried to break this apart?

Original comment by rick.rickanderson on 5 Aug 2010 at 12:30

[GoogleCodeExporter]

Another chunk of code with same issue in Compiler.java.

    List baseCommandLinker = new ArrayList(Arrays.asList(new String[] {
      avrBasePath + "avr-gcc",
      "-Os",
      "-Wl,--gc-sections",
      "-mmcu=" + Preferences.get("boards." + Preferences.get("board") + ".build.mcu"),
      "-o",
      buildPath + File.separator + sketch.name + ".elf"
    }));

Original comment by KLAb...@gmail.com on 5 Aug 2010 at 12:40

[GoogleCodeExporter]

Issue 912 has been merged into this issue.

Original comment by dmel...@gmail.com on 18 May 2012 at 7:31

[GoogleCodeExporter]

Are there things you need to know about the board that we can't handle through 
additional #defines or other macros or variables in the variants header files?  
That seems like a more flexible solution because it doesn't require the library 
files (or core or whatever) to know about the specific boards (which are 
potentially limitless) but instead it can just use the relevant piece of 
information for a given situation.

Original comment by dmel...@gmail.com on 18 May 2012 at 7:33

[GoogleCodeExporter]

@David - Not sure who you're replying to, but board-specific data / defines in 
the variant's header would be fine for my needs. The only case I've needed it 
for is when a library depends on a board-specific feature, such as a custom pin 
map (they hardcode for their own FasterDigitalWrite() instead of using the 
supplied pin map), or specific hardware (RTC, power management signals) which 
could be used if-available by a library designed for it, and degrade gracefully 
if used on a board without that hardware.

(The mechanism (variant files) exists since 1.0; my merged ticket was just 
asking for the Arduino team to *do it*  (#define boardtype) for the official 
variants and set a standard, and hopefully other developers will follow suit.)

One related thing that would be really helpful is the ability for #defines in 
one *library* to be visible from another, so library A can make use of library 
B if available (e.g. #ifdef libPinChangeInt {sleep for pin change} #else 
{software spinloop for pin change}). But, that's likely a separate issue 
(similar goal, but very different implementation under the hood, and I'm not 
sure if it's feasible anyway :-)

PS. Thanks for Arduino!

Original comment by drmn...@gmail.com on 3 Jun 2012 at 6:52

[GoogleCodeExporter]

This was introduced in 1.5.3, the symbol available at compile time is:

ARDUINO_{board}

for example the Arduino Uno will have:

ARDUINO_AVR_UNO

The value is defined through the build.board key in boards.txt:

https://github.com/arduino/Arduino/blob/8e7133eaaccb2463da22169915d6c4ae5e0ba3bc
/hardware/arduino/avr/boards.txt#L62

Original comment by c.mag...@arduino.cc on 19 Sep 2013 at 5:18

• Changed state: Verified