[Help Wanted] Mbed CE: A community fork of Mbed OS

As an update, I have now merged a change which enables json5 files to be used instead of json everywhere that Mbed uses json files. Simply give the file a “.json5” suffix, and Mbed Tools will use a json5 parser to load the file instead of a json parser. targets/targets.json has already been converted to json5, and in your own project you can rename the json files to json5 as desired – just don’t forget to update the MBED_APP_JSON_PATH and CUSTOM_TARGETS_JSON_PATH variables in CMakeLists.txt!

The upshot of this, of course, is that now you can have as many comments as you like in your configuration files (in addition to other nice json5 features like trailing commas and hex literals). This is a big step forward in making Mbed more convenient and easy to develop for!

4 Likes

I have tried the new json5 and it works. But I had to install the python package for this manually. Isn’t there a way to update the requirements via cmake? After some time where I haven’t used Mbed, I have to learn a lot again :slight_smile:

Oh, you need to manually install the requirements.txt when setting up a new project. That’s in the instructions here. Currently CMake doesn’t do this automatically; I think that it might be a little awkward if CMake were to start installing python packages without a lot of user interaction…

Hello! I know it’s been a while, just wanted to provide some updates about the current state of Mbed CE.

Over the last few months, it feels like the pace of the project has been picking up! I’m super stoked to have some new contributors from the community who have added some new features and bug fixes. We continue to accumulate more upload method configurations, and there’s been some cool new features and fixes added for STM32U5 and RASPBERRY_PI_PICO. Plus, DMA SPI is now supported on every STMicro target other than STM32U5 (where there’s still one issue that needs to get looked into).

Another thing that’s happened lately is I’ve spoken a bit with Martino Facchin from Arduino – he’s one of the devs responsible for maintaining the Mbed OS Arduino core and its giant pile of patches that Arduino couldn’t merge into mainline Mbed. I talked to him about Mbed CE, and he said that Arduino could be interested in providing Mbed CE as a core option through Arduino IDE! However, they do not have much dev time to spare, so we’d have to do the work of formatting Mbed as an arduino core and creating the correct index files to make it available on the Arduino package index. I managed to complete the first half of that job here. And it DOES work! I’m able to use the generated core files with Arduino IDE to compile & upload Mbed CE projects in one step!

This is pretty cool because it means there’s a much easier development environment option available if people want to use Mbed CE for Arduino boards without going through the manual setup. Also, since Arduino IDE can work with OpenOCD upload methods, there’s no reason we couldn’t add virtually every Mbed board to the Arduino IDE over time.

The remaining part, though, is that in order for the Arduino people to list us in the package index, we need to create a CI job which generates a package.json file and hosts it and the package files via some sort of permanent storage. Github Pages has been suggested as a possible option. The template package.json is here and Arduino pointed me to this ESP32 script which does something similar to use as a reference. Unfortunately I am not a web developer so this is a bit out of my comfort zone… I’d really appreciate if someone could take this on.

Which brings me to the last topic, which is what am I working on? Well, I feel like with the project picking up, we are going to see more and more PRs being submitted and more demand for testing stuff on a daily basis. As you may or may not know, for some time now I’ve been working on building a new CI test system to replace the old FPGA Test Shield system that ARM used, and I am also working on a device farm to run these tests automatically. Well, I have made a fair amount of progress! The basic device farm (with STM32U5, STM32L4, STM32H7, NRF52840, LPC1768, and RASPBERRY_PI_PICO) is online, and I have developed a new test shield PCB which can test SPI, I2C, UART, PWM, AnalogIn, and more. Also, I have developed some fairly torturous test cases which run various SPI and I2C transactions and verify that the results are correct, via a logic analyzer built right into the test shield. There’s no “transfer one byte and call it a day” here – these tests are complicated and they will only get even more detailed over time.

However, there is still a lot to do to get this project running, and as I have a day job I cannot be counted on to make progress consistently and quickly – it’s a question of when I have time and energy. I realized I was feeling a bit stressed with all the stuff going on with the project, because it was hard to determine how to divide my time. But logically, there’s a clear answer – we need to get testing automated now before it becomes a huge limiting factor later on. So, I am going to have to be a bit more strict here. For the next couple months, I am going to have to focus my time on test system development rather than new features and bug fixes. I will still be approving PRs, but I will not write anything myself other than stuff for the test system. I know that this means certain bug fixes will be delayed, and I’m sorry, but I have to put my foot down and focus on this or I will never get it done.

I’m hoping that by approximately summer I will have the new system up and running and then we can take another look at where things will go from there! In the meantime, I have created a new project board to track what work still needs to get done for this project. Feel free to check it out!

4 Likes

That sounds great, it would be good if Mbed-CE is a base for ArduinoMbed-core.
But I really can’t understand the Arduino politics, the new Arduino R4 with Renesas chip does not use the Mbed core, instead another new one. This leads to many new incompatibilities in libraries, because many have to use SDK functions and now to expand the terrible #ifdef coding.

1 Like

Ah yeah, sadly Martino told me that Arduino is moving away from Mbed since its abandonment and is trying to switch to Zephyr OS. They even will attempt to port some of the existing Mbed Arduinos to Zephyr, though it sounds like this is still early days. Sadness. Though, I don’t think it would be impossible to convince them to switch back to Mbed if we do a stellar job with Mbed CE!

Oh, Bad. and it will add much more confusion to Arduino users. More incompatible libraries.

This is how Arduino handles issues. I cannot recommend to use the Arduino Machine Control, for our company I will not recommend to use it.

to be fair, Jamie pointed me to a PR from some Arduino guys. The problem is known for some time and they tried to fix it, providing a large PR with a lot of effort for many targets. This PR was simply closed and not checked further.

But it shows that Mbed-CE should survive to get problems like this solved.

Hi,
Thanks for trying to save mbed-os.

Shouldn’t this version support what mbed-os supports?

I run this on the demo (hello world)

mbed-ce-hello-world\build>cmake … -GNinja -DCMAKE_BUILD_TYPE=Develop -DMBED_TARGET=“NUCLEO-F207ZG”

but it fails with

-- Mbed: mbed_config.cmake not found, regenerating configs...
ERROR: Target attributes for NUCLEO-F207ZG not found.

BR

Ah I think you wanted -DMBED_TARGET=“NUCLEO_F207ZG”

I just add, the target name has to be in exactly same format like is in targets.json file

BR, Jan

the ‘-’ in target names is bad, it should be added to our custom target documentation never to use it. Just ran into that pitfall. It works, but the name is used as a define and then interpreted as minus in the name and throwing warnings in every translation unit.

Thanks for your reply. That solved that issue.
This is under windows.

I get another issue and sure it is related to Windows. But since we are talking about a “working enviroment” for mbed, I need to mention that.
Before (when we used to use Makefiles), widnows failed to create the bin file due to the long names of the object that the compiler needed to put in the bin file. I used to use linux (Windows virtual machine) to do the last compilation to get the bin file.
Now, i think windows has more issues regarding command prompt. I know how to fix that you don’t need to reply for that part. (adding the c:\windows\system32 to path variable in window fix the issue) I just wanted to mention it.

I would like to know if there is any possibility to generate Makefile as before since that will help me to continue using eclipse and the way I used to debug mbed project.
Eclipse as IDE for mbed, was perfect fit (IMHO). I wish to be able to use it again.
Thanks.
BR

C:\Temp\mbed-ce-hello-world\build>ninja
[1/1] Linking CXX executable HelloWorld.elf
FAILED: HelloWorld.elf
cmd.exe /C "cd . && C:\PROGRA~2\GNUTOO~1\62017-~1\bin\AR10B2~1.EXE -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions -ffunction-sections -fdata-sections -funsigned-char -fomit-frame-pointer -g3 -mthumb -mcpu=cortex-m3 -Wno-register -Wl,--start-group -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -Wl,--end-group -specs=nosys.specs -Wl,--cref    -T C:/Temp/mbed-ce-hello-world/build/mbed-nucleo-f207zg.link_script.ld -Wl,-Map=C:/Temp/mbed-ce-hello-world/build/HelloWorld.elf.map -Wl,--gc-sections -Wl,--wrap,main -Wl,--wrap,_malloc_r -Wl,--wrap,_free_r -Wl,--wrap,_realloc_r -Wl,--wrap,_memalign_r -Wl,--wrap,_calloc_r -Wl,--wrap,exit -Wl,--wrap,atexit -Wl,-n -Wl,--wrap,printf -Wl,--wrap,sprintf -Wl,--wrap,snprintf -Wl,--wrap,vprintf -Wl,--wrap,vsprintf -Wl,--wrap,vsnprintf -Wl,--wrap,fprintf -Wl,--wrap,vfprintf @CMakeFiles\HelloWorld.rsp -o HelloWorld.elf  && cmd.exe /C "cd /D C:\Temp\mbed-ce-hello-world\build && arm-none-eabi-objcopy -O binary C:/Temp/mbed-ce-hello-world/build/HelloWorld.elf C:/Temp/mbed-ce-hello-world/build/HelloWorld.bin && "C:\Program Files\CMake\bin\cmake.exe" -E echo "-- built: C:/Temp/mbed-ce-hello-world/build/HelloWorld.bin" && arm-none-eabi-objcopy -O ihex C:/Temp/mbed-ce-hello-world/build/HelloWorld.elf C:/Temp/mbed-ce-hello-world/build/HelloWorld.hex && "C:\Program Files\CMake\bin\cmake.exe" -E echo "-- built: C:/Temp/mbed-ce-hello-world/build/HelloWorld.hex" && cd /D C:\Temp\mbed-ce-hello-world\mbed-os\tools\python && C:\Users\velmaja\AppData\Local\Programs\Python\Python312\python.exe -m memap.memap -t GCC_ARM C:/Temp/mbed-ce-hello-world/build/HelloWorld.elf.map --depth 2""
'cmd.exe' is not recognized as an internal or external command,
operable program or batch file.
ninja: build stopped: subcommand failed.

Eclipse is an underrated IDE, I used to use it back before I got converted to CLion. I have not tested this, but it is actually possible to make CMake generate Eclipse CDT project files, using cmake "-GEclipse CDT4 - MinGW Makefiles". IMO, CLion is a significant upgrade from Eclipse because its code parser is less glitchy and it integrates with CMake a lot better, so I’d also recommend giving it a try if you haven’t already.
Huh, I haven’t seen the cmd.exe issue before, but glad you figured out a fix!

It seems that is not possible. read the messages from the command you mentioned.
running this code

cmake .. -G "Eclipse CDT4 MinGW Makefiles" -DCMAKE_BUILD_TYPE=Develop -DMBED_TARGET=NUCLEO_F207ZG

Generators
* Visual Studio 17 2022        = Generates Visual Studio 2022 project files.
                                 Use -A option to specify architecture.
  Visual Studio 16 2019        = Generates Visual Studio 2019 project files.
                                 Use -A option to specify architecture.
  Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 11 2012 [arch] = Deprecated.  Generates Visual Studio 2012
                                 project files.  Optional [arch] can be
                                 "Win64" or "ARM".
  Visual Studio 9 2008 [arch]  = Deprecated.  Generates Visual Studio 2008
                                 project files.  Optional [arch] can be
                                 "Win64" or "IA64".
  Borland Makefiles            = Generates Borland makefiles.
  NMake Makefiles              = Generates NMake makefiles.
  NMake Makefiles JOM          = Generates JOM makefiles.
  MSYS Makefiles               = Generates MSYS makefiles.
  MinGW Makefiles              = Generates a make file for use with
                                 mingw32-make.
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
  Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Ninja Multi-Config           = Generates build-<Config>.ninja files.
  Watcom WMake                 = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles = Generates CodeBlocks project files
                                 (deprecated).
  CodeBlocks - NMake Makefiles = Generates CodeBlocks project files
                                 (deprecated).
  CodeBlocks - NMake Makefiles JOM
                               = Generates CodeBlocks project files
                                 (deprecated).
  CodeBlocks - Ninja           = Generates CodeBlocks project files
                                 (deprecated).
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files
                                 (deprecated).
  CodeLite - MinGW Makefiles   = Generates CodeLite project files
                                 (deprecated).
  CodeLite - NMake Makefiles   = Generates CodeLite project files
                                 (deprecated).
  CodeLite - Ninja             = Generates CodeLite project files
                                 (deprecated).
  CodeLite - Unix Makefiles    = Generates CodeLite project files
                                 (deprecated).
  Eclipse CDT4 - NMake Makefiles
                               = Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Eclipse CDT4 - MinGW Makefiles
                               = Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files
                                 (deprecated).
  Kate - MinGW Makefiles       = Generates Kate project files (deprecated).
  Kate - NMake Makefiles       = Generates Kate project files (deprecated).
  Kate - Ninja                 = Generates Kate project files (deprecated).
  Kate - Ninja Multi-Config    = Generates Kate project files (deprecated).
  Kate - Unix Makefiles        = Generates Kate project files (deprecated).
  Sublime Text 2 - MinGW Makefiles
                               = Generates Sublime Text 2 project files
                                 (deprecated).
  Sublime Text 2 - NMake Makefiles
                               = Generates Sublime Text 2 project files
                                 (deprecated).
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files
                                 (deprecated).
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files
                                 (deprecated).

It looks like you are compiling under WSL, but the sources are in the windows filesystem. That is very slow, you should copy the project to the WSL filesystem.

Thanks. but that was still using windows.
Using ubuntu under windows, it fails at the moment. You are correct, I used the same place which is under c:\temp …i.e. /mnt/c/temp …etc.

-- Check for working C compiler: /usr/bin/arm-none-eabi-gcc - broken
CMake Error at /usr/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "/usr/bin/arm-none-eabi-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /mnt/c/temp/mbed-ce-hello-world/build/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/ninja cmTC_471b5 && [1/2] Building C object CMakeFiles/cmTC_471b5.dir/testCCompiler.c.obj
    [2/2] Linking C executable cmTC_471b5
    FAILED: cmTC_471b5
    : && /usr/bin/arm-none-eabi-gcc -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions -ffunction-sections -fdata-sections -funsigned-char -fomit-frame-pointer -g3 -mthumb -mcpu=cortex-m3 -Wl,--start-group -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -Wl,--end-group -specs=nosys.specs -Wl,--cref CMakeFiles/cmTC_471b5.dir/testCCompiler.c.obj -o cmTC_471b5   && :
    /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: cannot find -lstdc++: No such file or directory
    /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: cannot find -lsupc++: No such file or directory
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  mbed-os/tools/cmake/app.cmake:55 (enable_language)
  CMakeLists.txt:14 (include)

Edit:
Solution for this problem was :

https://stackoverflow.com/questions/28533413/arm-none-eabi-ld-cannot-find-lc

it is still using the sources on mounted c drive. Sources needed to be copied to e.g. ~/projects/myMbedproject.