Should I use MBED of ARM or native platform of microcontroller suppliers?

Question

I got a STM32F429I-DISC1 development board from STMicoelectronics and I know MBED support it.

So if I want to learn about ARM and develop a commercial product in the future, should I use MBED platform or native platform of STMicoelectronics?

Answer 1

It depends.

• Do you want easy portability between ARM microcontrollers of different product families or even manufacturers? Do you wish to develop IoT applications and want simple internet connectivity? Would you like a vast selection of portable, easy to use libraries?
  Use mbed.

• Do you despise having to reinvent the wheel, but don't want the overhead of mbed? Do you dislike developing code with a web app? Is the ability to switch to a different manufacturer superfluous to you, but portability within the same product family is still required?
  Use the native libraries from ST (HAL or SPL).

• Do you want full control over every little detail of the hardware and software? Do you want to optimize your code to fit in the cheapest microcontroller, execute super fast, or use as little power as possible? Do you hate having to deal with over-abstracted, slow and inflexible libraries and would rather do it yourself?
  Program bare metal: include just CMSIS and register definitions, study the datasheet with care, and write your own code.

Answer 2

Mbed offers:

• Portability between other Cortex-M platforms.
• A vast set of networking stacks (LWiP, Nanostack) and networking drivers.
• An RTOS.
• Still wraps the STM32 HAL, so if you need something very specific you have those functions available (at the cost of non-portability).
• Can still develop and debug in STM workbench - in addition to the online IDE, uVision, VSCode, etc.

So in my personal (but biased!) opinion, there's little downside to using Mbed. It's much broader in scope than the STM32 HAL though, with many choices being made for you (choice of RTOS, choice of networking infrastructure). If you are unhappy with this, like to do bare-metal programming, or don't want the overhead of Mbed (although there are many ways to make it smaller); you could go for STM32 HAL.

Answer 3

If you are using off the shelf libraries the stm hal or mbed or a combination, you are learning just about zero about ARM. Even if you bypass the libraries most of the work is not related to ARM, it is mostly about the chip.

You should pursue all the avenues you have time for. The high and very high level solutions on the surface appear easy, but there can be a lot of work/pain involved. You are relying mostly on other peoples code, and when you dig into that code you may find that you dont like it. Professionally your boss wont care if you didnt want to put the effort end and used a library and then the library broke and the product failed and/or some percentage of a run had to be discarded or extra cost added to reprogram. Whatever path you need to be responsible for your choices, if you want to use a library then you need to own it, examine the code, be comfortable with its solutions.

I find that not using the library is much faster to develop (straight from the manual), easier, and you own the code. Smaller, performs better, etc. But at the same time is there something about that part that you dont know, did the chip vendor not find a timing bug because they used library code that ran slow and didnt uncover an issue, or bloated or not their code may hit a peripheral with a different beat frequency than yours and again a nuance to the chip yet uncovered. Are there undocumented registers you didnt touch, etc. You can/should examine their code from time to time even if doing your own thing to try to resolve these issues, a problem with library code be it you re-using your code across parts or the library supplier, is that while the chip vendor is likely re-using a module in the chip there may have been changes, library code will tend to carry baggage from prior versions of a module that do not apply any more to the module in the chip you are using, usually not a bad thing, but does make reading their code difficult sometimes.

If you hope to be a professional developer then it is in your best interest to be comfortable at all of these levels, the price of these products or even using simulators where possible for free means it is just a matter of you putting the time in, not a dollar amount. Try using the RTOS if any provided by the chip vendors SDK/BSP to implement something. Try using the chip vendors SDK/BSP libraries to make a library based bare metal solution, and try using the documentation for the part to create a bare metal solution. The latter being one where you learn something about ARM, or at least more likely to.

Mastering the tools is a big factor here, be able to build a working binary, even if somewhat trivial blinking an led, using your own exception/vector table, bootstrap code, application and linker script. the toolchains like gnu are out of the box aimed at linux/operating system based development or perhaps a specific library/sdk. But at the same time a compiler just takes high level code and outputs assembly, an assembler takes assembly and outputs an object and a linker links objects. The deeper through the toolchain the more toolchain specific it gets, a gnu ld linker script may work completely differently than some other compiler brand. The linker in general for that matter. Here again professionally you should attempt to use something other than gnu, try llvm/clang although that is somewhat connected, others might be pay-for but you can possibly get a demo/eval version.

If all you know how to do is take some canned ide/environment and call some libraries or write apps for a specific RTOS, while you can still make a living your options are clearly limited. In the time it takes you to binge watch a new season of some show, you could have that play in the corner of the screen or on a nearby tv and in parallel have learned at least one new thing that will benefit you professionally...

Although ARM clearly dominates the processor world, there are many other still active architectures that are worth exploring. the 8051 isnt going to die any time soon, you have at least one if not several in the device you are reading this on. The z80 while not as popular is still used as an 8051 alternative. there are of course other popular MCUs that are not buried in something else msp430, pic, avr (ardino uses these), and a number of others, still very widely used despite being passed over by arm solutions. many of these have simulators or open cores you can use for free to learn the architecture issues needed to get booted, etc, before getting into the non-architecture specific peripheral details. Likewise some of these have similarly inexpensive hobby/eval boards. Even better get some samples, a breakout board, a soldering iron and some jumper wires, know some of the electrical side of the product goes that much further to help you professionally.