[jsmith]

Hi,

IMO $(SolutionDir) could be more flexible. My other project is nRF5x based and also keeps nRF SDK within my source tree (project is a few years old – using latest nRF SDK would be stupid idea as it most likely will break everything). Don’t recall details but $(SolutionDir) would also work in nRF case while ‘IDF checkout’ solution – no.

It is just a suggestion – I’ve workaround and it works for me.

[jsmith]

For example – to speficify IDF path in build environment I need to set IDF_PATH=$(ProjectDir.forwardslashes)/../esp-idf

Folder structure is as follows:

Solution/

.git/

esp-idf-patched-and-customized/

Project1/

Project2/

ProjectN/

 

[jsmith]

First of all – thanks for your help. I really appericiate that.

I did it like you advised with some modifications (adjusted existing workspace modifying $(Solution).xml, set of *.vcxproj, etc)

-<ToolchainID>com.visualgdb.xtensa-esp32-elf</ToolchainID>
=<ToolchainVersion>5.2.0/7.10/r9</ToolchainVersion>
+<ToolchainID>4365939a-fe3e-467f-bd5b-fa8efeebad5a</ToolchainID>
+<ToolchainVersion>5.2.0/(crosstool-NG/r0</ToolchainVersion>

and similar changes in corresponding files to allow VGDB pickup OpenOCD from BSP.

 

 

[jsmith]

We can also help you integrate the original ESP32 toolchain into VisualGDB

Would be nice…

[jsmith]

Updated my profile – now it points to email associated with license. You can contact me at this email or simply reply here – IMO it could be interested for others too.

[jsmith]

To replicate my setup you need to:

1. install Win10/64 + VS2015 + VisualGDB  (+ GitExtensions + VisualAssist, but these are very optional)
2. follow VisualGDB manul
3. 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).

[jsmith]

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:

1. Use ESP-IDF way as your primary integration path (will save some time on BSPGenerator).
2. 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).
3. Allow to replace/update OpenOCD.
4. 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!

 

• This reply was modified 6 years, 3 months ago by jsmith.
• This reply was modified 6 years, 3 months ago by jsmith.
• This reply was modified 6 years, 3 months ago by jsmith.

[jsmith]

Thanks for your reply.

After trying to tweak ESP32 BSP generator to import latest ESP-IDF (took me some time but I did it) I think that custom build (https://visualgdb.com/tutorials/esp32/esp-idf/) is best possible way to develop for ESP32.

• This reply was modified 6 years, 8 months ago by jsmith.

[Author]

Posts