Skip to content

Conversation

@per1234
Copy link
Contributor

@per1234 per1234 commented Dec 4, 2025

Motivation

When a new App is generated, it contains a sketch which in turn contains a build profile. Previously, the fqbn key of this build profile was set to arduino:zephyr:unoq. Since the build profile is indeed used to control the dependencies of the sketch, the user would be led to also believe that the FQBN specified in the build profile is used when compiling and uploading the sketch. This is not so. An FQBN is instead hardcoded into the compilation and upload code (#12):

Fqbn: "arduino:zephyr:unoq",

Fqbn: "arduino:zephyr:unoq:flash_mode=ram",

This means the fqbn key in the build profile has absolutely no effect.

The obvious problem with this is that it will lead the advanced user to believe they can configure the FQBN used by App Lab via the fqbn key of the build profile. For example, they might wish to use the arduino:zephyr:unoq:flash_mode=flash,wait_linux_boot=no FQBN (arduino/ArduinoCore-zephyr@8119c2b) in cases where the sketch code is not reliant on the immediate availability of the Linux machine and they do not wish for the execution of the sketch program to be delayed after power on.

Even more confusing is the fact that the arduino:zephyr:unoq:flash_mode=ram FQBN used when uploading is different from the FQBN the default build profile would lead the user to believe is in use (since the default value of the flash_mode custom board option is flash NOT ram, and thus the arduino:zephyr:unoq used in the template is equivalent to arduino:zephyr:unoq:flash_mode=flash).

Change description

Remove the unused and misleading fqbn key from the generated build profile. This will better communicate the actual situation to the user.

Additional Notes

Related: https://forum.arduino.cc/t/issues-witho-monitor-and-bridge/1416857

Reviewer checklist

  • PR addresses a single concern.
  • PR title and description are properly filled.
  • Changes will be merged in main.
  • Changes are covered by tests.
  • Logging is meaningful in case of troubleshooting.

@per1234 per1234 requested a review from lucarin91 December 4, 2025 05:39
@per1234 per1234 added the enhancement New feature or request label Dec 4, 2025
@per1234 per1234 changed the title Remove misleading fqbn key from sketch build profile of new App template feat: Remove misleading fqbn sketch build profile key from App template Dec 4, 2025
…late

When a new App is generated, it contains a sketch with a sketch project file that defines a build profile . Previously,
the `fqbn` key ofthis build profile was set to `arduino:zephyr:unoq`. Since the build profile is indeed used to control
the dependencies of the sketch, the user would be led to also believe that the FQBN specified in the build profile is
used when compiling and uploading the sketch. This is not so. An FQBN is instead hardcoded into the compilation and
upload code, meaning the `fqbn` key in the build profile has absolutely no effect.

The obvious problem with this is that it will lead the advanced user to believe they can configure the FQBN used by App
Lab via the `fqbn` key of the build profile. For example, they might wish to use the
`arduino:zephyr:unoq:flash_mode=flash,wait_linux_boot=no` FQBN in cases where the sketch code is not reliant on the
immediate availability of the Linux machine and they do not wish for the execution of the sketch program to be delayed
after power on.

Even more confusing is the fact that the `arduino:zephyr:unoq:flash_mode=ram` FQBN used when uploading is different from
the FQBN the default build profile would lead the user to believe is in use (since the default value of the `flash_mode`
custom board option is `flash` NOT `ram`, and thus the `arduino:zephyr:unoq` used in the template is equivalent to
`arduino:zephyr:unoq:flash_mode=flash`).

Removing the unused and misleading `fqbn` key from the generated build profile will better communicate the actual
situation to the user.
Copy link
Contributor

@lucarin91 lucarin91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will do some tests to very nothing breaks. If that isn't the case, I will agree to remove it. We should then remove it also from the example app here https://github.com/search?q=repo%3Aarduino%2Fapp-bricks-examples%20sketch.yaml&type=code

@lucarin91 lucarin91 requested a review from cmaglie December 4, 2025 14:58
@per1234
Copy link
Contributor Author

per1234 commented Dec 4, 2025

We should then remove it also from the example app here https://github.com/search?q=repo%3Aarduino%2Fapp-bricks-examples%20sketch.yaml&type=code

100%! I will take responsibility for that follow up PR, contingent on the acceptance of this proposal.

@lucarin91 lucarin91 merged commit 1dd4b50 into arduino:main Dec 9, 2025
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants