A little fail-safe filesystem designed for microcontrollers (2017)
1–10 of 32 posts
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#2I 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.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#3I 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'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.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#4I 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 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.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#5I didn't read all of the design, but it looks like the author had an unusually clear understanding of the tradeoffs involved and how they relate to the specific target environment. There are some clever solutions there, all explained quite well. Definitely worth a look.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#6I 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…
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.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#7Earlier 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,…
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.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#8I 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'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.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#9Earlier 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,…
(replying to parent as well).
I have not used it but zephyr (https://www.zephyrproject.org) is a cross platform (including riscv) os/platform that looks interesting for embedded development.
Re: A little fail-safe filesystem designed for microcontrollers (2017)
#10Nice, perhaps a more robust fatfs replacement?
If you've used this (or are the author) how is the "storage on disk ... always kept in a valid state" feature implemented? Does it write two copies in case a write's interrupted so one can always roll back to the earlier valid copy?