jsmith

Forum Replies Created

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • in reply to: Environment variables #21000
    jsmith
    Participant

    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.

    in reply to: Environment variables #20998
    jsmith
    Participant

    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/

     

    in reply to: ESP32 toolchain #20975
    jsmith
    Participant

    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.

     

     

    in reply to: ESP32 toolchain #20970
    jsmith
    Participant

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

    Would be nice…

    in reply to: ESP32 toolchain #20942
    jsmith
    Participant

    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.

    in reply to: Point VisualGDB to use git repo for ESP32 build #13463
    jsmith
    Participant

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

    in reply to: Point VisualGDB to use git repo for ESP32 build #13448
    jsmith
    Participant

    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, 9 months ago by jsmith.
    • This reply was modified 6 years, 9 months ago by jsmith.
    • This reply was modified 6 years, 9 months ago by jsmith.
    in reply to: ESP-IDF 3.x #12267
    jsmith
    Participant

    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 7 years, 2 months ago by jsmith.
Viewing 8 posts - 1 through 8 (of 8 total)