Seriously Disappointed

Mbed OS Bugs
21

Thank you Zoltan :smiley: I will look at that.

After the last OS update (6.6.0), (using Studio) for some reason it’s come back to life using my own version of Erik’s library. There is something strange happening when using TCPsocket where there’s an increase in sensor errors.
I will raise an issue on Github.

However…
Most comments seem to hinge around the lack of documentation and library changes that leave you needing loads of updating which has been a pain this year.

Although considerably better, the v6.6 doc’s continue to have outdated examples and/or poor examples.

There is a huge amount of information and examples on the web for Arduino and Pi but virtually nothing for Mbed so users are very much reliant on the information that Mbed can provide.

It appears to me that most complaints are centered on a need to fix any existing issues and not add any more functions to Mbed until that happens.

22

The biggest problem is to work hard on the OS and break down all compatibility with older API.
Mbed OS version management is just bad.
As other user said and I mentioned in two other posts, your projects works fine today, tomorrow when you want to export, compile on the online IDE you cannot compile or do anything.
One of the problems I face now, They removed Serial printf from the OS … Why? I don’t know .
So, your code that you have been working on for years will no longer compile. You have to re-design your code from begining.
This is just an example how bad their strategy is about changing old API.
You have no choice longer. Online IDE is not working, you cannot export project either …so what?
I have an Interpreter OS that is based on the MBED, worked on for years now … Suddenly it is no longer compiled in the local version …
Now the issue is here … Trusting the platform will be questionable from now … Should I continue with MBED or try another platform … after all these years (almost 4 years).

23

Look at an example.
It is not so long back in time that they changed the delay/wait API to be like the following
ThisThread::sleep_for
But, now even this API is changed.
So there is no clear vision how things must be made … This function is deprecated and you cannot trust using it as they will take it out.
this was just an example how things changes in MBED. Clear vision required.
You shouldn’t decide to change an API today … and after one week/month change it again to another thing.
Reliability will be questionable.

2 Likes
24

@mjm2016 You should check out my SerialStream library, it helps with porting old(-ish) code that uses Serial.printf().

25

I think so.
as a beginner of MBED as well as a older of MCU,
there isn’t a step -by- step tutorial course by now.
It is very terrible that the OK code of old version (maybe)can’t run on a new version of MBED.
Is is confused every time when I read like this,

"Warning: ‘wait’ is deprecated:…
Warning: ‘CallChain’ is deprecated: CallChain has been deprecated and will be removed.
…

26

You can usually ignore depreciation warnings so long as your code still compiles.

If you want your app to compile the same way for all time, you need to pin to a particular version of mbed-os. It’s the same as in other software projects.

27

Thank you for pointing out the obvious :slight_smile:

I’m must say I really don’t understand complains such as “it was working a year ago and now when I open it, it doesn’t compile with the new version, everything has changed!” – Are you not using version control?!

There is not a single tool/library/project that will stay exactly the same for a year time while going though major version upgraded. Software evolves, it gets better, bugs are fixed, and sometimes it means breaking backward compatibility or changing the API.

But Mbed really follows semver and it’s absolutely normal to have firmware working on 5.x.x that will not work or compile on 6.x.x.

5.x.x to 6.x.x is major version upgrade and stuff breaking are to be expected.

Mbed also uses modern tools and everything is on Github, so as stated by @cjhdev, you can pin the versions that work for you, your workflow, your OS, your project. All the changes are in the history so you can always go back in time to the version that used to work, even for mbed-tools and the pip packages if needed!

Taking a step back I’m a bit fed up with this flow of negativity regarding Mbed… “it doesn’t work for my platform!”, “it used to work”, “why did you change the name of the function?”, “why are you pushing chrono and other amazing C++ library that help you write better code instead of letting me write the cr**y code I’m used to write?”.

As I said before, if you haven’t opened your project for a year and you try to upgrade to the latest version, don’t be surprised it doesn’t work. Try doing the same with a new version of iOS: same problems. But it’s okay, it’s called maintaining your software.

That being said, projects that have been dormant for a year and only opened through an online IDE sound more like hobby projects, or experimentations, than production firmware thousands of products are depending upon. And that’s okay, but in this case why waste everyone’s time complaining. Ask questions, ask for help (the community is getting bigger and bigger and there are amazing people ready to help out!), but please, be positive :slight_smile:

If your project is professional and you expect a high quality of service, you can pay for it. Mbed is free and open source. They don’t owe you anything. It’s even in the Apache 2.0 License:

Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.

To steal the words of Mike McQuaid, main maintainer of Homebrew, from his amazing article “Open Source Maintainers Owe You Nothing”

Let’s turn this legalese into plainer English (note that I Am Not A Lawyer):

  • The way the software is today is all that the maintainers ever agree to provide you (bugs and all)
  • The maintainers provide no assurances that the software will ever work for any user or use case (even documented ones)
  • The maintainers are never liable for any problems caused by any use of the software (including damages that require you to pay for repairs)
  • You must agree with the above to have any right to use the software

Don’t like the project? Stop using it. Don’t like the upgrade? Keep using the previous tag. Don’t like the way things evolve? Make a fork and start developing your own ideas. Think that your idea is worth sharing and adding to Mbed? Make a PR and contribute!

The best thing is that, even with this licence, it doesn’t stop the Mbed dev team to do everything they can to fix bugs, make the tools better and develop new features. If you’re curious, go read some of the discussions on issues and PRs on Github. You’ll understand what they are really doing, the complexity behind your wait is being deprecated issue and why they chose a different path that mean that you’ll need to change a few lines of code to get up and running again.

I’ve learned so much reading those discussions, not just about Mbed but about C/C++, coding practices, algorithms, etc., as well.

Of course, not everything is perfect, but if you really think some things should change, stop complaining and give us a hand! :slight_smile:

6 Likes
28

Some of your points are valid but not all.
As bug fix is a part of version releases … you can not argue us that we should stick with the older version.
There are serious bugs that gets fixed by revision releases. How can we still use the older version while they contains the bugs.
If you read my posts, you find that I am talking about the export, the online compiler and sure the OS.

Projects might be valid for much longer time than one or two years. You finish them and they are working. But, you always needs to go back to the old code and fix or add something.
Some projects takes years to implement, and might be a project that focus on future and features not speed of implementations.

While working on similar projects you will face these things that I have mentioned. I have such a project that I am working on … It is a script - OS, and a platform in Windows (special IDE) to program the script and send it to the MCU .
So, that is why changes in the API of MBED affect me really bad.
Changes in the API went so quickly that during the last 2 years version 2 eliminated, five started, and ended now version 6 is there.

Go and try to export an old mbed (2), use a nucleo board ( say Nucle-L476RG) and export for ARM/GNU Makefile. you will not be able to do so.

As I said, if bug fix is seperate from API changes, you can argue like that… but this is not the case.
Any OpenSource porject aims to be useful for people. There is no reason to have a project that beat the users.

So, it is not about been negative … it is about raising these questions to the developer team.
There must be priority of fixes . . At least the online compiler must be able to compile and export the projects. Version releases must be done in another way. Change in the API should be separated from BUG fix.
Sorry if my posts hits anyone … that is not the aim of my posts.
Notice that all these I am telling (Suggestions) are my opinion. I might be wrong.
As all Opensource project, they own us nothing … we own them THANKS.

29

It is very useful to have a thread about the problems. It is very difficult to get anything working when examples do not work.

2 Likes
30

I agree. But it very much depends where you look.

First the bad… this can be found in the Hardware pages. Many of these pages have out of date examples. The LPC1768 page is a classic.

Here the LPC1768 showcase “Hello World” example is still MBED OS 2. Not only that, but it does not even tell you that. Then on the right hand side bar it tells us that this board has Mbed OS support for version 6.6. So confusing, IMHO.

Then the good. This can be found in the Documentation section. Here you can change the Documentation version to suit the OS version. The examples then change to match. This is very helpful.

1 Like
31

I think it may pay to do a comparison like I have done recently.

I got to the point of ‘Mbed depreciation desperation’ where I looked at the alternative’s.

I have to say firstly and most importantly that Mbed is professional and an industry leading standard.
However from a business point of view it can be discouraging as to the wasted time involved with bug fixes.

So to that end I looked at the ‘child’s’ option, Arduino.

Absolutely hate it, the IDE is, putting it politely, rubbish.

But I was able to get a full HTTPS server/client function over GSM and wi-fi together in a couple of days. There’s Json processing libraries available and just about any library you want tbh, and they actually work!
Still not perfect by a long way but much faster to get up and running.

I (and anyone else that wants to) can update their Arduino ESP series devices globally using this WEB app my boy threw together in one evening. None of this complicated Pelion thingy.

https://esp-updater.netlify.app/

image
image1039×755 86.2 KB

A few bits to finish yet but I can FOTA and monitor my ESP devices quick and simple.

If my lad who ‘dabbles’ can do this in a couple of hours, why can’t we have something like this on Mbed?

I find it quite embarrassing really, I always moaned at others using Arduino, now I am :frowning: :frowning:

I want to come back to Mbed, can we have a change of staff and direction please ???

1 Like
32

Agree completely! I also got really frustrated about Mbed OS. Here is why:
Too often they change code WITHOUT testing the changes on the target for which they made the change. If some virtual test scripts do not find a bug, then the change gets merged… :scream:

Despite there are 168 factory produced boards, only 8 targets are covered by real testing before releasing a new OS version. This is less than 5% of the targets one can buy :neutral_face:

The documentation of Mbed is…well super disappointing. 99% of the doc is generated automatically by doxygen. For sure the character count of the doc is good enough, but good luck if you are about to really understand what the automated process tried to describe. Then i still did not mention doxygen just misses many important details.

Because of all that

  • i way too often face unexpected bugs (okay i can at least limit those bug if i NEVER(!) upgrade OS version (but that is a quite unreal expectation…)
  • i find myself wasting too much time digging up core code trying to figure out what has been missed in the doc
  • my eyes get sore of trying to read the doc which is also quite badly formatted beyond the actual content being suboptimal

The only things i really like about Mbed is the coding style, the flexibility regarding pin roles and the fact Mbed code runs faster (but Arduino code needs to work with MCUs just with some KB flash/RAM).

I never thought i will ever consider Arduino, but it seems they have a “PRO” version of their IDE, also the classic IDE is just about to change with the Beta release of V2.0. Both these have a file explorer that allows creating/editing .h and .cpp files.
Not to mention Arduinos doc is written by humans for humans, explains almost everything (does not assume you are someone who wrote the core code so you know everything about the particular functionality). Meaning if i read Arduino doc i can write my Arduino code in just some hours and it will 99% work as expected. I do not have to spend days/weeks trying to figure out what has not been mentioned in the docs as with Mbed.

I think i am really close to convert over to Arduino despite i do not really like their coding style, but i do not care about that if i can spare many-many hours compared to Mbed. (Not to mention with Arduino i could program other MCUs beyond those based on ARM-architecture).

1 Like
33

Thanks for sharing! It’s very useful!