Invalid FQBN: not an FQBN:

Development Tools IDE 2.x
1

I installed todays daily build (1027),

I drop down the board/connections drop down and choose the Micromod. And then try to build.

I have a teensy Micromod running. Note I built some stuff earlier with Arduino 1.8.19 sort of (build in sublime-text) and TyCommander running but not Serial enabled. Don't think this is involved, but mentioned for completeness.

I Then get the following error, which is cryptic at best.

Invalid FQBN: not an FQBN: teensy:avr:teensyMM:usb=serial:usb=serial,speed=600,opt=o2std,keys=en-us

Compilation error: Invalid FQBN: not an FQBN: teensy:avr:teensyMM:usb=serial:usb=serial,speed=600,opt=o2std,keys=en-us

image
image1307×838 51.3 KB

But if I go and then select the board, port, usb type... in the tool menus.
It does build.

Did not see anything obvious in current issues, will check again later

2

I have the same issue with Teensy 4.1. Worked before update earlier today

3

Thanks all. I can reproduce the bug and am preparing a report now. I will circle back with a link once that is finished.

4

Here is the report:

Thanks so much for bringing this to our attention.

This bug is related to a nice new feature added to Arduino CLI at the request of Paul Stoffregen:

The CLI is able to identify the board definition associated with a port based on properties returned by the pluggable discovery tool. Previously, it could only determine the base board identity (e.g., teensy:avr:teensyMM), and not the custom configuration of the board you make via the additional Tools menu items in the IDE such as Tools > USB Type. It is now possible for these custom board options to be identified as well.

Unfortunately, even though the feature is working correctly in Arduino CLI, we missed that the Arduino IDE code was making an assumption that the FQBN provided by Arduino CLI would always have the simple teensy:avr:teensyMM form.

As you discovered, the workaround is to always select the board from the Tools > Board menu in the Arduino IDE. When you do that, you are setting the board selection manually instead of using the FQBN automatically determined from the port data returned by the discovery tool.

5

Thanks,

As you already know, Paul, made a change to the Teensy software to hopefully handle this.

But his current solution, for how to handle Teensy Releases versus Teensy Beta releases,
there are some interesting tradeoffs.

That suppose the official release of Teensy boards is 1.57,
but suppose for those of us who are wanting to work with beta releases, there is
1.58 Beta 2. Note: the official release of 1.58 is probably at least several months away.

The question is, is there a reasonable way to accommodate, both typical users and those of us who want to use the beta (most of the time). And neither of us want to be constantly asked if we wish to update every time we start the IDE.

Note: When Paul comes out with lets say: 0.58.3 and I am running 57.0.1 or the like, it will not show up in the updateable list.

Paul's current solution, is to now name the beta release something like:
0.58.2 instead of 58.0.2... As to make sure that users don't accidentally update to a beta build.
But now I get the: generic there are boards out of date do you wish to update(automaic, manual.)

Wish there was a cleaner way. Note: some of this also applies to libraries as well. There are several possible options to help with some of this.

  1. have some way to officially mark a new release in list as a beta release. That is for example 1.58.3 as a beta build. It should only Nag me to update if I am already running a Beta build and/or some option in Types: like Updatable include betas...

  2. Have an option like Visual Studio has, where when it tells me this board is updateable, I can tell it to ignore this release. And maybe only ask me again when the next time that the
    teensy boards file is downloaded with a change in it.

  3. Wish the Automatically update option comes up with secondary dialog telling me are you sure you want to update, x, y, z boards and maybe allow me to exclude one or more of them. Maybe it does, been too cautious to allow this option.

  4. at a minimum, if I restart the IDE and none of the board manager files changed, and you already showed me these options 20 minutes ago, maybe it should not ask again.

Question is, should we create a new issue on some of this? Or is it covered under some existing one(s)? I did not find anything obvious, but not sure if it would be under IDE or CLI?

But for now, back to playing.

6

Thanks for posting the update.

To summarize for other interested parties, just update to the new 1.57.1 release of the "Teensy" boards platform when the IDE offers it to you and the problem with the FQBN will no longer occur.

More info here:

(post 33)

I have already submitted a proposal about this:

I mentioned it several times on the PJRC forum when the subject has been raised.

If this feature was implemented, pre-release/beta versions would not be offered as the default install nor for updates to users with production release versions installed.

This would mean that Paul would not have to use the incorrect version numbers for the pre-release/beta platform releases as a workaround for the current simplistic version handling. Since the correct pre-release/beta version numbers are newer than the production release version numbers, beta testers would not be offered updates to production release versions that are actually older than the pre-release/beta version they are using from a development perspective.

7

Thanks,
I added a comment to that issue, as to get notifications if something is updated on it and to hopefully maybe bump it it's priority.

Even with this, I do wonder about some of the other options might still be beneficial.

8

There is already a standardized way to do this via version numbers, which is used in modern software development projects:

https://semver.org/#spec-item-9

I don't see this as an effective way to address this specific problem of allowing Boards Manager to be used by platform maintainers for distributing pre-release versions without the presence of those releases harming the user experience for regular users.

However, I do think it could be useful for other use cases:

  • The user knows the release is "bad" (e.g., significant regression, incompatibility with their code)
  • The user is intentionally not updating that specific platform, but doesn't want to disable update notifications universally.

Arduino IDE already has this capability for the IDE updates, but not for platform or library updates.

There is an existing request for such a capability here:

I think the "Install Manually" button provides this capability effectively already. When you click that button, you get a list of the platforms that are updatable and the version that would be updated to and you can pick the specific platforms you want to update.

It seems to me that this would be obviated by your other proposal to add a "Skip Version" capability for the platform/library update notifications.

If I clicked the "Later" button because I don't want the update at all, then I would prefer to never get another for it.

If I clicked the "Later" button because I didn't have time at that moment to perform the update, but I do plan to do it, then I would be happy to get another notification for the update the next time I start the IDE.

So I don't see a use case where reducing the notification frequency is beneficial in addition to a "skip version" capability. Do you see one?

As for reducing the notification frequency as an alternative to the "skip version" capability, I think it is only a minor mitigation, but also do think it would be reasonable to tie it to the current 4 hour minimum interval of the package index downloads.

9

Thanks for all of this information, as well as your hard work!

Thanks, keeping fingers crossed, that some of this will be used to better solve cases where some users want to install betas and others don't. Not sure how much granularity is needed, I would be happy for two levels. Releases and not releases (which could include beta, rc...)

Agreed. But simply wondering if user hits Automatic thinking there may be only 2-3 libraries effected, and the system thinks there are over 50 libraries it will update, if there maybe be an are your sure you want to update that many...

But I will feel more comfortable when hopefully the update code will detect that a library is a github project and ignores it, and likewise maybe (if the directory is linked into library directory).
IDE 2 - Library Manager - Should not update Library linked in and/or which is a git clone · Issue #1881 · arduino/arduino-cli (github.com)

I agree, if the other things are implemented, like beta versus release, and it will not update libraries which are ones I am working on (github), and one can say, skip this update for this library or board, the other possibilities I mentioned are of limited usage!

The don't ask me again for some period of time, I mentioned more as a stop gap. That is if some of these things won't be implemented for another year or two, then maybe the reduce the number of times the IDE asks might be of some benefit.

Again, I would like to mention, how much I appreciate that improvements that Arduino 2.0 and now 2.0.1 have made the Arduino IDE experience.

1 Like
10

Still hoping this invalid FQBN issue in the IDE will eventually get fixed, and the IDE will actually use the extra info CLI provides to initialize the menu settings when the user chooses the board from the drop-down list in the main toolbar.

11

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