4 ms·

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

by 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.
  - als0 8y ago
    That EULA is specifically for the ARM RealView compilation tools, which are proprietary AFAIK. You don't need any EULA to use any of Mbed's stuff, it's all Apache licensed and can use any compiler.
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.

by hak8or 8y ago

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.
- als0 8y ago
  That EULA is specifically for the ARM RealView compilation tools, which are proprietary AFAIK. You don't need any EULA to use any of Mbed's stuff, it's all Apache licensed and can use any compiler.

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.