#if defined variables

Using Arduino Programming Questions
1

@pert

Where are these variables defined. I look in boards.txt or nano.variables portenta.variables but the defined words don't work it is these weird words that have ARDUINO_ in front of them.

void setup() {
  // put your setup code here, to run once:
   Serial.begin(115200);
}

void loop() {



  #if defined(ARDUINO_ARDUINO_NANO33BLE)   ||  defined (YOUR_BOARD1) 
      Serial.println("Your board is defined as ARDUINO_ARDUINO_NANO33BLE");
  #endif

  
  #if defined(ARDUINO_NANO33BLE)   ||  defined (YOUR_BOARD1) 
      Serial.println("Your board is defined as ARDUINO_NANO33BLE");    // does not print
  #endif


  
  #if defined(PORTENTA_H7_M7)   ||  defined (YOUR_BOARD1) 
      Serial.println("Your board is defined as PORTENTA_H7_M7");   // does not print
  #endif

  
  #if defined(ARDUINO_PORTENTA_H7_M7)   ||  defined (YOUR_BOARD1) 
      Serial.println("Your board is defined as ARDUINO_PORTENTA_H7_M7");
  #endif

  
  #if defined(CORE_CM7)   ||  defined (YOUR_BOARD1) 
      Serial.println("Your board is defined as CORE_CM7");
  #endif



  Serial.println("---------------------");
  delay(1000);
  // put your main code here, to run repeatedly:

}
2
1 Like
3

Hi @jerteach. The -D flags that define these macros are in the compilation command patterns in the platform's platform.txt file here:

The ARDUINO_ARCH_MBED macro is hardcoded there in the command pattern.

The flags for the other Arduino_* macros use references to properties:

The build.arch property referenced in the -DARDUINO_ARCH_{build.arch} flag is automatically defined by the Arduino build system. The value of this property is the name of the architecture folder of the platform installation. In the case of platforms installed via Boards Manager, that folder is named according to the packages[*].platforms[*].architecture field of the package index.

The -DARDUINO_ARCH_{build.arch} flag might seem redundant to the -DARDUINO_ARCH_MBED flag. However, it is not because the Arduino Mbed OS boards platform has been split into a separate architecture for each of the logical board families. For example, when compiling for the Portenta H7 board, this will cause the definition of an ARDUINO_ARCH_MBED_PORTENTA macro because the architecture of the "Arduino Mbed OS Portenta Boards" platform is mbed_portenta.

The build.board property referenced in the -DARDUINO_{build.board} flag is defined in the platform's boards.txt file. For the Portenta H7, it is here:

https://github.com/arduino/ArduinoCore-mbed/blob/4.0.6/boards.txt#L88

envie_m7.build.board={build.variant}

The definition of that property references yet another property: build.variant, which is defined here if you have "Main Core" selected from the Tools > Target core menu in Arduino IDE:

https://github.com/arduino/ArduinoCore-mbed/blob/4.0.6/boards.txt#L71

envie_m7.menu.target_core.cm7.build.variant=PORTENTA_H7_M7

and here if you have "M4 Co-processor" selected from that menu:

https://github.com/arduino/ArduinoCore-mbed/blob/4.0.6/boards.txt#L77

envie_m7.menu.target_core.cm4.build.variant=PORTENTA_H7_M4
2 Likes
4

@kolaha and @ptillisch thanks for the detailed explanation, what I think I hear you saying is that just add "ARDUINO_" to any of the defined words. Which is what I am seeing with my code above.

so the defined word "ARDUINO_NANO33BLE" becomes

"ARDUINO_ARDUINO_NANO33BLE"

Is that correct, because that is what works in the above sketch.

5

That is not what I am saying. I think I explained the origin of those ARDUINO_* macros fairly well in my previous reply. If there is something specific you don't understand about what I wrote, let me know and I'll see if I can make it more clear.

As for the defines.txt files mentioned by kolaha, these are simply a list of -D flags that are added to the compilation commands using the @<file> argument:

https://github.com/arduino/ArduinoCore-mbed/blob/4.0.6/platform.txt#L21

compiler.c.flags=-c {compiler.warning_flags} -g3 -nostdlib "@{compiler.mbed.defines}" "@{compiler.mbed.cflags}" {compiler.mbed.arch.define} -MMD -mcpu={build.mcu} {build.float-abi} {build.fpu}

https://github.com/arduino/ArduinoCore-mbed/blob/4.0.6/platform.txt#L27

compiler.cpp.flags=-c {compiler.warning_flags} -g3 -nostdlib "@{compiler.mbed.defines}" "@{compiler.mbed.cxxflags}" {compiler.mbed.arch.define} -MMD -mcpu={build.mcu} {build.float-abi} {build.fpu}

https://github.com/arduino/ArduinoCore-mbed/blob/4.0.6/boards.txt#L98

envie_m7.compiler.mbed.defines={build.variant.path}/defines.txt

ARDUINO_ is not prefixed to the macros defined by the -D flags in the defines.txt files. They are defined exactly as written in that file, just as they would be if you added the flags to a compiler command you invoked directly..

I explained it already in my previous reply.

The command pattern contains this flag: -DARDUINO_{build.board}.

The "Arduino Nano 33 BLE" board definition sets the build.board property referenced in the command pattern to ARDUINO_NANO33BLE:

https://github.com/arduino/ArduinoCore-mbed/blob/4.0.6/boards.txt#L236

nano33ble.build.board=ARDUINO_NANO33BLE

Put it together and you get a macro named ARDUINO_ARDUINO_NANO33BLE.

But if the flag in the command pattern had been -DFOO__{build.board} and the board definition had set the value of the build.board property to BAR, then the macro would instead be named FOO_BAR.

There is no magical arbitrary addition of an ARDUINO_ prefix. It is simply a common convention used to create a "namespace" of sorts for the macros in order to reduce the chance of name collisions with macros defined elsewhere. The platform developer has complete control over the definition and naming of such macros.

1 Like
6

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.