In 2020, an MCU is much more than a hunk of silicon. Indeed, it comes with a whole ecosystem including a BSP, integrated third party libraries, tooling, field application support, and more.
Thank you for a great post.
To be honest, I didnt know what stands for SDK so maybe you shoud put full title somewere at the beginning.
Also, I must say that I actually like the Eclipse-based IDEs because I once had project where I’ve been developing RTOS for Cortex-M3 and the IDE Memory view and CPU register view was of great help to me. Initially I started developing it in VS Code but I soon switched to Eclipse based IDE. Further, I like Eclipse IDEs better than Keil because Eclipse can be customised better.
Great post!
My workflow consists of VS Code with the Cortex Debug and Vim extensions with a custom makefile for cross builds, hate the forced IDEs.
Especially if the IDE is the only way of downloading the SDK (like in SiLabs’ case).
Just give me the SDK and I’ll figure out how to build my project myself, I don’t want your early 2000’s looking IDE.
The given requirements are clear and understood. At the same time, their weight factor is different: De gustibus non est disputandum!
We may or may not like Windows but every IDE has to support it otherwise it isn’t the competitor on the existing market. Every other OS is a bonus, not a requirement.
Makefile is indeed the lowest common denominator. At the same time, IDE is mostly for rapid prototype development when make takes quite significant time to tune and set it up the right/intended way.
Examples for sure are a must but their variety and quality are not less important. And this is in my mind is hugely important metric!
I did use many of those MCU and IDE but my marks are significantly different.
My major complaint is the quality of the examples - they do mostly show how to use the given MCU/SoC but they also show how NOT to design and write code - they are written by cheap outsourced engineers, require a lot of work to be understood and adapted. Yeah, this is the nature of the business…
And, of course, this is just my personal opinion.
Thanks for chiming in, Ivan. I think there’s a lot to like with Eclipse, and I understand the appeal of visual debuggers. I want everyone to be able to work with the tools they like (Eclipse, Vim, Notepad.exe, …), and not be backed into a corner by their MCU vendor 
.
I was careful in the introduction to note that this is an opinion piece. There probably is no objective truth on this topic!
I agree with you that examples are important, though I do not typically care whether or not the example code is high quality. As long as it demonstrate the use pattern for a peripheral, I’ve got what I need. One thing I did allude to in the code, is that I like to have all the examples downloaded so I can browse their code. Some SDKs require you use their project configurator to instantiate examples one by one 
.
This is completely biased.
Do you see only PSoC BLE with PSoC creator from Cypress?
Cypress also provides ModusToolbox which is cross platform (Mac, Win, Linux) and uses Makefile ecosystem.
Provides large set of code examples through Github. So continuous delivery is always there to be updated (prefered more than zip).
They support eclipse and vscode officially. But it doesn’t stop you from using vim or Emacs.
If I’d not need to manage others, especially young and/or inexperienced fellows then I may think like you’re saying. Any example needs to show not only a single side one needs but everything including grammatically correct comments. An example needs to show WHAT, HOW and WHY otherwise it is just a clue! Sometimes it’s enough.
Hey @ranjith, thanks for the note! I had not heard of Modus Toolbox before, looks like it is relatively new.
I made a change to the article to note that I’m specifically talking about PSoC Creator rather than the PSoC6 family as a whole. I’ll take a look at the module toolbox and update the article as needed.
After using Creator can’t switch my mind to Modus. Way too different tools.
Great post, @francois! This is an important but not often discussed topic. I’ve done some similar experimentation and wanted to offer a few pointers for the post. Forgive me if you’re already aware of both of these!
You mentioned that the STM32 SDK isn’t available as a monolithic download but I believe it is. Here is the link to that for the F1, and I believe that every device family has a similar resource.
You’re correct that Infineon doesn’t provide a makefile for their MCUs, but I found that the generic makefile generated by STM32CubeMX makes a decent stand-in, with a few modifications. You can find one that I used here and as long as I’m not going to get in trouble for modifying and sharing ST Microelectronics’ makefile, you should feel free to share that as widely as you’d like!
Hi all ,
Now i used vs code and gdb.
Because it is cross platform (window and linux like).
And IDE’s editor is pool.
Thanks for the link, Nathan. I looked for those and just wasn’t able to find them. Good to see they still exist! I’ll add a note to the post.
Actually, ST’s notation is underevaluated.
Indeed, ST is proposing all of its SDKs either through their STM32CubeMX tool or directly through simple zip files or even GitHub directly !
You can check:
on st web site: www.st.com/stm32cubemcupackage
on GitHub: https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer
That’s an impressive effort !
This is very cool, and I did not know about the Github repository. Seems like a new effort? I’ll update the article tomorrow. Thanks for the note @SeaFood!
Great post!
Personally my experience with Silicon Labs’ SDK has been quite good, and the SDK can be downloaded as a single zip. Their example makefiles are quite nice.
I would also give a huge penalty to the Atmel/Microchip SDK (ASF) for using precompiled libraries for which they don’t release the source code (QTocuh, LoRa etc)
According to this page it seems it was done in last April.
It seems ST also opened the Pull requests, so not just a publication, but rather an opportunity to contribute :). Definitely cool !
As far as I can tell, those are deprecated. The downloadable toolchain in that forum post is from 2016.
My bad, here is a link to a fresh version, although you need a user at silabs.com. Definately not “as available” as some of the other SDKs.