Closed per1234 closed 1 month ago
fpistm
commented
2 months ago Hi @per1234 Thanks for the PR. Anyway, I'm not a big fan of adding the "upload_port" as a fix. I've tested my proposal here and it works: https://github.com/stm32duino/Arduino_Core_STM32/issues/2511#issuecomment-2348482045 It is more homogeneous to fix like that. Are you agreed?
per1234
commented
2 months ago I've tested my proposal here and it works: https://github.com/stm32duino/Arduino_Core_STM32/issues/2511#issuecomment-2348482045
The only relevant part of that diff is this:
--- a/boards.txt
+++ b/boards.txt
@@ -12463,7 +12463,7 @@ Blues.build.st_extra_flags=-D{build.product_line} {build.enable_usb} {build.xSer
Blues.build.flash_offset=0x0
Blues.upload.maximum_size=0
Blues.upload.maximum_data_size=0
-Blues.vid.0=0x30A4
# Swan R5 board
Blues.menu.pnum.SWAN_R5=Swan R5The other changes might be worth making for other reasons, but they aren't relevant to https://github.com/stm32duino/Arduino_Core_STM32/issues/2469
That change will certainly fix https://github.com/stm32duino/Arduino_Core_STM32/issues/2469. However, assuming that providing identification for the ports of the Blues boards is considered desirable, it is clearly inferior to my proposal, which preserves the port identification for users of modern Arduino development software. You haven't provided any meaningful reason for rejecting my proposal.
fpistm
commented
2 months ago In fact, no other boards have the "upload_port" property. That's why I told it is not homogeneous to use "upload_port". If I had a chance I will develop a Discovery tool but no free time yet.
So to sum up, I used only this:
https://arduino.github.io/arduino-cli/1.0/platform-specification/#board-vidpid
Not upload_port.
Maybe it is a mistake I've made.
To be honest the description of the board vid/pid description and the upload_port is confusing and seems very closed.
fpistm
commented
1 month ago As no answer form OP, I've pushed a new PR (#2525) which supersede this one. Discovery tools will be investigate later.
Summary
The Arduino boards platform framework allows properties of a port to be associated with a board definition. The Arduino development software will identify a port having the associated properties as that board.
The "Blues boards" board definition contains an association for the
vidport property value of0x30A4:https://github.com/stm32duino/Arduino_Core_STM32/blob/89a29516cca7b50c6aef17a52e0e6e4afe78aeb7/boards.txt#L12466
Typically, in addition to the
vidproperty, a companionpidproperty will also be associated so that the association is specific to devices with that VID/PID pair. However, this board definition only associates avidproperty. Although unusual, this is reasonable in this case where the board definition provides support for all models of the Blues boards (rather than one specific model as is typically the case).Unfortunately it seems that the Arduino IDE 1.x codebase is written in a way that assumes a PID association will always be provided along with a VID association. When a platform is installed that contains a board definition that associates a
vidproperty without also associating apidproperty, it breaks port discovery entirely, causing no ports to be discovered for any board.The port discovery and port properties association system has been completely reworked since the time of Arduino IDE 1.x. The modern system, which is used by Arduino IDE 2.x and Arduino CLI, doesn't have any problem with this VID-only association. This means that it would be possible to define this association without breaking Arduino IDE 1.x if the association could be applied exclusively for the modern Arduino development software versions. Arduino IDE 1.x only uses the port property association for the convenience feature of labeling the port in the Tools > Port menu, so the lack of an association doesn't cause any meaningful impact.
At the time the port discovery and port properties association system was reworked, the port property association properties were renamed to support association with any arbitrary properties:
https://arduino.github.io/arduino-cli/latest/pluggable-discovery-specification/#board-identification
(while retaining support for the old property names). The new property names are only recognized by the modern Arduino development software and have no effect on Arduino IDE 1.x.
The port association properties for the "Blues boards" board definition are migrated from the old property names previously in use to the new names. This causes the port property association to no longer be recognized by Arduino IDE 1.x, fixing the breakage of its port discovery system. The association will still be recognized by the modern versions of Arduino development software just as before.
This PR fixes/implements the following bugs/features
Validation
0x30A4to your computer.0x30A4is labeled "(Blues boards)Additional context
Even though, from a technical standpoint, this change restores the platform's support for Arduino IDE 1.x, my impression is that maintainability was also a factor in the decision to drop 1.x support (which is quite understandable). For this reason, the "only Arduino IDE 2 is supported" statement was not removed from the readme.
Closing issues