Open manuelbl opened 5 years ago
The \"
around the path after the @
is causing the breakage to our compiler querying -- removing that fixes it.
However, there's another bug in that a bunch of the defines are populated with "-D" in front -- those should be removed.
After that, all the squiggles should be fixed. This seems like a bug with PlatformIO? If you think our C/C++ extension is not handling compiler arguments correctly you could file a bug on our extension: https://github.com/Microsoft/vscode-cpptools/issues.
FYI, we also added a new compilerArgs property as of 0.25.0 if that is more convenient to use than appending args to the end of the compilerPath.
C/C++: Log Diagnostics command and the "C/C++: <project>
" pane with C_Cpp.loggingLevel set to "Debug" can show diagnostics info, e.g. I saw that the querying of the gcc compiler was failing to process the last argument.
@sean-mcmanus is it possible to pass different configuration for C and C++ compilers? We have different flags for C and C++.
@ivankravets Not currently via c_cpp_properties.json, because there is no separate cppCompilerPath and cCompilerPath setting (you could file a feature request for that...no one else has yet requested that though). However, via the custom configuration provider interface (https://github.com/Microsoft/vscode-cpptools-api/blob/master/api.ts) a custom configuration provider could provide separate compilerPath/args for .c files versus .cpp files.
@ivankravets Another possibility is to have 2 different configurations, one for .c files and another for .cpp files, and then run the new cpptools.setActiveConfigName command (see https://github.com/microsoft/vscode-cpptools/pull/4893 ) when the active file type changes, but that command hasn't shipped yet.
@sean-mcmanus
However, there's another bug in that a bunch of the defines are populated with "-D" in front -- those should be removed.
Thanks, this is already fixed, but hasn't been released yet.
The \" around the path after the @ is causing the breakage to our compiler querying -- removing that fixes it.
Indeed, it works after removing extra quotes, but how we can handle whitespace characters in path to files specified using @file
syntax?
Our compilerPath property doesn't actually work with @\"path with spaces\"
so the usage of \"
doesn't fix the path with spaces scenario (could be a bug in our handling of the compilerPath).
However, using the compilerArgs enables the @\"path with spaces\"
to parse correctly, e.g.
"compilerPath": "~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gcc",
"compilerArgs": [
"-iprefix/~/.platformio/packages/framework-arduino-nrf52-mbedos/cores/arduino",
"@~/.platformio/packages/framework-arduino-nrf52-mbedos/variants/ARDUINO NANO33BLE/includes.txt"
]
We opened an issue in PIO Core https://github.com/platformio/platformio-core/issues/3364
@valeros will back soon with updates. Thanks!
@sean-mcmanus Could you please also give us a hint about -include
flag in compilerArgs
? So, in a nutshell, VSCode is not able to see any definition that is specified in a special header file which is passed to the compiler via -include file
command although the path to this file is specified in includePath
section. It only works if path to this file is specified in compilerArgs
using -I
flag. Is that how it should work by design?
I prepared a basic example that is compilable using CMake, but when you open it in VSCode you'll see an issue with undefined symbol. Thanks in advance!
-include
is equivalent to our "forcedInclude" setting (despite the name, it takes an array), so you should use that instead. Our compilerArgs setting is mostly just used for compiler querying for the system includes and defines, and code for translating the args into settings like forcedInclude that we understand doesn't exist (it exists for compile_commands.json processing though).
@sean-mcmanus Thanks for the hint, but looks like forcedInclude
option also ignores paths specified in includePath
. It works only if I specify the full path to a header file.
Am I missing something? Thanks!
You've hit bug (feature request) https://github.com/microsoft/vscode-cpptools/issues/2780 . I added a comment to that issue.
@sean-mcmanus Thanks! Also a question about escaping spaces in compilerArgs
. For example, on Windows we have to wrap flags with spaces (e.g. @\"path with spaces\"
), while on Linux the syntax with \"
just breaks IntelliSense. I checked Includes
field in the report generated by C/C++: Log Diagnostic
command and indeed the includes specified in @\"/path/with spaces/file\"
are missing on Linux if a flag contains escaped symbols. Is there a reason for this behavior?
On Windows, we create a command line via appending spaces between the args (e.g. gcc -IC:\\path with space
, which will fail without quotes), but on Linux/Mac we send the args in an array, which is equivalent to gcc "-I/path with space"
. Maybe on Windows we should be surrounding all the args with quotes? I don't recall any other user reports on this though, and I'm sure if anyone is relying on the existing behavior. You or I could create a bug or feature request at https://github.com/Microsoft/vscode-cpptools/issues .
FYI: I am able to build a deploy to Nano 33 BLE Sense. The application uses the builtin microphone and BLE and all works fine.
The only issue encountered is that the default path used for the project Library Options was specified as ~/Documents/Arduino/libraries. I had to change this to ~/OneDrive/Documents/Arduino/libraries. Happy to raise this as a separate issue if it is not known.
I see this item as open, but it seems that support is at least partially in the platform. I'm having trouble on my Arduino Nano 33 BLE, it will not execute the main loop when built with PlatformIO, but will using the Arduino tooling. My sketch is as simple as a Serial.println("Hello world")
. I have tried with setting up Serial in the setup()
function as well. All the code in the setup()
function executes correctly, including printing out to Serial.
Not sure how to go about debugging this, and would love to use CLion + PIO over using the Arduino IDE, thanks!
This sounds like the typical problem of most Arduinos implementing the Serial-to-USB bridge in software (instead of using a dedicated Serial-to-USB chip). Such a solution depends on the MCU being responsive, in particular during USB enumeration, i.e. when the host computer discovers the USB device and needs to figure out the device configuration.
In your case, the MCU is probably stopped by the debugger during enumeration and therefore the host computer gives up on the device. Later the code is stuck in while (!Serial);
or some USB interrupt handler.
The proper solution would be if the Arduino core was changed such that it forces USB enumeration when Serial
is initialized and waits and stays responsive until the host computer has completed the device discovery.
As a workaround, try one of the following:
setup
after while (!Serial);
and immediately continue when the debugger initially stops.delay(1000);
after while (!Serial);
and set the break point even after delay
.loop
or some other function after Serial
initialization using debug_init_break = tbreak loop
(in platformio.ini
)Serial
I tried #4, in order to test out the Serial path. I wrong a simple blink program
digitalWrite(LED_BUILTIN, HIGH);
delay(1000);
digitalWrite(LED_BUILTIN, LOW);
delay(1000);
This caused the board to go into an mbed os crash state (3 short blinks and 3 long blinks)
Curious what you said about the USB enumeration, it does work successfully with the Arduino IDE (a simple Hello World loop). Additionally, I did not think the Arduino Nano 33 BLE was debuggable without an additional board, is it? I do not have a debug board.
It looks as if there are more issues than I thought. If you run the program with PlatformIO's upload command (and not using the green debug arrow) and it fails, then there is indeed an issue in PlatformIO. Last December it has been working (except for IntelliSense issues). But a lot of things have changed in the mean time. I'll check it again.
Regarding debugging: It can be done with a debug adapter and some soldering: https://medium.com/@manuel.bl/arduino-in-circuit-debugging-with-platformio-9f699da57ddc
@manuelbl I am indeed using the green upload arrow (not the debug icon). I have tried this via command line as well, with the same results. Thanks for the link! Let em know if I can do anything to help the development.
@manuelbl FWIW, I tried going back through the old versions of this released package, none of them worked, guessing it may have to do with PlatformIO itself? I did not have an easy way to test this however.
I've just tested PlatformIO with my Arduino Nano 33 BLE again and I can report that it fully works: compiling, IntelliSense, uploading, executing, debugging.
For the first test, I've used a simple blink program and uploaded the program using the USB port:
platformio.ini
[env:nano33ble]
platform = nordicnrf52
board = nano33ble
framework = arduino
main.cpp
#include <Arduino.h>
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
digitalWrite(LED_BUILTIN, HIGH);
delay(1500);
digitalWrite(LED_BUILTIN, LOW);
delay(500);
}
Next, I've hooked up my J-Link and added these two lines to platformio.ini:
upload_protocol = jlink
debug_tool = jlink
Both uploading and debugging worked flawlessly.
Finally, I've added serial output and it work again, even when debugging. And I have tested it both on macOS and Windows.
If it still doesn't work for you, you should probably go to https://community.platformio.org/ and for help there (incl. a full project to reproduce your error).
should jlink matter? what options can I use if I don't have a jlink?
EDIT: what version of pio do you have?
J-Link is only needed for debugging. Without J-Link, just omit upload_protocol
and debug_tool
. It will use the default protocol (sam-ba
I think).
I'm using the latest official PIO core release (5.0.1) and up-to-date platform and other package versions.
Turns out the "Quick installer" path for PlatformIO installs the latest (5.0.2b) rather than latest stable, installing 5.0.1 fixed it! thanks for the help @manuelbl. I'm not sure if this means there will be a problem in the future with 5.0.2, or if it's just unstable.
@manuelbl do we have an issue with the upcoming 5.0.2-dev? We didn't do any significant changes.
@ivankravets I've tested it on both macOS and Windows and it works with 5.0.2-dev. I've used Visual Studio Code while @tylerhartwig also talked about CLion. So I doubt it's related to 5.0.2-dev. It might have been another installation problem though.
Some of the symptoms would also fit if the code contained while (!Serial) delay(1);
. It has the effect that setup()
waits until a terminal connects to the virtual serial port.
One additional question, is any support planned to be able to use mbed directly on this board? my understanding is this is possible via mbed command line, but having this in platformio would be awesome as well.
EDIT:
I should clarify, I know you can use mbed features, wondering if it will be possible to compile with mbed over arduino framework = mbed
.
package framework-arduino-nrf52-mbedos tracks https://github.com/arduino/ArduinoCore-nRF528x-mbedos, which will continue tracking mbed 5.x series and new releases will only happen in case of security bugs. Will it change to track https://github.com/arduino/ArduinoCore-mbed instead?
along the lines of what @lzq420241 said, I would be interested in some guidance on what needs to be done to update to the new 6.x library. I have some spare time I could potentially spend on this.
EDIT -- this should likely be tracked against #111 I'm guessing
Now that the Arduino Nano 33 BLE and Arduino Nano 33 BLE Sense have been released and introduce:
Are there any plans to bring them to PlatformIO? What will be needed? How can it be supported?