When I said we would be creating this project partially to fix bugs, I wasn’t kidding. Honestly, these kind of fixes might be my highest priority right now, because they present a huge impediment to new users using Mbed. I’ve been doing some testing with my test shield and an STM32 device, and have identified a trio of quite serious issues with the I2C HAL. These issues make single-byte I2C operations basically unusable on STM32 devices, and have done so since at least 2018.
I’m going to spend the next couple weeks (ish) doing a significant rework of the I2C API on STM32 devices, to try and write new single-byte API code that does not suffer these issues. I’ll also be creating some much better test cases that cover the corner cases (e.g. repeated starts) that the original tests missed, allowing these bugs to sneak in.
First thing’s first: the documentation for the I2C class has always struck me as some of Mbed’s worst, with very little explanation of how its methods are supposed to be used together or what certain parameters mean. Not to mention the issues with different functions having different return codes!
So, I did a complete rewrite of the I2C class documentation, adding a lot more info and new examples. Check it out here: Mbed OS Reference: I2C Class Reference . I also created a new write_byte() function with a standardized return code, and added a new transfer_and_wait() function to make multithreaded usage easier.
I have started now with the mbed-ce-example-hello-world in VSC. I have created the cmake-variants.yaml as described, but the entries are not visible in the Cmake variants pick list, only the previous default entries. What can be wrong?
edit:
damned, simple mistake, did not change into hello-world directory.
Next, Cmake configure complains about some missing python modules like intelhex and prettytable. I have it installed in py 3.8, but Cmake found 3.10. Still struggeling with python versions…
Yeah, CMake has annoying behavior where it finds the newest version of python rather than the one that is first on your PATH. Try installing the packages to python3.10, e.g. /path/to/python3.10 -m pip install -r ... instead of python -m pip install -r ...
thanks, I could fix it by removing some old path entry.
Next is:
[cmake] The upload method STM32CUBE is not enabled in the config code for this
[cmake] target -- set STM32CUBE_UPLOAD_ENABLED to TRUE to enable it.
Target is NUCLEO_F746ZG, I have tried several upload methods, all end with this error. Where do I have to set it to true to enable an upload method?
edit:
ok, I was to impatient to read the documentation
found targets/upload_method_cfg and modified a similar config, compiling works
And I really like it already, I should have tried it before. Great work! Also with the different upload methods, I have configured them many times manually, now it works very simple. I will dig deeper into it and check also how to convert older projects with mbed-os.
that is the problem, I have a fork of mbed-os, but mbed-ce is also a fork from mbed-os. So github does complain about creating the fork from Jamie.
Ok, I think I got it, I have to add Jamie’s Repo as remote and pull his changes.
edit:
the problem was the shallow copy. I ran into this trouble some time before, the mbed-cli does it also by default. In this case, it must be because of cloning the mbed-os-hello-world. I have executed ‘git fetch --unshallow origin’ and got the full copy of the repo. Now PRs and pushing will work.
I’ve been feeling like we’ve been a little STM32-centric lately, so I went ahead and added a different type of target to Mbed CE: the NXP MIMXRT105x. This MCU features very high performance and a very large memory pool, so it serves a somewhat different clientele than many of the STM32s. It also uses a completely different flash tool, NXP Redlink.
Feel free to review if able! This is a bug that has been bugging me since I first started using Mbed in 2019, so it feels good to finally get this nasty behavior cleaned up.
I have tried now the ‘multiple distros’ variant, it works very well.
Just one question about the mbed_finalize_build(), it is not included in the example in tools/cmake/tests. I guess it is enough to place it once in the top level CMakeLists.txt?
Happy to announce that @JojoS and I have improved Mbed CE’s support for custom targets over the last few weeks! We now support four different types of customization:
Custom targets with no source files, just a different name and different defines
Custom targets with additional source files
Custom targets that override build-in Mbed OS source files
Applying a custom linker script to any executable, custom or not
For an example of how to use the first three types, see the new custom targets example repo. To apply a custom linker script, simply pass it as the second argument to mbed_set_post_build().
While I’ve been traveling the last couple weeks, I did find time to finish off another small improvement for Mbed CE. Mbed has always had Doxygen docs, but there was never any checking that the documentation mixed in with the code actually had correct syntax. Over time, this led to a lot of little errors slipping through the cracks, such as broken links to constants, undocumented parameters, docs attached to the wrong entities, and functions missing from the docs due to missing #defines.
Well, this is not the case any more! I have enabled Doxygen’s strict mode, so that the CI pipeline will fail if there are any documentation errors. I then went through the code and fixed hundreds upon hundreds of errors, so it no longer has cause to complain about anything.
Combined with Jay’s recent changes to bring the docs into a proper tree structure, this means that the Mbed CE online docs are now easier to browse than ever!
As a quick update, I now have a branch with heavily re-written VS code support, removing the need to start separate GDB server processes or to flash code before debugging. I’d appreciate if people could try it out!
Proud to announce another big feature for Mbed CE: Raspberry Pi Pico support! @JohnnyK and I have worked over the past couple months on integrating the original Arduino patch into Mbed, making it run correctly, and bugfixing it until it passes all the Mbed tests (it had… significant issues).
As of today, you should be able to build any Mbed CE project for RP2040, so long as it’s using the latest master branch of Mbed. As for how to use the board with Mbed, check out the docs page here.
Wanted to post an update, I’m making a significant change to how Mbed CE operates with respect to Python packages.
Up until now, in order to build Mbed, you had to install the mbed_tools pip package before you were able to run CMake. However, this causes problems on Ubuntu 22 and other newer Linux distros, because these distros block the install of packages through pip, and mbed_tools isn’t available through apt-get.
I’ve just merged a change which pulls all of the Python packages directly into the Mbed OS source code. This means that you don’t need to install any Mbed python packages for the build to work; you just need to install the correct dependencies for the internal scripts to run. And these dependencies, thankfully, are all available in apt-get.
So, now, on Linux, you can just run xargs sudo apt-get install -y < mbed-os/tools/requirements.apt.txt and that will automatically install all of the correct Python stuff to run Mbed, no messing around with pip or with venvs needed!
This change also paves the way for Mbed CE to make our own changes to these packages in the future, including using json5 parsing to allow for comments in mbed_app.json!
