Skip to content

GitLab

A
arduino-cli
Switch branch/tag
  1. 31 Aug, 2023 1 commit
    • Cristian Maglie's avatar
      Upload port detector improvements (#2288) · 048415c5
      Cristian Maglie authored 
      * If the upload port-detector fails detection, fallback to the user-provided port

This will ensure that a port is always returned.

* Increased debug level

* Extend timeout if candidate port is lost in any case

Even if `waitForUploadPort` is true, we should extend the timeout to
allow USB enumeration to complete. In this case we extend by only 1
second instead of 5.

* Revert "Extend timeout if candidate port is lost in any case"

This reverts commit 7c77ed242383e416ff8748884a64474f73932911.

The latest commit is not necessary since the detector has already 5 seconds of timeout.
      048415c5
  3. 22 Aug, 2023 1 commit
  5. 21 Aug, 2023 1 commit
  7. 18 Aug, 2023 3 commits
    • Cristian Maglie's avatar
      feature: Detect board port change after upload (#2253) · 38479dc7
      Cristian Maglie authored 
      * UploadResponse now has 'oneof' clause for better API design

* Added scaffolding to return updated-port after upload

* Upload port change detection (first draft)

* Simplified port detection using a Future-style abstraction

* Perform watcher-flush higher in the call tree

* Do not infer upload port if 'upload.wait_for_upload_port' is false

* Further simplified port detection subroutine structure

* fixed linter issue

* Always return an updatedUploadPort.

Arduino CLI should always return the port after an upload, even in the case
where no port change is expected. The consumer shouldn't be required to
implement "if not updated_upload_port, use original port" logic.

The whole point is that all the logic for determining which port should be
selected after an upload should be implemented in Arduino CLI. The consumer
should be able to simply select the port Arduino CLI tells it to select in
all cases.

* Updated docs

* Perform a deep-copy of upload ports where needed.

Previously only the pointer was copied, thus making changes in
`actualPort` to be reflected also to `port`. This lead to some weird
result in the `updatedUploadPort` result:

{
  "stdout": "Verify 11344 bytes of flash with checksum.\nVerify successful\ndone in 0.010 seconds\nCPU reset.\n",
  "stderr": "",
  "updated_upload_port": {
    "address": "/dev/tty.usbmodem14101",     <------- this address...
    "label": "/dev/cu.usbmodem14101",        <------- ...is different from the label
    "protocol": "serial",
    "protocol_label": "Serial Port (USB)",
    "properties": {
      "pid": "0x804E",
      "serialNumber": "94A3397C5150435437202020FF150838",
      "vid": "0x2341"
    },
    "hardware_id": "94A3397C5150435437202020FF150838"
  }
}

* When updating `actualPort` address, update also the address label.

* Fixed some potential nil pointer exceptions

* Further simplified board watcher

We must acesss the gRPC API only until we cross the `command` package
border. Once we are inside the `command` package we should use the
internal API only.

* Before returning from upload, check if the port is still alive

Now the upload detects cases when the upload port is "unstable", i.e.
the port changes even if it shouldn't (because the wait_for_upload_port
property in boards.txt is set to false).

This change should make the upload process more resilient.

* Apply suggestions from code review
Co-authored-by: default avatarper1234 <accounts@perglass.com>

* Fixed nil exception

* Improved tracking algorithm for upload-port reconnection

The new algorithm takes into account the case where a single board may
expose multiple ports, in this case the selection will increase priority
to ports that:

  1. have the same HW id as the user specified port for upload
  2. have the same protocol as the user specified port for upload
  3. have the same address as the user specified port for upload

---------
Co-authored-by: default avatarper1234 <accounts@perglass.com>
      38479dc7
    • Cristian Maglie's avatar
      [skip-changelog] regression: hide include-not-found errors during library discovery (#2267) · b64876c7
      Cristian Maglie authored 
      * regression: hide include-not-found errors during library discovery

This regression was made during a refactoring of the Arduino preprocessor.
In particular the wrong change was part of this commit:
https://github.com/arduino/arduino-cli/commit/0585435f8b1d05e0117606f69bea42d3f3dfec79#diff-65ff16cbee816c0f443157444d99bcc144beee06c3329aec891894c8aeda7b27L372-R378

-                       preproc_stderr, preproc_err = GCCPreprocRunner(ctx, sourcePath, targetFilePath, includes)
+                       var preproc_stdout []byte
+                       preproc_stdout, preproc_stderr, preproc_err = preprocessor.GCC(sourcePath, targetFilePath, includes, ctx.BuildProperties)
+                       if ctx.Verbose {
+                               ctx.WriteStdout(preproc_stdout)
+                               ctx.WriteStdout(preproc_stderr)
+                       }

Previously GCCPreprocRunner, in verbose modem will show ONLY the stdout of
the process, instead the "refactored" code wrongly added also stderr to the
output.

For reference this is the old GCCPreprocRunner implementation:
https://github.com/arduino/arduino-cli/commit/0585435f8b1d05e0117606f69bea42d3f3dfec79#diff-371f93465ca5a66f01cbe876348f67990750091d27a827781c8633456b93ef3bL36

-func GCCPreprocRunner(ctx *types.Context, sourceFilePath *paths.Path, targetFilePath *paths.Path, includes paths.PathList) ([]byte, error) {
-       cmd, err := prepareGCCPreprocRecipeProperties(ctx, sourceFilePath, targetFilePath, includes)
-       if err != nil {
-               return nil, err
-       }
-       _, stderr, err := utils.ExecCommand(ctx, cmd, utils.ShowIfVerbose /* stdout */, utils.Capture /* stderr */)
-       return stderr, err
-}

This commit fixes the regression.

* Added integration test
      b64876c7
    • Cristian Maglie's avatar
      [skip-changelog] regression: Fix property expansion of "recipe.preproc.macros" (#2268) · 3bd60c6b
      Cristian Maglie authored 
      Previously the undefined template placeholders in "recipe.preproc.macros"
were silently replaced the empty string. This changed after a
refactoring in 0585435f.

Previously it was:

https://github.com/arduino/arduino-cli/commit/0585435f8b1d05e0117606f69bea42d3f3dfec79#diff-371f93465ca5a66f01cbe876348f67990750091d27a827781c8633456b93ef3bL62
-       cmd, err := builder_utils.PrepareCommandForRecipe(buildProperties, "recipe.preproc.macros", true, ctx.PackageManager.GetEnvVarsForSpawnedProcess())

The `true` parameter in the call to `builder_utils.PrepareCommandForRecipe` is the parameter `removeUnsetProperties`.

This behaviour has not been ported over after the "refactoring":
https://github.com/arduino/arduino-cli/commit/0585435f8b1d05e0117606f69bea42d3f3dfec79#diff-733dda6759fe968eb8a8d7305c37c7a320a8df52764ca0cba8e88a6f1d077eb5R44-R65

+       const gccPreprocRecipeProperty = "recipe.preproc.macros"
+       if gccBuildProperties.Get(gccPreprocRecipeProperty) == "" {
+               // autogenerate preprocess macros recipe from compile recipe
+               preprocPattern := gccBuildProperties.Get("recipe.cpp.o.pattern")
+               // add {preproc.macros.flags} to {compiler.cpp.flags}
+               preprocPattern = strings.Replace(preprocPattern, "{compiler.cpp.flags}", "{compiler.cpp.flags} {preproc.macros.flags}", 1)
+               // replace "{object_file}" with "{preprocessed_file_path}"
+               preprocPattern = strings.Replace(preprocPattern, "{object_file}", "{preprocessed_file_path}", 1)
+
+               gccBuildProperties.Set(gccPreprocRecipeProperty, preprocPattern)
+       }
+
+       pattern := gccBuildProperties.Get(gccPreprocRecipeProperty)
+       if pattern == "" {
+               return nil, nil, errors.Errorf(tr("%s pattern is missing"), gccPreprocRecipeProperty)
+       }
+
+       commandLine := gccBuildProperties.ExpandPropsInString(pattern)
+       args, err := properties.SplitQuotedString(commandLine, `"'`, false)
+       if err != nil {
+               return nil, nil, err
+       }

that is missing the call to `properties.DeleteUnexpandedPropsFromString`.
      3bd60c6b
  9. 17 Aug, 2023 1 commit
  11. 14 Aug, 2023 1 commit
  13. 12 Aug, 2023 1 commit
  15. 11 Aug, 2023 1 commit
  17. 04 Aug, 2023 1 commit
  19. 03 Aug, 2023 3 commits
  21. 02 Aug, 2023 1 commit
  23. 24 Jul, 2023 2 commits
    • MatteoPologruto's avatar
      [skip-changelog] Update installed.json file used in tests (#2250) · 62bb4c47
      MatteoPologruto authored
      62bb4c47
    • per1234's avatar
      Explain usage of `monitor --config` in command help (#2249) · 78d19fa1
      per1234 authored 
      The `--config` flag of the `arduino-cli monitor` command is used to configure the communication port used by the
monitor.

Previously the command line help did not provide any guidance for the usage of this flag, which might lead the users to
wonder:

- How can the configuration options available for use via the flag be determined?
- What is the format for the configuration option argument?

The information is provided in the FAQ page of the documentation, but that is not as convenient a source of information
as the command line help and the user may not even be aware of its existence.

The command help is hereby adjusted to provide the user with this information:

- Create a conceptual linkage between the `--config` and `--describe` flags by using the "communication port settings"
  terminology in the references of both.
- Document the argument format.

In addition to the comma-separated list format I documented here, an alternative usage of passing multiple `--config`
flags is also supported. I chose the former because I felt that the descriptions of the latter in either command line
notation (e.g., `[--config <ID>=<value>]...`) or in prose (e.g., "The format is <ID>=<value>. Can be used multiple times
for multiple settings.") were less clear.
      78d19fa1
  25. 21 Jul, 2023 2 commits
  27. 20 Jul, 2023 2 commits
  29. 06 Jul, 2023 1 commit
  31. 04 Jul, 2023 1 commit
  33. 03 Jul, 2023 1 commit
  35. 30 Jun, 2023 1 commit
    • Cristian Maglie's avatar
      Disable DTR clearing on 1200-bps touch (only on Windows) (#2234) · fe6d7499
      Cristian Maglie authored 
      The reason why it was originally introduced:
https://github.com/arduino/Arduino/pull/2709/commits/a6909bdb49d99253b4e684365e72e5dce31a49a7

Why we are removing it now?
* Windows does preserve the state of the RTS/DTR bits on successive
  opening of the serial port.
* The serial library used in the Arduino IDE 1.8.x has a bug when trying
  to set DTR=false, on successive opening of the port the DTR line is
  set back high by the USB serial driver. This works differently from
  the serial library we use in the Arduino CLI, that sets DTR=false for
  good and this change is preserved on the successive opening of the
  port.
* Having the serial port left in a state with DTR=false may cause
  problems to tools uploading later.

It may probably completely removed, but for now, to reduce the testing
surface, it will be disabled only for Windows.
      fe6d7499
  37. 27 Jun, 2023 3 commits
  39. 21 Jun, 2023 3 commits
  41. 20 Jun, 2023 2 commits
  43. 19 Jun, 2023 1 commit
  45. 16 Jun, 2023 1 commit
    • Cristian Maglie's avatar
      Automatically download indexes, if missing, in gRPC `Init` call (#2119) · 82e6f5d7
      Cristian Maglie authored 
      * Created core.PlatformList implementaion follow gRPC naming

Previously it was named GetPlatforms with a different return type than
the one defined in gRPC API .proto files.

* Added test for #1529

* Perform first-update automatically in gRPC Init

* Made cli.instance.Create function private

* Extract function to compute index file name

* Auto-download 3rd party indexes as part of the Init
      82e6f5d7
  47. 15 Jun, 2023 2 commits
  49. 14 Jun, 2023 1 commit
  51. 13 Jun, 2023 2 commits