I would like to develop my code in C++ WHAT IS THE BEST TOOL FOR PROFESSIONAL STM32 DEVELOPMENT?
For educational purpose I prefer a free IDE. What is your idea about Eclipse? Did you have coded in Eclipse for ARM CPUs?
For educational purpose I prefer a free IDE.
That's fine. I am prepared to negotiate the licence such that you can use your desired IDE.
If you can't afford my tools, you could do a lot worse than consider the Keil offering. I'm sure you have already noticed they provide a FREE development environment for the STM32L0 and STM32F0.
I've used Eclispe, and Atollic, not a big fan.
To figure out what you like, and what works for you, you need to evaluate them yourself. This way you can create a list of what features are important to you, and which are critical.
Free tools tend to lack the "integration" of critical things like debugging, and trace.
"Free tools tend to lack the "integration" of critical things like debugging, and trace."
While free tools often have a developer who burns for some features he/she found missing in some commercial tool, so free tools can sometimes be very strong in some specific editing functionality.
One problem with a commercial IDE, is that the company who makes it has limited resources so they tend to spread the butter a bit thin. And a problem with community-developed IDE:s is that everyone wants to focus in different directions so they have a tendancy to get a billion bells and whistles that doesn't integrate really well and that sometimes haven't been given the required rework needed after the first round of end-user comments.
In the end, an all-in-one solution will seldom be best at everything. A lorry is better than a station wagon when lots of stuff needs to be transported. And a cab is nicer to drive in sunny and warm weather. While a sports car will be niftier on curvy roads.
It's easy to think that this isn't relevant for software since software isn't limited by normal physical laws like cars are. But software has other limitations - more features means more crowded menu systems, more overloading of hot-key combinations and more magical context-sensitivity features clashing with each other. The 40+ year old command-line tools in Unix still wins over GUI tools for lots of tasks by having each tool great at a few things and letting the end-user chain together the tools according to individual needs.
Thanks.
Sadly, documentaion is rarely one of them.
:-(