6 ms·

I am curious - does anyone have some feedback from using the mbed ecosystem? I have generally shied away from using too much vendor middleware but it does look

I am curious - does anyone have some feedback from using the mbed ecosystem? I have generally shied away from using too much vendor middleware but it does look like there are a lot of useful libraries.

LeifCarrotson 8y ago
I've uzed the original mbed NXP LPC1768 several years ago, and didn't do too much with the vendor ecosystem, but it was very easy to just use the regular ARM-GCC compiler and extract the functionality I needed from their libraries into my own projects.
hak8or 8y ago
I would also love to hear replies to this. I used mbed in the past and have been fairly dissatisfied with it for two reasons: It uses c++ for the sake of using c++ instead of leveraging the extreme bonuses c++ provides over using c for embedded. For example, it tends to use dynamic memory allocation heavily, doesn't make use of unique/shared pointer, doesn't use templates properly (if at all) in places it would be ideal (hence increasing code size and slowing things down). Last I checked, it doesn't support cmake at all, and instead used an extremely complicated and conveluted build system/process. Both of those combined made me run away and never look back. Another side thing as of late is it seems to be officially supported by arm, which means it will never run on other cores like risc-v. I am not interested in getting stuck with one platform when riscv (in my opinion) has incredible potential for microcontrollers and is seemingly right around the corner.
- notacoward 8y ago
  Your criticism seems a bit idiosyncratic, to put it kindly. So it doesn't use the flavor of C++ you prefer? Sure, but there's a lot of room for argument about whether shared_ptr or template-instantiation bloat would be good choices for an IoT-level embedded system. Similarly, the fact that it doesn't use cmake seems like more a matter of preference than of actual suitability. As for being supported by ARM, well hey, at least it's open source. It could theoretically be forked for RISC-V. Lacking any mention of alternatives, that criticism also seems rather hollow. Beggars can't be choosers, y'know. BTW, you maybe should have mentioned that you work on a competing project.
  - swiley 8y ago
    Dynamic memory allocation on an embedded system is pretty bad. Even in desktop applications you should usually try and avoid that. Over complicating the build system is a reason for dropping almost anything but especially this. The whole point of a framework like that is to make things easier.
    - notacoward 8y ago
      > Dynamic memory allocation on an embedded system is pretty bad. That's the one criticism I found valid. I even called it one of the "Four Horsemen of Poor Performance" in a pretty widely read article I wrote on server performance back in 2002. On the other hand, over-reliance on static allocation means allocating many arrays/pools for the worst case, even when they couldn't possibly all hit worst case at the same time, and that can be a pretty bad choice on a highly memory-constrained device. (Doing it for the sake of real-time predictability is actually a different issue.) OTOH complaining about not using templates because of performance seems exactly backwards, and complaining that it's not likely the the project sponsor will port already-open-source code to a competing architecture themselves seems a bit too entitled. When I see a list of negatives that are mostly bogus, and no mention of positives at all, it's a strong indicator of NIH syndrome.
  - vhodges 8y ago
    (replying to parent as well). I have not used it but zephyr (https://www.zephyrproject.org https://www.zephyrproject.org) is a cross platform (including riscv) os/platform that looks interesting for embedded development.
  - justincormack 8y ago
    The EULA for mbed says "ensure that they are licensed for use only as part of Software Applications and only on microprocessors manufactured or simulated under licence from Arm" https://os.mbed.com/eula/ https://os.mbed.com/eula/ It is confusing though as the code mostly appears to be Apache, not sure if it is just parts that are constrained by the EULA, but it is clearly not intended to be ported to RISC-V or MIPS or whatever.
- kevin_thibedeau 8y ago
  There is a difference between mbedOS and the support libraries which can all be used independently of their monolithic system. Modern C++ is not supported by some commercial compilers so you get lowest common denominator in that case but that is irrelevant to the core libs all implemented in C.
ross-squires 8y ago
I'm a huge fan of mbed OS. The build system adapts to any environment, and you can "eject" if you want to tweak a specific build style. I personally use VS Code with the "mbed compile" workflow. The official libraries are well-documented and easy to use. I've had to fight a couple vendor-specific oddities when adapting third-party components from their online community, but everything else seem to work as expected.
deleted 8y ago
[deleted]
tom_ 8y ago
I worked with mbedTLS on a desktop/mobile project a couple of years ago. I'd previously used OpenSSL, and I wasn't very impressed, but mbedTLS seemed OK: easy to get it building with cmake, easy to get it building on Windows/OS X/iOS/Linux, no actual I/O in the library. I remember finding integration with libuv a mite annoying, as mbedTLS is rather pull-minded, and I didn't find the documentation for the I/O callbacks super-clear. If your I/O callbacks are making blocking calls of a pipe or socket, though, I'm sure it's much simpler. Would use again. (Would not use OpenSSL again.)
- Gibbon1 8y ago
  > (Would not use OpenSSL again.) Reminds me of someone using this gif to describe working with OpenSSL. https://imgur.com/gallery/ikBZF82 https://imgur.com/gallery/ikBZF82
- kevin_thibedeau 8y ago
  mbedTLS is mostly nice but it does suffer from some poor coding practices like large buffers allocated on the stack. I would warn anyone to stay away from Cypress/Broadcom's WICED OS which has a modified version of mbedTLS with foolish changes to the API that makes porting code extremely challenging.
cozzyd 8y ago
I have a tiny bit of experience with it. I found it hard to keep track of which libraries worked with each other or with my particular microcontroller (particularly anything involving networking), but it was probably just my own ignorance.
- Gibbon1 8y ago
  My experience with it was all the packages for the platform I wanted to use were broken.
catherd 8y ago
mbed is great for prototyping. It's basically the Arduino system you would have gotten if Arduino was developed by people who mostly already know what they are doing instead of learning as they go. Lots of libraries for various sensors and other applications, so if you do early stage development on hardware you can quickly throw prototypes together and not need to deal with sorting through a lot of mediocre Arduino stuff. YMMV on keeping it for production use. Some parts of it should be fine for some applications. Other things not. I've run into issues with things like threads and timers not always working right for every library, but really that's par for the course on a system of libraries that diverse, and supporting so many different chips.
diydsp 8y ago
yes. i found a bug in the gcc export along with a dozen others. mbed devs hemmed and hawed about it for 6 months until they convinced themselves it's not a bug. I dropped mbed after that, switched that project over to Arduino.

LeifCarrotson 8y ago

I've uzed the original mbed NXP LPC1768 several years ago, and didn't do too much with the vendor ecosystem, but it was very easy to just use the regular ARM-GCC compiler and extract the functionality I needed from their libraries into my own projects.

hak8or 8y ago

I would also love to hear replies to this. I used mbed in the past and have been fairly dissatisfied with it for two reasons: It uses c++ for the sake of using c++ instead of leveraging the extreme bonuses c++ provides over using c for embedded. For example, it tends to use dynamic memory allocation heavily, doesn't make use of unique/shared pointer, doesn't use templates properly (if at all) in places it would be ideal (hence increasing code size and slowing things down). Last I checked, it doesn't support cmake at all, and instead used an extremely complicated and conveluted build system/process. Both of those combined made me run away and never look back. Another side thing as of late is it seems to be officially supported by arm, which means it will never run on other cores like risc-v. I am not interested in getting stuck with one platform when riscv (in my opinion) has incredible potential for microcontrollers and is seemingly right around the corner.

notacoward 8y ago
Your criticism seems a bit idiosyncratic, to put it kindly. So it doesn't use the flavor of C++ you prefer? Sure, but there's a lot of room for argument about whether shared_ptr or template-instantiation bloat would be good choices for an IoT-level embedded system. Similarly, the fact that it doesn't use cmake seems like more a matter of preference than of actual suitability. As for being supported by ARM, well hey, at least it's open source. It could theoretically be forked for RISC-V. Lacking any mention of alternatives, that criticism also seems rather hollow. Beggars can't be choosers, y'know. BTW, you maybe should have mentioned that you work on a competing project.
- swiley 8y ago
  Dynamic memory allocation on an embedded system is pretty bad. Even in desktop applications you should usually try and avoid that. Over complicating the build system is a reason for dropping almost anything but especially this. The whole point of a framework like that is to make things easier.
  - notacoward 8y ago
    > Dynamic memory allocation on an embedded system is pretty bad. That's the one criticism I found valid. I even called it one of the "Four Horsemen of Poor Performance" in a pretty widely read article I wrote on server performance back in 2002. On the other hand, over-reliance on static allocation means allocating many arrays/pools for the worst case, even when they couldn't possibly all hit worst case at the same time, and that can be a pretty bad choice on a highly memory-constrained device. (Doing it for the sake of real-time predictability is actually a different issue.) OTOH complaining about not using templates because of performance seems exactly backwards, and complaining that it's not likely the the project sponsor will port already-open-source code to a competing architecture themselves seems a bit too entitled. When I see a list of negatives that are mostly bogus, and no mention of positives at all, it's a strong indicator of NIH syndrome.
- vhodges 8y ago
  (replying to parent as well). I have not used it but zephyr (https://www.zephyrproject.org https://www.zephyrproject.org) is a cross platform (including riscv) os/platform that looks interesting for embedded development.
- justincormack 8y ago
  The EULA for mbed says "ensure that they are licensed for use only as part of Software Applications and only on microprocessors manufactured or simulated under licence from Arm" https://os.mbed.com/eula/ https://os.mbed.com/eula/ It is confusing though as the code mostly appears to be Apache, not sure if it is just parts that are constrained by the EULA, but it is clearly not intended to be ported to RISC-V or MIPS or whatever.
kevin_thibedeau 8y ago
There is a difference between mbedOS and the support libraries which can all be used independently of their monolithic system. Modern C++ is not supported by some commercial compilers so you get lowest common denominator in that case but that is irrelevant to the core libs all implemented in C.

ross-squires 8y ago

I'm a huge fan of mbed OS. The build system adapts to any environment, and you can "eject" if you want to tweak a specific build style. I personally use VS Code with the "mbed compile" workflow. The official libraries are well-documented and easy to use. I've had to fight a couple vendor-specific oddities when adapting third-party components from their online community, but everything else seem to work as expected.

deleted 8y ago

[deleted]

tom_ 8y ago

I worked with mbedTLS on a desktop/mobile project a couple of years ago. I'd previously used OpenSSL, and I wasn't very impressed, but mbedTLS seemed OK: easy to get it building with cmake, easy to get it building on Windows/OS X/iOS/Linux, no actual I/O in the library. I remember finding integration with libuv a mite annoying, as mbedTLS is rather pull-minded, and I didn't find the documentation for the I/O callbacks super-clear. If your I/O callbacks are making blocking calls of a pipe or socket, though, I'm sure it's much simpler. Would use again. (Would not use OpenSSL again.)

Gibbon1 8y ago
> (Would not use OpenSSL again.) Reminds me of someone using this gif to describe working with OpenSSL. https://imgur.com/gallery/ikBZF82 https://imgur.com/gallery/ikBZF82
kevin_thibedeau 8y ago
mbedTLS is mostly nice but it does suffer from some poor coding practices like large buffers allocated on the stack. I would warn anyone to stay away from Cypress/Broadcom's WICED OS which has a modified version of mbedTLS with foolish changes to the API that makes porting code extremely challenging.

cozzyd 8y ago

I have a tiny bit of experience with it. I found it hard to keep track of which libraries worked with each other or with my particular microcontroller (particularly anything involving networking), but it was probably just my own ignorance.

Gibbon1 8y ago
My experience with it was all the packages for the platform I wanted to use were broken.

catherd 8y ago

mbed is great for prototyping. It's basically the Arduino system you would have gotten if Arduino was developed by people who mostly already know what they are doing instead of learning as they go. Lots of libraries for various sensors and other applications, so if you do early stage development on hardware you can quickly throw prototypes together and not need to deal with sorting through a lot of mediocre Arduino stuff. YMMV on keeping it for production use. Some parts of it should be fine for some applications. Other things not. I've run into issues with things like threads and timers not always working right for every library, but really that's par for the course on a system of libraries that diverse, and supporting so many different chips.

diydsp 8y ago

yes. i found a bug in the gcc export along with a dozen others. mbed devs hemmed and hawed about it for 6 months until they convinced themselves it's not a bug. I dropped mbed after that, switched that project over to Arduino.