21–30 of 32 posts
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.
These are single-purpose systems, you don't need to use filenames and have POSIX semantics, you typically just need to put your data into a circular buffer on FLASH. The circular buffer (with checksummed elements) will take care of bad-block management and wear levelling for you.
I've seen this far too often, filesystems are not ideal for this class of system.
Earlier quoted context omitted.
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 id…
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,…
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.
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.
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.
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.
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 callback…
Reminds me of someone using this gif to describe working with OpenSSL.
Earlier quoted context omitted.
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,…
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/ 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.
You don't need any EULA to use any of Mbed's stuff, it's all Apache licensed and can use any compiler.
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.
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.
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.
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 id…
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.
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 callback…
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.
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.