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

Mbed OS
63

Hi,
I have a question/problem.
The cmake line

add_subdirectory(mbed-os) # Load Mbed OS build targets.  Must be added before any other subdirectories

Definitely this will not add all sub-directories.

Now, if I need to use some drivers, the compilation will fail.
take this example and try to run the hello world.

#include "mbed.h"
#include "EthernetInterface.h"
#include "TCPSocket.h"

int main()
{
	while(true) 
	{
		printf("Hello world from Mbed CE!\n");
		ThisThread::sleep_for(1s);
	}

	// main() is expected to loop forever.
	// If main() actually returns the processor will halt
	return 0;
}

I don’t know how this cmake thing works. since there is no make file … I dont know where to check if the directories adds or not and how to write the include.
thanks for your help.

64

Ahh, you need to add

target_link_libraries(YourApplication mbed-netsocket)

to your application. This is something we are working on documenting.

1 Like
65

Hi Jamie,
Thank you very much.
I would like to make them as variables.
So this is my version.


#define libraries you are using here . 
set(LIB1 mbed-netsocket)
set(LIB2 mbed-os)

# Combine the libraries into one variable
set(LIBRARIES_TO_LINK ${LIB1} ${LIB2})

#Keep files inside /src directory
file(GLOB_RECURSE SOURCES
     src/*.cpp
     src/*.h
)

#Project name is based on the previous definition
project(MyProject) 

add_executable(${PROJECT_NAME} ${SOURCES})
target_link_libraries(${PROJECT_NAME} ${LIBRARIES_TO_LINK}) # Can also link to mbed-baremetal here

Thanks again,
BR

1 Like
66

Hello,

i would like to introduce another new part of our project MbedCE. We made a new organization Mbed-CE Libraries & Examples which could replace Components | Mbed which is not maintained like everything else.

I prepared 5 repos where each hold one library. Each is already converted (by me or someone else, info should be in header file.) and prepared for MbedCE at this moment. However it is possible to use these libraries also with current MbedOS 6+ without any changes, just import them into KeilStudio directly from repo.

We will try to add more libraries but this will take a time. We will be also happy if someone will join to help or share own library and so on.

BR, Jan

4 Likes
67

I have a repo with current Mbed-CE and some test apps using a Webserver, MQTT, SDIO, Modbus and Fingerprint Sensor.
The webserver is roughly working, but needs further imporvements. Its using worker threads for the client connections, but maybe the event based approach from ESPAsyncWebserver is better. MQTT is working fine, TFTP server also.
For health reasons, I’m currently not able to work on this stuff, but the current state can be found here:

Hope it helps someone.

2 Likes
68

Got a new documentation project to share with you guys!

In the times I’ve designed projects using Mbed OS, a major pain point has been selecting an MCU which supports the features I need. Example: if I need an MCU that supports asynchronous SPI, Ethernet, and a true random number generator, what are my options? Finding candidates isn’t easy.

Now sure, I guess I could do some sort of parametric search online, but that can be difficult to do in a vendor-neutral way, and it also won’t warn me about features which exist in a chip’s silicon but aren’t supported by Mbed. That info exists in targets.json5, but it isn’t easy to understand unless (a) you are well briefed on Mbed internal terminology, like the difference between DEVICE_SPI and DEVICE_SPI_ASYNCH, and (b) you have the patience to go up through the inheritance hierarchy and check each level for its declarations. Clearly, this json file is designed to be parsed by a machine, not a person!

Well, I decided to create a machine to parse it and generate something a bit easier for humans like us to read. Basically, it’s a set of scripts which read the json5 file and generate some cross-reference tables which show each target and the drivers it supports. To make the information even more understandable, I also documented each driver with a description and organized the targets into families, so e.g. all the STM32H7 targets are shown together. Additionally, I set it up to connect to the CMSIS device pack database, so for any target which defines a device_name property, it can automatically pull the MCU vendor name, RAM size, and flash size.

You can see the first version of this site online now: here’s the list of targets and the list of drivers. These are still pretty rudimentary (I have only the most basic experience with web programming), but I hope that they will be useful to anyone in the same position trying to choose the right MCU for a purpose or understand what specific things in Mbed do!

The next step forward will be to integrate this site with the testing system, so that it’s possible to see results of test runs in the web UI and to see a matrix of which tests test which features and which tests test which targets.

4 Likes
69

Hello,

Thanks, you’ve created a really handy machine for comparing MCU families.
Are all these targets Mbed CE compatible?
I guess we’ll be able to see this information with the integration of the test system.

For the driver list I noticed that it was always given in the same order on the Mbed CE MCU Target Families page for each target family.
However, when you go to the family page, the order of the drivers sometimes changes.
This is the case, for example, with the K64F or RP2024 target family, which doesn’t have Analog Inputs at the top of the list as it does on the index.

Thanks again Jamie, you’re really doing a great job with Mbed CE.

1 Like
70

Yes, all of these targets are Mbed CE compatible, although I can’t guarantee that every single one actually works as there are quite a lot of targets I haven’t gotten the chance yet to test with. Huh I will look into the ordering issue!

1 Like
71

Hello again! As an update, I’ve now integrated support for the Arduino Nicla Sense ME into Mbed CE. This board was actually quite easy to support as it’s very similar to the NRF52832 board already supported, and it includes an Mbed interface chip on-board (no more messing around with bootloaders this time!). Martino from Arduino was kind enough to send me a dev unit to test with as well.

For more info on this target, check the info page here: MCU Info Page: Arduino Nicla Sense ME · mbed-ce/mbed-os Wiki · GitHub

I have also compiled some Arduino core files that you can use to compile for this target, and the other Arduino ones, in Arduino IDE: Release Release v1.1.0 · mbed-ce/ArduinoCore-mbed-ce · GitHub
Feel free to check it out if you’d like to try building for Mbed directly from the Arduino toolset!

4 Likes
74

Just wanted to let you guys know, I created a new roadmap to track the significant changes we are working on in Mbed CE! Please check it out if you’re interested in the progress we’ve made so far and in the things that could use more help!

5 Likes
75

Also, regarding the EoL announcement, I am a bit disheartened, but not too surprised. It seemed like all the life had gone out of Mbed OS development back in early 2022, and the official version has just been on life support since then. I had always suspected that they were going to take it off of life support at some point… Also, I did have a bit of warning that something like this might occur from ARM, though I was sworn to secrecy on that front until an actual announcement was made. There was a bit of an effort to try and save the project internally, but it seems like it didn’t win out.
So yeah, not surprised, but disappointed.

5 Likes
76

Finally finished a new proposal I’ve been working on, for one of the first big new features that we are adding to Mbed. It’s something that’s been sorely needed for some time: a way for the build system to provide information about the memory banks on a device. This used to exist in Mbed CLI 1 but was never ported over to CMake and Mbed CLI 2. I say it’s high time we get this information back, and in a more configurable and detailed way!

Please check out the proposal if you have a chance and submit any feedback here or on the discussion page! I’m interested to hear what people have to say about this; let me know if there are any features you want or use cases I missed!

1 Like
77

Good to see Mbed will live on. It’s a shame ARM axed it. Lots of great ideas and developers.

Unfortunately, I moved on to Zephyr-OS several years ago.

Good luck with Mbed CE!

1 Like
78

that’s good coverstation i like it

79

Hi all! I’d like to share some news on Mbed CE changes over the last couple months! There’s still a boatload to do, but little by little, things are happening.

STM32H5 Support

Thanks to @JohnnyK 's hard work, we now have partial support for the STM32H5 processor architecture! There’s still a ton to do, but core functionality, such as the ADC, PWM outputs, I2C, and SPI (including DMA SPI) is tested and working. Over time we hope to improve support further, such as adding Ethernet and USB compatibility. I’m super stoked because this is the first completely new MCU family that Mbed CE has added support for !

STM32H7 Improvements

I’ve been turning my attention recently to the STM32H7 family of devices, as these are some of the most popular and capable microcontrollers used with Mbed OS (and are especially commonly used in Arduino products). Despite this, they were badly in need of some love and refactoring, as there were a number of issues with their linker scripts, clock configurations, and other code.

Now, each sub-family of STM32H7 devices uses one single clock configuration file and linker script. No more copypasta, and development and bugfixes for these devices will be way easier. After extensive research, I created a doc page that outlines exactly which of these chips we support and how they are related to each other in terms of memory and features.

Compilation and Build Fixes for Many Targets

Over the past two years of work on Mbed CE, with extensive rewriting of the build system, and without access to a large percentage of the target devices, how many Mbed targets do you think had their builds broken by accident? Well, I’ll give you a hint, it was more than 0. But it should be close to 0 now, because we have implemented a large matrix of CI builds that compile Mbed for at least one MCU in every single target family. Many of these builds were indeed broken, and they are fixed now! So, using Mbed with Cypress, Maxim, Renesas, and Nuvoton boards should be much more likely to just work now.

Speaking of Nuvoton, I’m incredibly excited to welcome @ccli8 as a contributor to Mbed CE! @ccli8 is an engineer at Nuvoton and has been helping test out Mbed CE on a number of different Nuvoton boards. They’ve added a full set of upload method configuration files for all Nuvoton targets and have fixed a number of issues with building and uploading that prevented TFM-enabled boards from working with Mbed CE.

Memory Bank Information

Last but not least, my main focus for the past couple of months has been bringing memory bank information to Mbed CE. To recap my previous post, this has never properly been supported in Mbed CLI 2 and a new implementation of this feature has been sorely needed. Mbed now tracks which flash and RAM banks exist on each MCU and passes this to the source code and the build process. Not only does this let certain parts of the Mbed code and linker scripts be written a lot more cleanly, but it also lets us do something really cool with the build report. The memory map script can now display each memory bank and its fill percentage!

RAM Bank SRAM_D2: 278528(+0)/294912 bytes used, 94.4% (+0.0%) used
RAM Bank SRAM_D1: 16064(+0)/524288 bytes used, 3.1% (+0.0%) used
RAM Bank SRAM_D3: 0(+0)/65536 bytes used, 0.0% (+0.0%) used
RAM Bank SRAM_DTC: 256(+0)/131072 bytes used, 0.2% (+0.0%) used
RAM Bank SRAM_ITC: 0(+0)/65536 bytes used, 0.0% (+0.0%) used
RAM Bank SRAM_BKUP: 0(+0)/4096 bytes used, 0.0% (+0.0%) used
ROM Bank IROM1: 139280(+0)/2097152 bytes used, 6.6% (+0.0%) used

When I used Mbed in the past, I often struggled to understand exactly how much memory existed on my device and how it was allocated into banks. I hope that this report will clear things up a lot going forward!

Changes to be aware of

The memory bank information PR is a pretty huge change to certain Mbed internals, and unfortunately is a breaking change for custom target users. For right now, custom targets will need to do one of the following when used with the latest version of Mbed CE:

  • Declare a "device_name" property in their target JSON that matches an MCU name known to Mbed (see the MCU description file’s top level keys for the list of valid names)
  • Extend a target built in to Mbed that declares a "device_name"property
  • Declare their own "memory_banks" property that declares memory banks to Mbed. This method should be used if the MCU used in the custom target is not one known to Mbed OS. See section 4 of the proposal linked above for formatting examples for this section.

The other thing to be aware of is that, when updating to new versions of Mbed CE that support memory bank information, everyone will need to delete and recreate their CMake build directories. This will make sure that the memory bank information gets generated. The latest version of Mbed CE now generates an error if it suspects you’ve forgotten to do this.

Well, that’s all I got for now, but we are still working away on new changes! My most immediate priority is a rewrite of the STM32H7 ethernet driver, because I’ve discovered… well, a lot of sketchiness, and it prevents Ethernet from working on these devices in certain cases. I am also continuing to work on finishing up the CI test shield and putting together a larger device testing operation.

1 Like
80

Hello,

I’m not an experienced video maker but I’ve made few videos about how to get started with MbedCE - youtube

During this process I did also a revision of our instructions and did a necessary correction.
BR, Jan

1 Like
81

Wanted to post an update because we have just merged 2 PRs with semi-breaking changes to mbed-ce master branch.

The first PR (#410) makes the choice of mbed-os vs mbed-baremetal global to the project instead of per-target. While this was one of the new features provided by the Mbed CLI 2 build system, it had proven to be very difficult to maintain, and caused a lot of subtle issues (#304, #407) as it basically required libraries outside of the core mbed-os to choose whether they would build against baremetal or RTOS, and if they chose baremetal, they had to build in a binary compatible way whether or not the RTOS was enabled.

I do not believe there were too many big use cases for this feature, as generally a project will either want to use mbed-os everywhere or mbed-baremetal everywhere depending on the size of the MCU. And if given a choice between weirdness that affects users unexpectedly, and slightly less features, I will always choose slightly less features. I think that a lot of the ways ARM went wrong when maintaining Mbed OS came down to that…

Anyway, in terms of breaking changes, if your project uses mbed-baremetal, you will need to add a new JSON option, like:

{
    "target_overrides": {
        "*": {
              "target.application-profile": "bare-metal"
        },
}

Otherwise your app will start building with Mbed RTOS. Note that we did add an error in mbed_set_post_build() if you try to link mbed-baremetal in this case, so it should be pretty obvious when you need to make this change. Thanks a ton to @ccli8 from Nuvoton for driving this fix!

The second breaking(ish) change was driven by a new warning in CMake 3.33. You may have seen it if you tried to build Mbed with the latest CMake version, where it complains about calling enable_language() before project(). To fix this, I had to split up app.cmake into two different files, where the second one has to be included after the project() call in your application. Basically, you will have to change

include(mbed-os/tools/cmake/app.cmake)

into

include(mbed-os/tools/cmake/mbed_toolchain_setup.cmake)
project(MyMbedApp
    LANGUAGES C CXX ASM) 
include(mbed_project_setup)

As you can see, since we had to make breaking changes anyway, I also took the chance to give app.cmake a less generic name :slight_smile: . For more info about the change, see the PR. I say this one is breaking-ish because old code will still work, it will just print several warnings saying that you need to update it.

Besides these changes, we’ve still been hard at work on Mbed CE in the last few months, and have made changes including:

  • Spinning up our own echo server (https://mbed-ce.dev) to replace the ARM one which shut down, rendering the network tests nonfunctional
  • Adding support for the mcuboot bootloader (thanks to @zhiyong and Sam Lefebvre for help!)
  • Merging fixes for the BLE HCI driver security issues (see here for details)
  • Merging the Renesas ESP32 AT command driver into Mbed (thanks to @chris-snow!)

Note that as this forums inches closer to shutting down, I will also be posting these updates on the Mbed CE Discussions forum.

1 Like
82

Is it possible to program mBED LPC1768 in MBED CE?

83

Yes, it is possible.

BR, Jan

84

Quick update: Just merged a huge update to the STM32 Ethernet drivers. This PR basically rewrites them completely from scratch, using a new, much more ergonomic ethernet MAC driver API. See the design document for more details on how the new driver works.

This should solve a number of issues that have been annoying people for years with the STM32H7 Ethernet driver, including:

  • Very slow transmissions (due to blocking until packets have been completely transmitted)
  • Slowing down the entire MCU by about a factor of 2 when Ethernet is first enabled (due to disabling the data cache)
  • No multicast join support
  • Ethernet dying if you tried to transmit a packet buffer located in DTCM, or another memory location that the Ethernet DMA can’t access
  • No support for Nanostack
  • No support for running the Ethernet test suite (so I couldn’t even tell what other more subtle issues it might have had)
  • No support for ethernet PHYs other than LAN8742

And while the STM32F2/F4/F7 Ethernet driver wasn’t nearly as bad, it still was not zero copy and had a few of the above issues, so I rewrote it as well. Now, both drivers are fully zero-copy and should be implemented in the most performant way possible! (P.S. STM32H5 now supports Ethernet as well).

If you use Ethernet on an STM32 MCU, I would highly recommend updating to the latest commit of mbed-os and giving it a shot. If you use STM32F7 or H7, you should see an immediate performance benefit. Please let me know if you see any regressions or other issues!

P.S. There are breaking changes if and only if you use a custom target that provides its own Ethernet pinmap init code. See the PR for details.

3 Likes