- This topic has 9 replies, 3 voices, and was last updated 6 years, 10 months ago by
.
-
Posts
-
Hi,
I am developing some software with the ESP32 under VisualGDB project and have run into several bugs, not caused by VisualGDB. Upon going to the Espressif repo HERE I discovered that my problem was very recently fixed in an update. Unfortunately, there doesn’t seem to be a new framework update in VisualGDB for me to download. Since this bug of mine is actually a hindrance to my project moving forward, I’d like to know if there was some way I could instruct VisualGDB to build my project using the source from the linked Git repo? This way I could stay up to date must faster if need be.
Side note: It’s apparently not as simple as replacing the project esp32-BSPs with the git repo’s version. Any pointers on moving from the repo to a VisualGDB project would be extremely helpful. Judging by the file structure of the included BSPs with a default Visual GDB blinky project for the ESP32, it looks like you guys copied straight from the repo at one point or another as well.
Update:
I built my project following the Espressif ESP32 getting started tutorial here using the latest commit from the official Espressif IDF github repo mentioned earlier. This verified that my bug was fixed using the updated code, so now I’m quite motivated to figure out how to instruct VisualGDB to utilize the repo source code instead of the default installed BSPs. I’ll post more as I figure things out if I haven’t heard back from the support team.
Update 2:
I discovered the Sysprogs BSP generator project: git repo and the associated wiki here
This looks promising. Edit: Some samples of using the generators from scratch would be really nice. The wiki describes how to use the code at a high level, which I understand, but I’m struggling how to parse that down into the details of actually using the tools for my project.
Hi,
VisualGDB actually supports the original ESP-IDF projects using a slightly different mechanism (it is fully described here), so we would advise updating the IDF in the esp-idf.orig folder and trying it out.
The generator usually needs minor updates between ESP-IDF releases due to breaking changes. We are planning to update it (and also release an updated toolchain) within the next month.
Hi guys,
good to hear that sysprogs is going to release new ESP32 update.
I’m using external ESP IDF (just changed ESP_PATH to my own tree) more than half year. IMHO using any other way (BSP generator and co) in ESP32 case is a way to nowhere:
1) Their stack is too big to be compiled as single module, a lot of renames and tricks are need to support that.
2) Their stack quality is far from … adequate. If you have something a bit more complex than ‘hello led’ you need to update their stack offten, merging different fixes, and sometimes – updating 3rd party libraries manually (for example – libsoudium) and it is not quick task if we use generated BSP.
3) If you are part of team you can’t assume that everyone is using VisualGDB – our hardware engineer uses Linux, firmware – Windows, managment – OS X. All of them need to compile firmware. So they have to use ESP-IDF path to build firmware.
4) All 3rd party libraries ported to ESP32 are available as ESP-IDF ‘components’ – no sense to spend any time integrating them again into thing generated by BSP generator.
VisualGDB guys, if I could suggest:
- Use ESP-IDF way as your primary integration path (will save some time on BSPGenerator).
- Allow to replace/update xtensa toolchain by this one (right now trying to resolve xtensa-esp32-elf-gcc: error: unrecognized command line option ‘-mfix-esp32-psram-cache-issue’ which is not supported by your toolchain).
- Allow to replace/update OpenOCD.
- Add article explaining how to work with ‘Full-custom mode’ – that would be helpful (tried to integrate Espressif’s OpenOCD + gcc – was unable to get debugger working – don’t recall details – it was half year ago).
And thanks for your great tool!
Support:
This sounds like a much better solution than the route I was trying to go. I’ve made it through most of the linked tutorial, however building the imported files leads to an error with the toolchain. Upon building, the output windows spits out the message included in the attached file.
Obviously there is the issue of the toolchain being out of date. I built originally with the latest from Espressif here and tried to update the VisualGDB toolchain from the package manager, but found I had no updates available. I’m guessing that to somehow switch out the toolchain I would need a modified version of that C:\SysGCC\esp32\bin\bash.exe file? Not too sure how to proceed.Jsmith:
What is your setup like for utilizing the external ESP-IDF? Are you debugging inside of the VisualGDB environment? That’s primarily what I am interested in as I can build the code fine with the external tools if need be. I’ve become addicted to the VisualGDB style of interactive debugging as it seriously increases my productivity
To replicate my setup you need to:
- install Win10/64 + VS2015 + VisualGDB (+ GitExtensions + VisualAssist, but these are very optional)
- follow VisualGDB manul
- then, to make it simple, edit [esp32 toolchain]\etc\profile, adjust export IDF_PATH=/esp-idf.orig to point to your ESP IDF path (for example export IDF_PATH=/cygdrrive/c/project/esp-idf). in my case /cygdrrive/c/project/esp-idf is part of my project checkout – if you do something not trivial then you’ll want to keep esp-idf within your project tree – most likely you’ll need to tweak esp-idf sources and/or want to build your project exactly with your version of esp-idf.
This setup allows to use VS editing features + VisualGDB debugger. Note that ESP is not so comfortable for debugging as ARMs are. It is limited to 2 hardware breakpoints and debugging is not very stable. IMO VGDB guys did everythint what they could do – their debugger works perfectly with NRF51 or remote Linux, slow but still usable with Android native debugging (mainly due to huge amount of source files).
Thanks jsmith. I’ll try that out later tonight. I’ve definitely noticed the lackluster debugging capabilities as compared to ARM. I do most of my projects on some form of an ARM based chip and migrating over to the ESP was a bit of a shock (2 breakpoints?!). Ah well. I’d agree that VisualGDB has done a lot.
Hi,
jsmith, thanks for the suggestion. We are actually experimenting with a custom project subsystem for the ESP-IDF projects that will basically map the internal ESP-IDF structure directly to Solution Explorer (similar to our Advanced CMake subsystem). Once we release it, it will let you use the original esp-idf while having VS-style look-and-feel. We cannot promise any specific deadlines for this yet, however we will likely release it in the first half of 2018.
- You must be logged in to reply to this topic.