mBed: Using current Target for Ethernet-Project with mbed-os5

[Chris]

Hi,

currently I try to compile a project based on a NUCLEO_STM32F746ZG Board, utilizing the board-PHY.

Whenever EthernetInterface.h/EthernetInterface.cpp are to be compiled, the “[..] VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.mbed\features\unsupported\net\eth\EthernetInterface [..]” path is beeing called. This leads me to the conclusion, the project is handled as an “mbed-os 2″project, but not as I suspected as an “mbed-os 5” project.

I started the project by creating a simple “blinky” mbed-Project via the VisualGDB-Wizard, then added the supposedly needed frameworks (netsocket Library, rtos Library, LWIP library, Ethernet support).

 

Is there some option / setting / flag I missed to set or configure properly?

I’m open to any suggestion and appreciate any help, thank you very much in advance.

 

 

BTW.: On another topic, might we (the users) expect a mbed-BSP release based on a recent mbed-os release (mbed-os-5.4.3 or newer) anytime in the new future? I already tried to use the current BSP-Tools for mbed, but wasn’t too successfull.

[support]

Hi,

The VisualGDB embedded frameworks are actually based on the mbed features and libraries reported by the mbed build system, so it could be a bit confusing in case of Ethernet libraries.

Please try referencing the “LWIP Support” framework instead of “Ethernet support” to get the mbed v5 sources (you can search for file names in the BSP.XML file to get the framework names required to include certain sources).

Regarding the new release, we usually update the popular BSPs quarterly. Hence the next mbed update will be released around the end of Summer.

[Chris]

Thank you for your reply. The mentioned problem of entering the “unsupported” path of the mbed-os when using ethernet support seems to be solved with this. Thereafter another new problem arose, which I’m now trying to figure out, why it occures.

 

The moment the compiler reaches “platform.h”, this header includes cstddef, cstdlib, cstdio and cstring as part of the used Toolchain, which then are reported as not existant file / folder.

I treid bot Toolchains, the official GNU_ARM-none-eabi-gcc Toolchain and the Sysprogs arm-eabi Toolchain. Both yield the same result. Do I somehoe need to explicitly define my project as an cpp Project?

• This reply was modified 7 years, 6 months ago by Chris.

[support]

Hi,

Just to clarify: does this happen when building, or is it an IntelliSense-only issue? In the latter case, please try opening VisualGDB Project Properties and regenerating MSBuild-related files on the MSBuild Settings page (if you are using MSBuild).

[Chris]

It was a problem that occured during the build phase.

I solved it by explicitly forcing the used language-standard for c and c++ files.

[Author]

Posts