platformio / platform-nordicnrf52

Nordic nRF52: development platform for PlatformIO
https://registry.platformio.org/platforms/platformio/nordicnrf52
Apache License 2.0
108 stars 116 forks source link

Support for Arduino Nano 33 BLE (Sense) #53

Open manuelbl opened 5 years ago

manuelbl commented 5 years ago

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?

sean-mcmanus commented 4 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.

ivankravets commented 4 years ago

@sean-mcmanus is it possible to pass different configuration for C and C++ compilers? We have different flags for C and C++.

sean-mcmanus commented 4 years ago

@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.

sean-mcmanus commented 4 years ago

@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.

valeros commented 4 years ago

@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?

sean-mcmanus commented 4 years ago

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"
            ]
ivankravets commented 4 years ago

We opened an issue in PIO Core https://github.com/platformio/platformio-core/issues/3364

@valeros will back soon with updates. Thanks!

valeros commented 4 years ago

@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!

sean-mcmanus commented 4 years ago

-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).

valeros commented 4 years ago

@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!

sean-mcmanus commented 4 years ago

You've hit bug (feature request) https://github.com/microsoft/vscode-cpptools/issues/2780 . I added a comment to that issue.

valeros commented 4 years ago

@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?

sean-mcmanus commented 4 years ago

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 .

JasonBSteele commented 4 years ago

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.

tylerhartwig commented 3 years ago

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!

manuelbl commented 3 years ago

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:

tylerhartwig commented 3 years ago

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.

manuelbl commented 3 years ago

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

tylerhartwig commented 3 years ago

@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.

tylerhartwig commented 3 years ago

@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.

manuelbl commented 3 years ago

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).

tylerhartwig commented 3 years ago

should jlink matter? what options can I use if I don't have a jlink?

EDIT: what version of pio do you have?

manuelbl commented 3 years ago

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.

tylerhartwig commented 3 years ago

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.

ivankravets commented 3 years ago

@manuelbl do we have an issue with the upcoming 5.0.2-dev? We didn't do any significant changes.

manuelbl commented 3 years ago

@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.

tylerhartwig commented 3 years ago

@manuelbl all of my tests beyond maybe my first comment were from command line. I did see issues when Serial was not included. If I'm not mistaken the version was 5.0.2b I'm not sure if that's the same as dev?

I specifically followed this for installation.

I followed up with this.

tylerhartwig commented 3 years ago

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.

lzq420241 commented 3 years ago

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?

tylerhartwig commented 3 years ago

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