[doingnz]

Before i create an issue in ESP-IDF bugtracker, thoughts why the following works under msys32 build without ‘0x’ prefix, but in VisualGDB environment requires ‘0x’ prefix for default and range cannot be hex?

config SPIFFS_BASE_ADDR
hex "SPIFFS Base address"
range 100000 1FFE000
default 180000
help
Starting address of the SPIFFS area in ESP32 Flash

[doingnz]

if I specify:

config SPIFFS_BASE_ADDR
hex “SPIFFS Base address”
default 0x180000
range 1048576 33546240
help
Starting address of the SPIFFS area in ESP32 Flash

It will build, and VisualGDB UI for PROJECT PROPERTIES will require value to be entered as hex prefixed with ‘0x’, but it will ignore the range check. i.e. I can enter 0x100 and it will be saved as the config value.

Obviously not an urgent fix as I can build and run the project. 🙂

[doingnz]

The problem appears to be with “range”.

i.e. this is OK

config SPIFFS_BASE_ADDR
hex “SPIFFS Base address”
default 0x180000
help
Starting address of the SPIFFS area in ESP32 Flash

but this is not

config SPIFFS_BASE_ADDR
hex “SPIFFS Base address”
range 0x100000 0x1FFE000
default 0x180000
help
Starting address of the SPIFFS area in ESP32 Flash

 

[doingnz]

I tried adding the 0x prefix earlier. Still fails, but with a different error. i.e. with

config SPIFFS_BASE_ADDR
hex “SPIFFS Base address”
range 0x100000 0x1FFE000
default 0x180000
help
Starting address of the SPIFFS area in ESP32 Flash

error is

Traceback (most recent call last):
File "C:/SysGCC/esp32/esp-idf/v3.1/tools/kconfig_new/confgen.py", line 292, in <module>
main()
File "C:/SysGCC/esp32/esp-idf/v3.1/tools/kconfig_new/confgen.py", line 106, in main
output_function(config, temp_file)
File "C:/SysGCC/esp32/esp-idf/v3.1/tools/kconfig_new/confgen.py", line 258, in write_json_menus
config.walk_menu(write_node)
File "C:/SysGCC/esp32/esp-idf/v3.1/tools/kconfig_new/kconfiglib.py", line 966, in walk_menu
callback(node)
File "C:/SysGCC/esp32/esp-idf/v3.1/tools/kconfig_new/confgen.py", line 232, in write_node
greatest_range = [int(min_range.str_value), int(max_range.str_value)]
ValueError: invalid literal for int() with base 10: '0x100000'

 

[doingnz]

Try that attachment again after deleting the folders ‘mkspiffs’ and ‘spiffs_image’. The original folders available from github repo as no changes relevant to running on ESP32

Attachments:

You must be logged in to view attached files.

[doingnz]

The project is now running on the ESP32-WROVER-KIT v4.1 with the workaround of using the int and decimal values in place of the HEX.

There are a couple of other small edits from the original library. Demo not perfect, but runs blinky + tft_demo as tasks.

Attached Zip of project if anyone wants to play further.

[doingnz]

the step on September 29, 2018 at 05:28 where BUILD_VERSION is set in CMakeSettings.json is not a VisualGDB project. It uses a regular VS2017 folder+ CMAKE project. Not sure how you want me to test? There are no VisualGDB settings? It is a folder project.

I made a hello-world sample. Modified the CMakeLists.txt to the following

# The following lines of boilerplate have to be in your project's
# CMakeLists in this exact order for cmake to work correctly
cmake_minimum_required(VERSION 3.5)

include($ENV{IDF_PATH}/tools/cmake/project.cmake)

set(BUILD_VERSION 0.9.99.999)
set(PROJECT_VERSION 1.2.3.4)

# set default version
if(NOT BUILD_VERSION)
set(BUILD_VERSION 0.0.0.0)
endif()
message(STATUS "BUILD_VERSION=${BUILD_VERSION}")
message(STATUS "PROJECT_VERSION=${PROJECT_VERSION}")
message(STATUS "######################################################################################")
project(nanoFramework VERSION ${BUILD_VERSION})
message(STATUS "BUILD_VERSION=${BUILD_VERSION}")
message(STATUS "PROJECT_VERSION=${PROJECT_VERSION}")
message(STATUS "######################################################################################")
message(STATUS "Building nanoFramework version ${PROJECT_VERSION} using build type '${CMAKE_BUILD_TYPE}'.")
message(STATUS "Source directory is '${PROJECT_SOURCE_DIR}'.")
message(STATUS "Build directory is '${PROJECT_BINARY_DIR}'.")
message(STATUS "Toolchain is '${TOOLCHAIN}'.")
message(STATUS "######################################################################################")

Then on clean and rebuild the initial output shows that both PROJECT_VERSION and BUILD_VERSION are set initially, but PROJECT_VERSION gets cleared when project(…) statement is executed. There is a lot that happens as a result of the project(….) statement between the “#####” just before and after the project(…) statement.

 

------ Rebuild All started: Project: nanoFramework, Configuration: Debug VisualGDB ------
Removing C:\Projects\esp\EmbeddedProject5\EmbeddedProject5/VisualGDB/Debug...
Reconfiguring project due to missing Makefile...
Found Git: C:/SysGCC/esp32/usr/bin/git.exe (found version "2.15.0")
BUILD_VERSION=0.9.99.999
PROJECT_VERSION=1.2.3.4
######################################################################################
-- Building empty aws_iot component due to configuration
Component names: main app_trace xtensa-debug-module app_update spi_flash bootloader_support mbedtls lwip vfs ethernet tcpip_adapter micro-ecc aws_iot jsmn bootloader bt nvs_flash coap console cxx driver esp-tls nghttp esp32 log pthread smartconfig_ack wpa_supplicant esp_adc_cal esp_http_client esp_https_ota esptool_py expat fatfs wear_levelling sdmmc freertos heap idf_test json libsodium mdns newlib openssl partition_table soc spiffs ulp
Component paths: C:/Projects/esp/EmbeddedProject5/EmbeddedProject5/main;C:/SysGCC/esp32/esp-idf/v3.1/components/app_trace;C:/SysGCC/esp32/esp-idf/v3.1/components/xtensa-debug-module;C:/SysGCC/esp32/esp-idf/v3.1/components/app_update;C:/SysGCC/esp32/esp-idf/v3.1/components/spi_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader_support;C:/SysGCC/esp32/esp-idf/v3.1/components/mbedtls;C:/SysGCC/esp32/esp-idf/v3.1/components/lwip;C:/SysGCC/esp32/esp-idf/v3.1/components/vfs;C:/SysGCC/esp32/esp-idf/v3.1/components/ethernet;C:/SysGCC/esp32/esp-idf/v3.1/components/tcpip_adapter;C:/SysGCC/esp32/esp-idf/v3.1/components/micro-ecc;C:/SysGCC/esp32/esp-idf/v3.1/components/aws_iot;C:/SysGCC/esp32/esp-idf/v3.1/components/jsmn;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader;C:/SysGCC/esp32/esp-idf/v3.1/components/bt;C:/SysGCC/esp32/esp-idf/v3.1/components/nvs_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/coap;C:/SysGCC/esp32/esp-idf/v3.1/components/console;C:/SysGCC/esp32/esp-idf/v3.1/components/cxx;C:/SysGCC/esp32/esp-idf/v3.1/components/driver;C:/SysGCC/esp32/esp-idf/v3.1/components/esp-tls;C:/SysGCC/esp32/esp-idf/v3.1/components/nghttp;C:/SysGCC/esp32/esp-idf/v3.1/components/esp32;C:/SysGCC/esp32/esp-idf/v3.1/components/log;C:/SysGCC/esp32/esp-idf/v3.1/components/pthread;C:/SysGCC/esp32/esp-idf/v3.1/components/smartconfig_ack;C:/SysGCC/esp32/esp-idf/v3.1/components/wpa_supplicant;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_adc_cal;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_http_client;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_https_ota;C:/SysGCC/esp32/esp-idf/v3.1/components/esptool_py;C:/SysGCC/esp32/esp-idf/v3.1/components/expat;C:/SysGCC/esp32/esp-idf/v3.1/components/fatfs;C:/SysGCC/esp32/esp-idf/v3.1/components/wear_levelling;C:/SysGCC/esp32/esp-idf/v3.1/components/sdmmc;C:/SysGCC/esp32/esp-idf/v3.1/components/freertos;C:/SysGCC/esp32/esp-idf/v3.1/components/heap;C:/SysGCC/esp32/esp-idf/v3.1/components/idf_test;C:/SysGCC/esp32/esp-idf/v3.1/components/json;C:/SysGCC/esp32/esp-idf/v3.1/components/libsodium;C:/SysGCC/esp32/esp-idf/v3.1/components/mdns;C:/SysGCC/esp32/esp-idf/v3.1/components/newlib;C:/SysGCC/esp32/esp-idf/v3.1/components/openssl;C:/SysGCC/esp32/esp-idf/v3.1/components/partition_table;C:/SysGCC/esp32/esp-idf/v3.1/components/soc;C:/SysGCC/esp32/esp-idf/v3.1/components/spiffs;C:/SysGCC/esp32/esp-idf/v3.1/components/ulp
The ASM compiler identification is GNU
Found assembler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
The C compiler identification is GNU 5.2.0
The CXX compiler identification is GNU 5.2.0
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Building empty aws_iot component due to configuration
Adding linker script C:/Projects/esp/EmbeddedProject5/EmbeddedProject5/VisualGDB/Debug/esp32/esp32_out.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.common.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.peripherals.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.libgcc.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.spiram_incompatible_fns.ld
Component libraries: ;main;app_trace;xtensa-debug-module;app_update;spi_flash;bootloader_support;mbedtls;lwip;vfs;ethernet;tcpip_adapter;micro-ecc;aws_iot;jsmn;bt;nvs_flash;coap;console;cxx;driver;esp-tls;nghttp;esp32;log;pthread;smartconfig_ack;wpa_supplicant;esp_adc_cal;esp_http_client;esp_https_ota;expat;fatfs;wear_levelling;sdmmc;freertos;heap;idf_test;json;libsodium;mdns;newlib;openssl;soc;spiffs;ulp
BUILD_VERSION=0.9.99.999
PROJECT_VERSION=
######################################################################################
Building nanoFramework version using build type 'DEBUG'.
Source directory is 'C:/Projects/esp/EmbeddedProject5/EmbeddedProject5'.
Build directory is 'C:/Projects/esp/EmbeddedProject5/EmbeddedProject5/VisualGDB/Debug'.
Toolchain is ''.
######################################################################################
Configuring done
Generating done

 

[doingnz]

Thank you for the updated VisualGBD… I have installed it and will play.

Regarding the project(….) statement, it works correctly with regular CMake in VS2017 and building an ESP32 / IDF version of nanoFramework.

With the Build Version defined in the VS2017 recognised CMakeSettings.json as

"variables": [
{
"name": "BUILD_VERSION",
"value": "0.9.99.999"
},

and the following in CMakeLists.txt

# set default version
if(NOT BUILD_VERSION)
set(BUILD_VERSION 0.0.0.0)
endif()
project(nanoFramework VERSION ${BUILD_VERSION})
<h6>#################
message(STATUS "######################################################################################")
message(STATUS "Building nanoFramework version ${PROJECT_VERSION} using build type '${CMAKE_BUILD_TYPE}'.")
message(STATUS "Source directory is '${PROJECT_SOURCE_DIR}'.")
message(STATUS "Build directory is '${PROJECT_BINARY_DIR}'.")
message(STATUS "Toolchain is '${TOOLCHAIN}'.")
message(STATUS "######################################################################################")
#######################</h6>
the output is the expected

1> -- ######################################################################################
1> -- Building nanoFramework version 0.9.99.999 using build type 'Debug'.
1> -- Source directory is 'C:/Projects/esp/nf-interpreter'.
1> -- Build directory is 'C:/Projects/esp/nf-interpreter/build'.
1> -- Toolchain is 'GCC'.
1> -- ######################################################################################

 

• This reply was modified 6 years, 2 months ago by doingnz.

[doingnz]

Thank you for the updated VisualGDB. The folder layout is fixed.

I have confirmed the  problem with ${PROJECT_VERSION} remains. You can reproduce it by creating a standard hello-world example with the new cmake VisualGDB. Then use the following CMakeLists.txt (i.e. use a version of project(…) that attempts to set PROJECT_VERSION.

# The following lines of boilerplate have to be in your project's
# CMakeLists in this exact order for cmake to work correctly
cmake_minimum_required(VERSION 3.5)

include($ENV{IDF_PATH}/tools/cmake/project.cmake)
#project(hello-world)

set(BUILD_VERSION "0.9.99.999")
message(STATUS "###############################")
project(hello-world VERSION ${BUILD_VERSION})
message(STATUS "Building hello_world version ${PROJECT_VERSION}.")
message(STATUS "###############################")
set(PROJECT_VERSION "0.9.99.999")
message(STATUS "Building hello_world version ${PROJECT_VERSION}.")

The ##### help to mark the output range of interest.  You can see from the above there are no statements in the CMakeLists.txt to set ${PROJECT_VERSION} between the two lines of ######### characters. message(…) is depending on the CMake system to set ${PROJECT_VERSION}. The output below shows there is no version information as PROJECT_VERSION has not been set. The subsequent set will define the PROJECT_VERSION and it will then be reported correctly in the output.

Is it possible a PROJECT_VERSION is being set in a Windows Environment that is discard as part of the process of VisualGDB launching CMake?

Reconfiguring project due to missing Makefile...
Found Git: C:/SysGCC/esp32/usr/bin/git.exe (found version "2.15.0")
###############################
-- Building empty aws_iot component due to configuration
Component names: main app_trace xtensa-debug-module app_update spi_flash bootloader_support mbedtls lwip vfs ethernet tcpip_adapter micro-ecc aws_iot jsmn bootloader bt nvs_flash coap console cxx driver esp-tls nghttp esp32 log pthread smartconfig_ack wpa_supplicant esp_adc_cal esp_http_client esp_https_ota esptool_py expat fatfs wear_levelling sdmmc freertos heap idf_test json libsodium mdns newlib openssl partition_table soc spiffs ulp
Component paths: C:/Projects/esp/EmbeddedProject4/EmbeddedProject4/main;C:/SysGCC/esp32/esp-idf/v3.1/components/app_trace;C:/SysGCC/esp32/esp-idf/v3.1/components/xtensa-debug-module;C:/SysGCC/esp32/esp-idf/v3.1/components/app_update;C:/SysGCC/esp32/esp-idf/v3.1/components/spi_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader_support;C:/SysGCC/esp32/esp-idf/v3.1/components/mbedtls;C:/SysGCC/esp32/esp-idf/v3.1/components/lwip;C:/SysGCC/esp32/esp-idf/v3.1/components/vfs;C:/SysGCC/esp32/esp-idf/v3.1/components/ethernet;C:/SysGCC/esp32/esp-idf/v3.1/components/tcpip_adapter;C:/SysGCC/esp32/esp-idf/v3.1/components/micro-ecc;C:/SysGCC/esp32/esp-idf/v3.1/components/aws_iot;C:/SysGCC/esp32/esp-idf/v3.1/components/jsmn;C:/SysGCC/esp32/esp-idf/v3.1/components/bootloader;C:/SysGCC/esp32/esp-idf/v3.1/components/bt;C:/SysGCC/esp32/esp-idf/v3.1/components/nvs_flash;C:/SysGCC/esp32/esp-idf/v3.1/components/coap;C:/SysGCC/esp32/esp-idf/v3.1/components/console;C:/SysGCC/esp32/esp-idf/v3.1/components/cxx;C:/SysGCC/esp32/esp-idf/v3.1/components/driver;C:/SysGCC/esp32/esp-idf/v3.1/components/esp-tls;C:/SysGCC/esp32/esp-idf/v3.1/components/nghttp;C:/SysGCC/esp32/esp-idf/v3.1/components/esp32;C:/SysGCC/esp32/esp-idf/v3.1/components/log;C:/SysGCC/esp32/esp-idf/v3.1/components/pthread;C:/SysGCC/esp32/esp-idf/v3.1/components/smartconfig_ack;C:/SysGCC/esp32/esp-idf/v3.1/components/wpa_supplicant;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_adc_cal;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_http_client;C:/SysGCC/esp32/esp-idf/v3.1/components/esp_https_ota;C:/SysGCC/esp32/esp-idf/v3.1/components/esptool_py;C:/SysGCC/esp32/esp-idf/v3.1/components/expat;C:/SysGCC/esp32/esp-idf/v3.1/components/fatfs;C:/SysGCC/esp32/esp-idf/v3.1/components/wear_levelling;C:/SysGCC/esp32/esp-idf/v3.1/components/sdmmc;C:/SysGCC/esp32/esp-idf/v3.1/components/freertos;C:/SysGCC/esp32/esp-idf/v3.1/components/heap;C:/SysGCC/esp32/esp-idf/v3.1/components/idf_test;C:/SysGCC/esp32/esp-idf/v3.1/components/json;C:/SysGCC/esp32/esp-idf/v3.1/components/libsodium;C:/SysGCC/esp32/esp-idf/v3.1/components/mdns;C:/SysGCC/esp32/esp-idf/v3.1/components/newlib;C:/SysGCC/esp32/esp-idf/v3.1/components/openssl;C:/SysGCC/esp32/esp-idf/v3.1/components/partition_table;C:/SysGCC/esp32/esp-idf/v3.1/components/soc;C:/SysGCC/esp32/esp-idf/v3.1/components/spiffs;C:/SysGCC/esp32/esp-idf/v3.1/components/ulp
The ASM compiler identification is GNU
Found assembler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
The C compiler identification is GNU 5.2.0
The CXX compiler identification is GNU 5.2.0
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
Check for working C compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe
Check for working CXX compiler: C:/SysGCC/esp32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Building empty aws_iot component due to configuration
Adding linker script C:/Projects/esp/EmbeddedProject4/EmbeddedProject4/VisualGDB/Debug/esp32/esp32_out.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.common.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.peripherals.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.libgcc.ld
Adding linker script C:/SysGCC/esp32/esp-idf/v3.1/components/esp32/ld/esp32.rom.spiram_incompatible_fns.ld
Component libraries: ;main;app_trace;xtensa-debug-module;app_update;spi_flash;bootloader_support;mbedtls;lwip;vfs;ethernet;tcpip_adapter;micro-ecc;aws_iot;jsmn;bt;nvs_flash;coap;console;cxx;driver;esp-tls;nghttp;esp32;log;pthread;smartconfig_ack;wpa_supplicant;esp_adc_cal;esp_http_client;esp_https_ota;expat;fatfs;wear_levelling;sdmmc;freertos;heap;idf_test;json;libsodium;mdns;newlib;openssl;soc;spiffs;ulp
Building hello_world version .
###############################
Building hello_world version 0.9.99.999.
Configuring done

 

 

 

[doingnz]

How do you expect to handle per project settings for VisualGDB and CMake going forward?

VS2017 uses a file called CMakeSettings.json

VSCode uses a file called cmake-variants.json

regular CMake does not appear to have a concept of project settings, but a cache can be initialized with -C <settings> command line parameter

I have suggested a per project file called settings.cmake and then a project uses include(settings.cmake) at the top of the CMakeLists.txt. The format of the settings.cmake is just regular CMake statements. This approach should work for any build environment and be platform independent. The VisualGDB CMake import could look for the files used by VS2017 and VSCode and import them to settings.cmake.

I am asking so that I can start moving towards the approach VisualGDB will ulitmately use for CMamke based ESP32 projects going forward. Ideally would work for all Embedded CMake build targets as projects like nanoFramework can target multiple embedded CPUs and a uniform approach to configuring a build would be nice. I can imagine settings-esp32.cmake, settings-stm32.cmake etc…. Anyway I am interested in your thoughts as I am a newbie to cmake and visualgdb.

[doingnz]

I have now tried to build the nanoFramework project. As there is no CMake project import in the current build of VisualGDB, I first created a dummy hello_world project. I then copied the folders with the nanoFramework source files and the root CMakeLists.txt into the newly minted hello-world project folder.

The nanoFramework CMakeLists.txt expects several variables to be defined. In Visual Studio Code this is achieved auto-magically with a cmake-variants.json file the cmake extension imports. To provide the same settings within VisualGDB cmake build environment, I created a file called settings.cmake with a list of cmake set(…) commands and added include(cmake.settings) at the top of the original CMakeLists.txt

e.g. start of file looked like

set(TARGET_SERIES "ESP32")
set(USE_FPU "TRUE")
set(RTOS "FREERTOS")
set(SWO_OUTPUT "OFF")
set(NF_BUILD_RTM "OFF")
...

I could build most of nanoFramework without error. However, please can you have a look at the support for the VERSION definitions within a cmake project definition. Please see CMake document here

e.g. add the following lines to any sample project. e.g. the regular hello-world sample.

set(BUILD_VERSION "0.9.99.999")
project(hello-world VERSION ${BUILD_VERSION})
message(STATUS "Building hello_world version ${PROJECT_VERSION}.")
configure_file("target_os.h.in" "target_os.h" @ONLY)

define a target_os.h.in file with lines as follows

#define VERSION_MAJOR @PROJECT_VERSION_MAJOR@U
#define VERSION_MINOR @PROJECT_VERSION_MINOR@U
#define VERSION_BUILD @PROJECT_VERSION_PATCH@U
#define VERSION_REVISION @PROJECT_VERSION_TWEAK@U

or in place of PROJECT, it should be ok to use the project name. e.g.

#define VERSION_MAJOR @hello_world_VERSION_MAJOR@U

the generated file ends up with

#define VERSION_MAJOR U
#define VERSION_MINOR U
#define VERSION_BUILD U
#define VERSION_REVISION U

when we expect it to have

#define VERSION_MAJOR 0
#define VERSION_MINOR 9
#define VERSION_BUILD 99
#define VERSION_REVISION 999

the CMakeLists.txt output is also missing the PROJECT_VERSION info from the line

message(STATUS "Building hello_world version ${PROJECT_VERSION}.")

Ideas?

Thanks for making a great product! very nearly there for cmake support for ESP32.

I can for now fake the version by changing the definition in the .in file and replace the default U with something that lets it compile. Next thing I need to overcome is linking the as built IDF. The nanoFramework by default expects to use a pre-built library.

 

[doingnz]

I am getting an unexpected error after it first load the new project. I used the wizard to generate a CMake “hello World’ sample.

C:\Projects\esp\EmbeddedProject2\EmbeddedProject2\EmbeddedProject2.vgdbproj: active configuration changed to Debug
System.ComponentModel.Win32Exception (0x80004005): Access is denied
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start()
at o91.d_2()
at d21.u()
at yd1.m2(Boolean b, Boolean a)
-- Building empty aws_iot component due to configuration

 

The sample did successfully Build->Build Solution…

Initially I could not find the hello_world_main.c in solution explorer (see screen shot), but could manually using File menu to navigate to the file on disk. I could then set a break point and single step the compiled sample on a WROVER via JTAG. Nice!

Please see the attached screen shot .. the folders displayed in Solution Explorer are a little confused with several levels of ‘..’ folders. On expanding the heiracy, I could also find the missing hello_world_main.c file.

Attachments:

You must be logged in to view attached files.

[doingnz]

thank you for the prompt support. 🙂

I can install the updated VisualGDB easily.

I struggled to install the gnutoolchain r13. Install stopped with Access Denied error. I was able to complete the install by renaming the existing SysGCC to SysGCCr12 before running the installer.

I will now try a CMake build….

[Author]

Posts