Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add -DBOARD_NAME="{build.board}" #136

Merged
merged 1 commit into from
May 16, 2021
Merged

Add -DBOARD_NAME="{build.board}" #136

merged 1 commit into from
May 16, 2021

Conversation

khoih-prog
Copy link
Contributor

Add -DBOARD_NAME="{build.board}" to Compile patterns to facilitate using BOARD_NAME in sketches

For example

void setup() 
{ 
  // Open serial communications and wait for port to open:
  Serial.begin(115200);
  while (!Serial);

  Serial.print("Ethernet Test on "); Serial.println(BOARD_NAME);
}
void loop() 
{
}

to print

Ethernet Test on RASPBERRY_PI_PICO

Add -DBOARD_NAME="{build.board}" to Compile patterns to facilitate using BOARD_NAME in sketches
@per1234
Copy link
Contributor

per1234 commented May 16, 2021

@khoih-prog is the BOARD_NAME macro name an established convention?

If not, I'm wondering if it would be better to use the ARDUINO_ prefix, as is done for -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch}. This creates a "namespace" of sorts for the platform-generated macros to avoid name collisions with macros defined elsewhere, which is especially likely with globally defined macros. On the other hand, maybe it's a bit odd to use the ARDUINO_ for macros which don't have a precedent in the official platforms?

@khoih-prog
Copy link
Contributor Author

The BOARD_NAME has been used in the STM32 core

platform.txt #L93)

# Build information's
build.info.flags=-D{build.series} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DBOARD_NAME="{build.board}" -DVARIANT_H="{build.variant_h}"

If we need to display which board we're using (for example, for library/core writer to know if the user uses or selects the correct board) It's better than we have to use harder way

#if defined(ARDUINO_SAMD_MKR1000)
  #define BOARD_NAME      "SAMD_MKR1000"
#endif

#if defined(ARDUINO_RASPBERRY_PI_PICO)
  #define BOARD_NAME      "RASPBERRY_PI_PICO"
#endif

This way, users has to know how to access board.txt to know

rpipico.build.board=RASPBERRY_PI_PICO

to use -DARDUINO_{build.board} => #if defined(ARDUINO_RASPBERRY_PI_PICO)

while using BOARD_NAME, users don't have to know anything about board.txt and platform.txt


This is very minor and not important feature, just good to have.

@khoih-prog
Copy link
Contributor Author

khoih-prog commented May 16, 2021

One more note is that in ArduinoCore-mbedcore, we have the similar BOARD_NAME definition @ pins_arduino.h #L67

#define BOARD_NAME			"RaspberryPi Pico"

@per1234
Copy link
Contributor

per1234 commented May 16, 2021

The BOARD_NAME has been used in the STM32 core

in ArduinoCore-mbed, we have the similar BOARD_NAME definition

Thanks for the clarification. That is a fairly significant precedent, which I was not aware of. This sort of thing is most valuable when done consistently across the ecosystem, so I think you made the right choice.

Ideally, there would be a formal official definition of these standards. There is (in my biased opinion) currently pretty good documentation about the platform components which are required or provided automatically by the build system, but essentially no formal documentation about the recommended/expected components (arduino/arduino-cli#985), which means there is not a very good mechanism for documenting the current standards or proposing new ones. Currently the approach is to just analyze what has been done in the official platforms.

This is very minor and not important feature, just good to have.

I fully understand the motivation behind the proposal and why -DARDUINO_{build.board} is not an effective substitute in the use cases for BOARD_NAME.

@khoih-prog
Copy link
Contributor Author

khoih-prog commented May 16, 2021

@per1234

no formal documentation about the recommended/expected components

there is not a very good mechanism for documenting the current standards or proposing new ones.

That's something waiting for you, as an long-time insider, to propose and make change.

@earlephilhower
Copy link
Owner

Don't we need some escape magic to get this define as a quoted string? I think bash/cmd will just eat the quotes in platform.txt while parsing out args to the compiler.

@khoih-prog
Copy link
Contributor Author

I haven't seen any issue yet. This way has been used and tested in several platforms and OSes without any problem.

@earlephilhower
Copy link
Owner

Ok, thx!

@earlephilhower earlephilhower merged commit b504fea into earlephilhower:master May 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants