3 ms·

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 w

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.

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.