Closed grisevg closed 4 years ago
Eclipse would fail to resolve portTICK_PERIOD_MS
I see the same on Eclipse (both Windows 7 and Ubuntu 16.04 LTS) and it gets me frustrated.
It's not perfect, as you have to manually specify include paths, path to IDF and path to the toolchain, but same goes for Eclipse.
@grisevg do you need to specify all include paths in VSCode or just one to the components folder as described in https://github.com/espressif/esp-idf/pull/157#issuecomment-267762873 ?
Regarding both issues above there is a branch together with testing report https://github.com/espressif/esp-idf/pull/157#issuecomment-270134045, that indicate possible resolution.
So far I did not have a chance to check VSCode to say what the good things I like about Eclipse are provided by VSCode as well, to justify the switch. People familiar with both VSCode and Eclipse should post their comments so Espressif team can gauge the interest.
@krzychb I also include up to components folder, and it resolves the functions very well.
I shall try the tasks.json file with my VSCode on Mac. It sounds like a good little shortcut. Thanks!
@krzychb @seopyoon cheers, including just components
folder works. I've updated the example config.
@krzychb most VSCode C/C++ features are covered here: https://code.visualstudio.com/docs/languages/cpp
Looks like it could be even possible to setup an interactive debugging with GDB right in the editor, but I don't have a JTAG device atm to test it.
I set up the tasks.json. How do I use this functionality? @grisevg
+1 on adding docs. VSCode is (er, will soon be) really awesome for ESP debugging!
Note that I am really close, but instead using launch.json
and perhaps only need to know the value for TargetArchitecture
. See: https://github.com/Microsoft/vscode-cpptools/issues/763
I've been able to single step an STM32 using VSCode: very cool! https://gojimmypi.blogspot.com/2017/05/vscode-remote-debugging-of-embedded.html I really hope to be able to do this with ESP32 (and ESP8266?).
if esp-idf is in the project folder symbols get found automatically. for windows you can also add the msys2, mingw32 and xtensa-esp32-elf bin folders to the path in tasks.json. make monitor has some trouble starting a console, you can edit the idf_monitor.py to output to stderr(task output window), or make a .cmd file with the python command in it and run that command from tasks. You can see how I work with it esp-idf-VSCode-template
It doesn't work in my vscode(Version 1.13.1).
"PATH" : "${env.PATH}:/home/grisevg/esp/xtensa-esp32-elf/bin"
change it to
"PATH" : "${env:PATH}:/home/grisevg/esp/xtensa-esp32-elf/bin"
@heymind Yeah, ${env.PATH} stopped working for me too after a update. Thanks for the fix
Anyone use it on Mac?? It used to work well, but after an update, (Not sure VSCode update or esp-idf update) all of them get red underlines. But, when command + click function, or struct, it successfully finds the referring ones.
So functionally, it is fine, but it's red everywhere. Please give me advice. My paths included in c_cpp_properties.json are:
"/usr/include",
"/Users/
@seopyoon Add this to your settings.json
"C_Cpp.intelliSenseEngine": "Tag Parser"
It is an issue with the new VSCode intellisense. This setting reverts it back to the old behavior.
See here https://github.com/Microsoft/vscode-cpptools/issues/690
It works but it's not context sensitive. So for me, Eclipse CDT is unfortunately better so far. I don't know much about VSCode to try to help but I am reading about it. It's lighter in memory for obvious reasons and it works faster than Eclipse in my opinion.
I am willing to donate my time regarding this matter. Any pointers, guidance and help will be greatly appreciated.
Thanks guys.
Some additional information ...
With the current version of VSCode, the includePath is not recursive. It says it right in the editor when you hover the mouse over the word includePath.
Hi guys,
I think it's possible to implement a tool which generates a compile_commands.json
and use it in VSCode now, as the newest C/C++ plugin has added support for this, see here: https://github.com/Microsoft/vscode-cpptools/tree/v0.14.0
I'll have a research later when I finish my exam tomorrow.
Regards, Jackson
Any progress from anyone on this? VSCode seems very popular nowadays, it would be great if the IDF would support it better :)
Hi all,
Maybe this is a bit off-topic, but I've made a CMake template for CLion users. Check here for more details: https://github.com/huming2207/esp32-cmake-helloworld
Currently this template can only used for CLion indexing, not ready for compiling the project.
Regards, Jackson Hu
This all seems to be deprecated in new version of visual code. as a result it is ignored. does anyone have an updated tasks.json for reference?
Guess we should try the official CMake now. They are rolling out the official support for CMake build system since v3.1 and it works fine in CLion.
For VSCode using CMake, probably here is a solution: https://medium.com/audelabs/c-development-using-visual-studio-code-cmake-and-lldb-d0f13d38c563
Sorry I need to correct my previous reply
Just try this: https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools
Works mostly perfect for ESP-IDF v3.1+ for now, although it is a bit slower than CLion.
IMHO it would also be great to support #vscode given that #vscode free, availible on Window, Linux and iOS; and is extensibile with a growing set of tool, extensions and language support.
Some additional information ...
With the current version of VSCode, the includePath is not recursive. It says it right in the editor when you hover the mouse over the word includePath.
"${env:IDF_PATH}/components/**"
seems to work for me.
Hi guys,
I have integrated ESP32 IDF development to VScode on windows. I'm only missing the make flash command that I can't make worw. At the moment I have to open a ming32 terminal and navigate to the project root and launch the make flash command manually. I would like to have a VS code task to flash the device. Here is my current tasks.json :
{
"version": "2.0.0",
"command": "C:/Espressif/ESP32/msys32/usr/bin/bash",
"args": ["--login","-c"],
"type": "shell",
"presentation": {
"reveal": "always",
},
"suppresslabel": true,
"options": {
"cwd": "${workspaceRoot}",
"env": {
"CHERE_INVOKING": "enabled_from_arguments",
"MSYSTEM": "MINGW32"
}
},
"tasks": [
{
"label": "build all",
"group": "build",
"command": "C:/Espressif/ESP32/msys32/usr/bin/bash",
"type": "shell",
"args": [
"--login","-c",
"make",
"all",
"-j10"
],
"presentation": {
"reveal": "always",
},
"problemMatcher": {
"owner": "cpp",
"fileLocation": "absolute",
"pattern": {
"regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
"file": 1,
"line": 2,
"column": 3,
"severity": 4,
"message": 5
}
}
},
{
"label": "build app",
"group": "build",
"command": "C:/Espressif/ESP32/msys32/usr/bin/bash",
"type": "shell",
"args": [
"--login","-c",
"make",
"app",
"-j10"
],
"presentation": {
"reveal": "always",
},
"problemMatcher": {
"owner": "cpp",
"fileLocation": "absolute",
"pattern": {
"regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
"file": 1,
"line": 2,
"column": 3,
"severity": 4,
"message": 5
}
}
},
{
"label": "clean app",
"command": "C:/Espressif/ESP32/msys32/usr/bin/bash",
"type": "shell",
"args": [
"--login","-c",
"make",
"app-clean",
"-j10"
],
"presentation": {
"reveal": "always",
},
},
{
"label": "flash app",
"command": "C:/Espressif/ESP32/msys32/usr/bin/bash",
"type": "shell",
"args": [
"--login","-c",
"make",
"app-flash"
],
"presentation": {
"reveal": "always",
},
},
{
"label": "monitor",
"type":"process",
"windows": {
"command": "C:/Espressif/ESP32/msys32/mingw32.exe",
"args": [
"make",
"monitor"
],
},
"presentation": {
"reveal": "always",
},
"problemMatcher": []
},
{
"label": "menuconfig",
"type":"process",
"windows": {
"command": "C:/Espressif/ESP32/msys32/mingw32.exe",
"args": [
"make",
"menuconfig"
]
},
"presentation": {
"reveal": "always",
},
"problemMatcher": []
}
]
}
Launching the "flah app" task result in the following :
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5 Compiler version: 5.2.0 Python requirements from C:/Espressif/ESP32/msys32/home/theom/esp32/esp-idf/requirements.txt are satisfied. Project is not inside a git repository, will not use 'git describe' to determine PROJECT_VER. App "template" version: 1 To flash all build output, run 'make flash' or: python /home/theom/esp32/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port COM29 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0xd000 /home/theom/esp32/projects/template/build/ota_data_initial.bin 0x1000 /home/theom/esp32/projects/template/build/bootloader/bootloader.bin 0x10000 /home/theom/esp32/projects/template/build/template.bin 0x8000 /home/theom/esp32/projects/template/build/partitions_two_ota.bin
But nothing is uploaded. What can I do to integrate this functionnality to VScode?
Hello, im using this for flash: { "label": "flash app", "command": "idf.py", "type": "shell", "args": [ "-p", "COM4", "flash" ], "presentation": { "reveal": "always" } },
I have to agree. VSCode works much better as Eclipse
For added usefulness, you can use this vs extension. https://marketplace.visualstudio.com/items?itemName=cantonios.project-templates There's a ESP32 project template here - https://github.com/albertsuwandhi/VSCode-ESP-IDF
I have found that adding the build folder before the ESP-IDF folder on the include path solves the problems with portTICK_PERIOD_MS
etc:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceRoot}/main/**",
"${workspaceRoot}/build/include/",
"${env:IDF_PATH}/components/**"
],
"browse": {
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": ""
},
"intelliSenseMode": "gcc-x64"
}
],
"version": 4
}
Relevant lines:
${workspaceRoot}/build/include/
${env:IDF_PATH}/components/**
This is starting to look very good :)
@grisevg may you update your post?
@JosuGZ Did you mean adding the build path before the IDF path?
@JosuGZ Did you mean adding the build path before the IDF path?
Oh, yes, in case of disagreement, code rules ;) Edited.
Hi folks! I post here my best attempt to run ESP-IDF v4.0 (idf.py, CMake, Ninja...) in VSCode.
By the way, I don't want to spoil but I checked the job offers @ Espressif, and they probably hired some guy to make an official VSCode Extension. Great news for VSCode users that don't want to bother with PlatformIO 😃
I have an error when trying to build task:
running command$ bash -c Build make app Failed to launch external program "bash" -c Build make app. spawn bash ENOENT
Tried manually on the terminal:
"bash" -c Build make app
Works.
I am using VSCode v1.38.1
Any help appreciated.
ESP-IDF v4.0
Hi folks! I post here my best attempt to run ESP-IDF v4.0 (idf.py, CMake, Ninja...) in VSCode.
From scratch:
- Follow the new ESP-IDF Get Started Guide (latest)
- Download and install VSCode
- Install 3 VSCode extensions: C/C++, Native Debug, Task Explorer
Inside your VSCode project folder, add these files:
.vscode/tasks.json (click to expand) .vscode/launch.json (click to expand) .vscode/c_cpp_properties.json (click to expand) .vscode/settings.json (click to expand) You should now see the different tasks in the Explorer:
And you should be able to start a debug session:
Some quirks:
- You should adapt the OpenOCD script to your match your ESP-32 dev board (if not ESP-WROVER-KIT), and set the path to gdb manually.
- The correct firmware must be flashed before starting a debug session (OpenOCD is not configured to flash the ESP32).
- OpenOCD is started automatically before a debug session, but is not terminated after the debug session. You must terminate it to flash a new firmware (just like the ESP Monitor)...
- I tested on macOS only, but it should work on Linux and Windows as well. Please give some feedback.
- You can use ESP Monitor while debugging only if it was launched before the debug session. So the correct order is Flash CPU, Start Monitor, Start Debug.
- If you're on a ESP-WROVER-KIT, specially on macOS, you may have to unplug and replug your device after a debug session in order to access the UART functions again (this guide didn't work for me). Still looking for a workaround...
Followed the instructions, but I'm experiencing issues with the included files:
Additional info:
Any ideas on how to resolve this?
@trishaulr VSCode locates the include files in the build folder of your project, thus it has to be compiled once. Does the Build task run fine ?
Hey folks, it's been 2 years, PlatformIO exists now and it works really well. I'm closing the issue.
@trishaulr VSCode locates the include files in the build folder of your project, thus it has to be compiled once. Does the Build task run fine ?
Thanks @motla tried Build but I get an error relating to the install: (Note all the tools have been installed; I'm able to compile and build from CLI without problems).
Adding ESP-IDF tools to PATH... Not using an unsupported version of tool xtensa-esp32-elf found in PATH: 1.22.0-80-g6c4433a-5.2.0. WARNING: directory for tool xtensa-esp32s2-elf version esp32s2-dev-4-g3a626e9-8.2.0 is present, but tool was not found ERROR: tool xtensa-esp32s2-elf has no installed versions. Please run '/Users/Trishaul/esp32/esp-idf/install.sh' to install it. ERROR: tool esp32ulp-elf has no installed versions. Please run '/Users/Trishaul/esp32/esp-idf/install.sh' to install it. ERROR: tool openocd-esp32 has no installed versions. Please run '/Users/Trishaul/esp32/esp-idf/install.sh' to install it. /bin/bash: idf.py: command not found The terminal process terminated with exit code: 127
Terminal will be reused by tasks, press any key to close it.
@grisevg Yes it's a solution, but afaik PlatformIO it is not compatible with IDF 4.0 (we can't even specify the IDF version to use to compile a project so it's not suitable for a serious company - see here). People should have the choice to use the default Espressif toolchain under VSCode with no extra overlay. But it's not an issue indeed, more like a suggestion.
@motla Fair enough, I wasn't aware of that. But open a new issue, this one has exceeded its purpose.
@trishaulr it's probably some mixing of IDF 3 and 4. Please be sure to remove all IDF folders and calls in your .bash_profile file. Then install IDF 4 from scratch like specified in the docs: https://docs.espressif.com/projects/esp-idf/en/latest/get-started/index.html
@trishaulr it's probably some mixing of IDF 3 and 4. Please be sure to remove all IDF 3 folders and calls in your .bash_profile file
@motla Apologies if I'm missing something basic, but there just seems to be one IDF link under the profile:
/Users/Trishaul/esp32/xtensa-esp32-elf/bin /Library/Frameworks/Python.framework/Versions/3.6/bin /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotne :~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands
@trishaulr Try to remove the first line. Toolchain path doesn't have to be in the bash profile file any more, as it's now defined by calling IDF script export.sh (see here). Moreover, it is now installed automatically under ~/.espressif/tools when you call install.sh
@trishaulr Try to remove the first line. Toolchain path doesn't have to be in the bash profile file any more, as it's now defined by calling IDF script export.sh (see here). Moreover, it is now installed automatically under ~/.espressif/tools when you call install.sh
@motla ; eventually gave up and did a clean rebuild of my entire machine. This time I came across a different error:
IDF_PATH must be set before sourcing this script zsh:1: command not found: idf.py The terminal process terminated with exit code: 127
I've opened a terminal in VCS and set IDF_PATH; but it doesn't seem to resolve this issue. Any suggestions as to how to resolve this?
@trishaulr Try to remove the first line. Toolchain path doesn't have to be in the bash profile file any more, as it's now defined by calling IDF script export.sh (see here). Moreover, it is now installed automatically under ~/.espressif/tools when you call install.sh
@motla ; eventually gave up and did a clean rebuild of my entire machine. This time I came across a different error:
IDF_PATH must be set before sourcing this script zsh:1: command not found: idf.py The terminal process terminated with exit code: 127
I've opened a terminal in VCS and set IDF_PATH; but it doesn't seem to resolve this issue. Any suggestions as to how to resolve this?
UPDATE: Managed to get around the IDF_PATH error by editing tasks.json to include the full path to idf.py. However now, a different error has popped up: The following Python requirements are not satisfied: click>=5.0 pyparsing>=2.0.3,<2.4.0 pyelftools>=0.22
(Note: all of these requirements are actually met; I've double-checked the package versions)
By the way, I don't want to spoil but I checked the job offers @ Espressif, and they probably hired some guy to make an official VSCode Extension. Great news for VSCode users that don't want to bother with PlatformIO 😃
For those who didn't see, it is now available at https://github.com/espressif/vscode-esp-idf-extension
Thanks for the post @motla !
Please give it a try and let us know how to make it awesome for you all.
Hello All,
It's saying this is closed so I may post a new thread.
I've been doing things via the command line in win10 thus far; but want to be able to debug via JTAG and a decent GUI - I've set up Eclipse and VS Code and have run into the various issues with various degrees of success - but, in the opinions of those here - which is the best environment for effective JTAG debugging - Eclipse or VS Code?
Also, I just picked up the ESP-Prog units - I do have a Segger - which one is better?
TIA, John W.
Currently Visual Studio Code extension we haven't released Debugging support (coming really soon) but Eclipse extension have very nice debug experience.
You should definitely try them both and see which one works best for you.
OK Brian,
Any ETA on when that will show up in VS Code?
I'll focus on Eclipse then at the moment. I'm also having an issue with VS Code finding tools from other projects even though all of the IDF paths are explicitly defined - need to figure out how to make VS Code stop that.
Thanks, John
On Fri, Mar 20, 2020 at 4:29 AM Brian A. Ignacio notifications@github.com wrote:
Currently Visual Studio Code extension we haven't released Debugging support (coming really soon) but Eclipse have very nice debug experience.
You should definitely try them both and see which one works best for you.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/303#issuecomment-601653285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARTWJ2PIBRJTXWTJONZ5NDRINHQ7ANCNFSM4C52QFYA .
Although we don't have debug support in our extension, we do provide some templates for launch.json so you can debug with the C/C++ extension with the xtensa toolchain.
Please take a look at our repository https://github.com/espressif/vscode-esp-idf-extension for any ESP-IDF extension for Visual Studio Code issues and suggestions.
Brian,
Yes - thanks for that.
Best Regards, John
On Sun, Mar 22, 2020 at 7:17 PM Brian A. Ignacio notifications@github.com wrote:
Although we don't have debug support in our extension, we do provide some templates for launch.json so you can debug with the C/C++ extension with the xtensa toolchain.
Please take a look at our repository https://github.com/espressif/vscode-esp-idf-extension for any ESP-IDF extension for Visual Studio Code issues and suggestions.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/303#issuecomment-602326192, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARTWJ2QGFXN7ZFSDRFRJUTRI3BCFANCNFSM4C52QFYA .
@motla I'm facing the same issue. It builds fine, but it complains of not finding a downstream dependency. Any ideas?
@julianiaccopucci This happens because you need to configure the C/C++ extension to resolve headers as suggested in the message try using compile_commands.json in your project's .vscode/c_cpp_properties.json
as described in here
Hey guys,
I've tried configuring Visual Studio Code for IDF development on Linux and it works really well (for example Eclipse would fail to resolve
portTICK_PERIOD_MS
for me, while VSCode resolves it nicely).Here's what I had to do to get basic functionality working:
.vscode/c_cpp_properties.json
with header search paths:.vscode/tasks.json
with a build task and error parserIt's not perfect, as you have to manually specify include path, path to IDF and path to the toolchain, but same goes for Eclipse.
Do you guys think it's worth adding to the docs? Of course question of what IDE is better is a personal choice, but considering that VSCode is very popular, cross-platform and works really well, I think it's worth adding to the getting started docs.