We’re planning on a few changes to the Mbed website, and having the roadmap visible and easy to find is high on our list.
3 Likes
I can see changes on the website.
I truly do not understand why it renders as of now a hamburger menu on a desktop?! Maybe you wanted the users to click just one more time for nothing?
The mobile menu kicks in below ~1250 px so the vast majority of desktop users would see the full menu. There might be some scope to reduce that page break though, so I’ll pass this to our web team.
Well… i have a 4K display and as of today i see the hamburger menu on my pc.
This was not the case before.
Is this on forums.mbed.com or on os.mbed.com? On the forums the hamburger menu is always there regardless of resolution. That’s a decision made by Discourse, the service we use for the forums. If it’s on os.mbed.com then I wouldn’t expect you to see it on a 4k display!
On os.mbed.com This might be a recently introduced CSS media query related issue then.
Seems like i found the rule:
@media only screen and (max-width: 1250px)
.mbed-nav__menu {
display: none;
}
The highest width where it still does not show the hamburger menu is 1228px. On my display this CSS works best:
@media only screen and (max-width: 1100px)
.mbed-nav__menu {
display: none;
}
Issue seems to be fixed, at least i can see the normal main menu again on my desktop.
The <table> tags that contain the documentation of the APIs often contain many table rows and tend to be hard to read. I lack some spacing after the <tr class="memdesc"> rows. I know with table rows one can not set a padding or margin… however for sure the doc team could add this html after each <tr class="memdesc">:
<tr class="spacer"><td></td><td></td></tr>
And this CSS:
tr.spacer {
height: 20px;
}
tr.spacer td {
border: none;
}
That way the table would lead our eyes much better and the doc would become more readable.
1 Like
I guess the roadmap would need an update.
Good point, Peter. We’ll do an update shortly as we want to show our plans for at least the next two quarters rather than just one and we’re just finalising that planning at the moment.
2 Likes
As promised, the updated Mbed roadmap is now visible in GitHub:
Thanks for the update!
A remark:
Support MCUBoot in Mbed OS
is planned but this is already almost completely done by @aglass0fmilk. See GitHub - AGlass0fMilk/mbed-mcuboot-demo: Demo of mcuboot with Mbed
Yes the support is there. What I’d like to come up with is a way to use the new cmake build tools to simplify building the bootloader and multiple applications from the same libraries.
Right now, the folder structure in the above mbed-mcuboot examples is:
project/
├── mbed-mcuboot-bootloader/
│ ├── mbed-os
│ ├── mcuboot
│ └── mbed_app.json
└── mbed-mcuboot-application/
├── mbed-os
├── mcuboot
└── mbed_app.json
As you can see, in this structure the bootloader and applications can have different mcuboot configurations, different mcuboot versions, different mbed-os version (not sure the last two are that critical).
It is very laborious to try and synchronize these settings and dependencies between multiple applications. It would be nice to use the build tools to simplify.
Also, I currently have a bunch of shell scripts to build the bootloader and application, sign the application, generate OTA update binaries, merge hex files together… all of these could probably just become cmake targets instead of platform-specific shell scripts.
On a similar note, I think Mbed should address this:
We need a firmware version framework/API
This is something I find myself inventing/copy-pasting for every project. Currently, it’s just an application-level configuration that is a string. I then append the build timestamp to the “x.x.x” version string to get the full version.
What I’d prefer is some macro defined by the cmake build tools that gives us a customizable firmware version string (to accommodate different organization’s versioning formats) and optionally appends the commit hash of the repository. I think the commit hash is much more representative of the state of the code at build than a timestamp (you can have an older FW version with a later timestamp). Maybe even append “-dirty” to commit hashes that have uncommitted changes, similar to Linux builds.
@andypowers @vcoubard @donatien If the Mbed team would like to move up mcuboot support in the roadmap, I am at the point where I’d like to start figuring out how to better integrate it with Mbed anyways. So I could help. Unfortunately, I am at the same time learning cmake so I might not have the best vision for how to integrate it.
1 Like
This method looks like it ought to work fine for the CMake side implementation: Compile-time version strings in CMake
I was asking myself the same question!
Waiting for a new release as well, the Github has been awfully quiet for a few weeks now.
The roadmap has not been updated since April, despite the several releases since that time…
Now this tells much about how the whole project is governed and that might be the root cause of all the other issues with Mbed in general.
Last blog post in June, what is up? Has Mbed became abandonware they just forgot to tell this to the user base? Recently there is higher activity on the forum, probably new users asking basic things and the usual bunch of people trying to answer such questions that should not even arise if there was any usable doc.
My question is: how long does the core team think all this can remain the same way?
7 Likes
I do agree with you, I’m a bit afraid seeing very little activity on both mbed-os and mbed-tools repositories.
An update on the roadmap and the situation is more than welcome.
3 Likes
We should have updated before, but there are a few activities happening which have meant the Mbed livestreams haven’t restarted after the summer break.
To begin with, unfortunately Don has decided to pursue a new opportunity and has left Arm. We obviously wish him every success in his new, yet to be revealed, venture.
We are combining the livestream into “Innovation Coffee”, another regular YouTube livestream that covers more general embedded topics as well. We’re planning some Mbed-related content currently.
As some of you may have seen at DevSummit, Arm has announced a new initiative focused on IoT, Arm Total Solutions, and one of the key parts of this is Project Centauri, which is pulling together industry and security standards to provide foundational software for Cortex-M based microcontrollers. We in the Mbed team are, along with other development teams in Arm, working on a longer term roadmap that brings this together with Mbed, CMSIS, TF-M and other technologies to simplify IoT development, which is, we think, one of the core tenets of Mbed.
So in the short term, we’ve slowed down Mbed work to give the team some space to conduct the engineering investigations needed to underpin this roadmap. We hope to be able to share more on this work in Q1 next year, so will update you when we have more.
Thanks Andy for the update.
I’m not sure if it’s all good news or if we should be terrified. I’m feeling like Arm is throwing new solutions to the public every other day a little bit like google and if you find one that you like and works great for your project, you can be sure it will be killed or left to die (Inbox I’m looking at you…).
A lot of people here have invested a lot of time to use mbed not just as a prototyping tool but as the foundation for their firmware that they are shipping in real life product.
There are still a lot of half finished tasks that will make our life easier but are still work in progress with a lot of known issues.
I’m okay if Arm wants to slow down or step down from mbed-os but as with everything else, we just want to know what to expect.
A lot of dedicated people here could be good managers of the github repo if need be.
3 Likes