Mbed-os: VSCode exporter: use mbed instead of make and other enhancements

[JojoS62]

Description

VSCode is a great tradeoff between enhanced editor and IDE. It is more transparent and lightwight compared to eclipse based IDE and extensions are easier to create. Multi platform support is included by design.
The current exporter uses makefile based build process. This requires an external tool to be installed, the gcc toolchain for instance does not contain a make tool.
Things are easier when the mbed-cli with 'mbed compile' is used instead. This is aready described in the mbed documents: https://os.mbed.com/docs/v5.9/tutorials/visual-studio-code.html
Building with mbed compile looks like the reference for mbed building now and using this in VSCode does not require special IDE related stuff like in the eclipse exporters. Creating eclipse exportes is a tedious task and the result is fragile, the exporter is hard to sync with the eclipse plugins.

I want to suggest to

• use mbed cli as the default VSCode configuration (alternative: vscode_mbed-cli exporter to maintain existing makefile based, but the existing does not work well)
• create VSCode configuration with multiple tasks for building with default profiles develop, release and debug and user suplied --profile configurations
• create launch configurations with OOCD and pyOOCD
• create task for flashing target

Sounds like much work, but indeed it is 'just' creating configuration files, most magic is done already by mbed-cli.

There is already a vscode-mbed extension, but currently this does not work with windows. Anyway, a mbed extension can be used for configuring mbed target, toolchain, debug probe etc.

Any comments?

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

[DBS06]

I already did that at the project I am working for, but it relies on the extension "vscode-commandbar" and some additional python scripts which controls the mbed-toolchain. As far as I remember it was not really straight forward to do this, because sometimes you get stuck at some silly points i.e. different command and path interpretation on windows and linux... Therefore we wrote some scripts which interpret the call from "vscode-commandbar" and maps it to mbed-toolchain, furthermore we have more than one target and apps.

But yes this enhancement would tight the development more to mbed-os (i.e. build with bootloader, compiling/running/executing tests, ...), which is in my meaning the right way.

[DBS06]

BTW: for debugging the "Cortex-Debug" extension is highly recommended! It works better, faster and provides you more debugging information.

[JojoS62]

Thanks for your feedback.
I'm testing an updated tasks.json, the configurations from the vscode exporter are using depricated formats and do not work well.
This is how it looks like now (requires 'mbed config target' is set):

.vscode/tasks.json

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "type": "shell",
    "problemMatcher": {
        "owner": "cpp",
        "fileLocation": ["relative", "${workspaceFolder}"],
        "pattern": {
            "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
            "file": 1,
            "line": 2,
            "column": 3,
            "severity": 4,
            "message": 5
        }
    },
    "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": false,
        "panel": "shared",
        "showReuseMessage": false
    },
    "tasks": [
        {
            "label": "compile release",
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "command": "mbed",
            "args": ["compile", "--profile", "release", "-t", "GCC_ARM", "-c"]
        },
        {
            "label": "compile debug",
            "group": "build",
            "command": "mbed",
            "args": ["compile", "--profile", "debug", "-t", "GCC_ARM"]
        },
        {
            "label": "compile develop",
            "group": "build",
            "command": "mbed",
            "args": ["compile", "--profile", "develop", "-t", "GCC_ARM", "-c"]
        }
    ]
}

the '-c' clean switch is added now only for testing. The strange thing is that sometimes it is working, sometimes not. The compile stops randomly at some file but there is no error.

Compile [ 48.9%]: stm32f4xx_hal_can.c[ERROR] [Errno 0] Error
[mbed] ERROR: "c:\python27\python.exe" returned error.
       Code: 1
       Path: "D:\Projects\Sn\LocalGit\test\mbed-os-blinky"
       Command: "c:\python27\python.exe -u D:\Projects\Sn\LocalGit\test\mbed-os-blinky\mbed-os\tools\make.py -t GCC_ARM -m DISCO_F469NI --profile develop --source . --build .\BUILD\DISCO_F469NI\GCC_ARM-DEVELOP -c"
       Tip: You could retry the last command with "-v" flag for verbose output

With the different path notation I have seen no problems, it looks like that the vscode now converts Unix to Windows, I'm using '/' in the commands. When neccessary, the configuration can use different settings for Windows/Mac/Linux.

[JojoS62]

The problem that I see is caused by a simple 'print' in Python:

File "D:\Projects\Sn\LocalGit\test\mbed-os-blinky\mbed-os\tools\notifier\term.py", line 77, in notify
    print(msg)
IOError: [Errno 0] Error
[mbed] ERROR: "c:\python27\python.exe" returned error.
       Code: 1

it looks like this issue (Windows 10 console problem):
https://github.com/Microsoft/vscode/issues/40199

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-26

[geoffrey-vl]

I must confirm that setting up a project for compiling and debugging on vscode (windows) can be quite a daunting task since multiple problems have to avoided:

• make doesn't work by default on win10 due to file path restrictions combined with any mbed applications that are complexer than blinky
• custom targets can't be flashed using -f option since they can't be auto detected
• finding the correct gdb commands to debug / flash your board can be problematic for starters

Some of the limitations are also bound to vscode itself. You can't simply switch targets inside the IDE, or switch profiles. There is no decent mbed extension. In general I found that getting your tools setup on Windows in general was really problematic for vscode, but also for example for eclipse derivatives where the linker couldn't link due to windows file path restrictions.

[janjongboom]

@JojoS62 @geoffrey-vl @DBS06 I've given up on the exporters, as it's very hard to generate something that both works properly and keeps working over time. Part of this is because you cannot rely on getting local information from exporters, as they need to also work in the online compiler. So instead I put together https://github.com/janjongboom/mbed-vscode-generator. It takes your current environment into account, is non-destructive, is flexible about directory structure, and gives me fully working intellisense and debug configurations in VSCode.

I've not tested this on Windows (as I don't have a Windows license), so it'd be great if someone could take a look. Flashing is done with GDB rather then Mbed CLI and it generates instructions for pyOCD and STLink.

[YoHidden]

@janjongboom thanks for the app provided.

I'm giving it a try on macOS, but I'm getting an error right when the _.vscode_ folder is being generated. When running this...

_mbed-vscode-generator -m NUCLEO_F401RE_

...I get this output...

Mbed VSCode generator, v1.0.0

Verifying dependencies:
✔ Mbed CLI installed
✔ Input directory exists
✔ Compiler found (/Users/Jorge/bin/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc)
✔ Debugger found (/usr/local/bin/pyocd-gdbserver)
✔ Target configured (NUCLEO_F401RE)

Input directory is "/Users/Jorge/Developer/mbedApps/Nucleo_blink_led"
Output directory is "/Users/Jorge/Developer/mbedApps/Nucleo_blink_led/.vscode"

Generating .vscode directory:
✘ Exporting to make_gcc_arm failed (see below)

[mbed] Working path "/Users/Jorge/Developer/mbedApps/Nucleo_blink_led" (program)

Traceback (most recent call last):
File "/Users/Jorge/Developer/mbedApps/Nucleo_blink_led/.temp/tools/project.py", line 423, in
main()
File "/Users/Jorge/Developer/mbedApps/Nucleo_blink_led/.temp/tools/project.py", line 415, in main
ignore=options.ignore
File "/Users/Jorge/Developer/mbedApps/Nucleo_blink_led/.temp/tools/project.py", line 145, in export
notify.info("Using targets from %s" % targets_json)
AttributeError: 'NoneType' object has no attribute 'info'
[mbed] ERROR: "/usr/local/opt/python@2/bin/python2.7" returned error.
Code: 1
Path: "/Users/Jorge/Developer/mbedApps/Nucleo_blink_led"
Command: "/usr/local/opt/python@2/bin/python2.7 -u /Users/Jorge/Developer/mbedApps/Nucleo_blink_led/.temp/tools/project.py -i make_gcc_arm -m NUCLEO_F401RE --profile debug --source ."
Tip: You could retry the last command with "-v" flag for verbose output

Any suggestion ?

Thanks.

[janjongboom]

@YoHidden This is a bug in the make_gcc_arm exporter:

janjongboom:~/repos/Nucleo_blink_led $ mbed export -i make_gcc_arm -m NUCLEO_F401RE
[mbed] Working path "/Users/janjongboom/repos/Nucleo_blink_led" (program)
Traceback (most recent call last):
  File "/Users/janjongboom/repos/Nucleo_blink_led/.temp/tools/project.py", line 423, in <module>
    main()
  File "/Users/janjongboom/repos/Nucleo_blink_led/.temp/tools/project.py", line 415, in main
    ignore=options.ignore
  File "/Users/janjongboom/repos/Nucleo_blink_led/.temp/tools/project.py", line 145, in export
    notify.info("Using targets from %s" % targets_json)
AttributeError: 'NoneType' object has no attribute 'info'
[mbed] ERROR: "/usr/bin/python" returned error.
       Code: 1
       Path: "/Users/janjongboom/repos/Nucleo_blink_led"
       Command: "/usr/bin/python -u /Users/janjongboom/repos/Nucleo_blink_led/.temp/tools/project.py -i make_gcc_arm -m NUCLEO_F401RE --profile debug --source ."
       Tip: You could retry the last command with "-v" flag for verbose output
---

Try https://github.com/ARMmbed/mbed-os-example-blinky instead, it should work.

Also added a note to the docs.

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.