Tags: arduino/arduino-cli
Tags
regression: Import fix for `compile --input-dir .` regression found in … …#2304 (#2305) * Add support for default build profile (#2203) * Add support for default profile to compile command * Add support for default profiles to upload command * Add TestCompileWithDefaultProfile to integration tests * Get the profile's FQBN if it's not already specified in the request * Update documentation regarding sketch projects * Added integration tests for all default_profile cases * Reverted old sketch_with_profile test --------- Co-authored-by: Cristian Maglie <[email protected]> * [skip-changelog] Use `LoadSketch` in upload function and return `rpc.Port` in `GetPort` (#2297) * Change GetPort's returned type to rpc.Port * Use LoadSketch in runUploadCommand --------- Co-authored-by: MatteoPologruto <[email protected]>
Upload port detector improvements (#2288) * 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 7c77ed2. The latest commit is not necessary since the detector has already 5 seconds of timeout.
feature: Detect board port change after upload (#2253) * 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: per1234 <[email protected]> * 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: per1234 <[email protected]>
Disable DTR clearing on 1200-bps touch (only on Windows) (#2234) The reason why it was originally introduced: arduino/Arduino@a6909bd 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.
Disable DTR clearing on 1200-bps touch (only on Windows) (#2234) The reason why it was originally introduced: arduino/Arduino@a6909bd 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.
Improved memory usage on core/libraries install (#2187) This is obtained through the upgrade of the 'extract' library. Upstream patch: codeclysm/extract#21