Simplest free/cheap IDE for STM32F7 discovery board

[bigdawg]

Hi guys, I got the new STM32F7 (http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?icmp=pf261641_pron_pr-massmarket_jun2015&sc=stm32f7discovery-pr) board the other day and I am thinking of playing around with it, but since this is my first foray into the ST micro boards; I dont know which IDE is best/simplest to use. I went online, and found that there is system workbench for STM32 (http://www.openstm32.org/System+Workbench+for+STM32); however, its not user friendly at all, and it looks much harder to flash the firmware onto the board than the other boards I have worked with in the past like TI tiva or Arduino etc. Plus, I have looked up the forums, and it doesnt seem like many people are using it at all.

I'll be glad if someone can suggest some alternatives for the IDE which have some tutorials/videos I can refer to, and hopefully get a firmware for a simple blink or PWM control of motor going.

[newbrain]

Hi all, first post here, but I have been lurking for some time.
I felt I could contribute to the topic, so here I am...

I have used STM32 Nucleo and Discovery boards for some of my projects, and I also have a and F7 Disco, so I went through an evaluation process similar to yours.
Here are some pieces of advice, take them as personal,  experience based, opinions:
0- If these are your first steps in ARM/STM32 programming, you have chosen a (IMO) very good product, but a steep learning curve: the F7 Disco is a very complex board, with lots of sophisticated peripherals (both on chip and on board), and limited access to I/O pins (just the Arduino connectors). Arduino is a different world.
1- Take your time to learn the platform. The amount of information available is daunting: the Reference manual for the processor is 1655 pages. You must know it by heart, including the errata (half joking, but read the MCU datasheet, and I was bitten by one of the errata).
2- STM32F7 does away with the classical STD Peripheral libraries, so it's either hand written code for register access or HAL. I'd go for HAL for anything more complex than a blinky.
3- Use STM32CubeMX to generate clock and peripheral initialization code. Doing it by hand is possible (and definitely a good learning exercise to be done at least once or twice), but tedious and error prone: life is too short. The generated code can be easily included in a project of your favorite IDE.

Now, to the environments:
0- I use both Windows and Linux, but the better IDEs are, for whatever reasons, Windows only. My STM32 coding is 99% under Windows.

Free:
0- Go Commando. Use you preferred editor, gcc, makefiles, openocd. You'll show how tough you are, and pull a lot of hair (the rest will grow white...). Advisable only if you have lot of time, patience and some experience, but you'll learn a lot...maybe too much.
1- The free version of professional packages for ARM are, in general code size limited (32kB). With a complex board as the F7 Disco, it's easy to hit this limit when you start using on-board peripherals. I don't dislike Keil (and it's unlimited, free for STM32F0 cores!)
2- The greatest part of free IDE are Eclipse based. Eclipse is a powerful piece of SW, but I find it very complex and often not so intuitive (I'm also professionally exposed to it).
3- System Workbench is Eclipse based, with all the advantages and disadvantages, but it was the first (AFAIK) to explicitly support the F7 (no surprise, coming from ST itself). It's also well integrated with CubeMX. For free, I find it a reasonable choice. I did not have any great problem with flashing.
4- CooCOX CoIde is a (very) pared down Eclipse IDE. Easy to use with F0-F4, some glitches and frequent crashes (at least for me). Unfortunately, no F7 support roadmap and glacial updates (at least lately). It can be coaxed to compile for F7 (just use F4, same instruction set) but no flash or debug support (IIRC), so I would not advise to use it (at the moment).
5- Em::blocks (now EmBitz) is lean and liked by many. It has almost complete F7 support (still a bit buggy, check the forum). I'm not so keen on its look and feel, but it might be viable and it's worth a try.
6- EmIde: last version is more than one year old, so no F7 support.
7- Coming from Arduino, you might want to consider mbed, similar in many ways, different in others. Not for me, but YMMV. F7 Disco is supported.

Commercial:
0- Most IDE have a time trial or code size limited version. Try them!
1- Professional IDEs are really out of reach for a hobby. Definitely worth it for work, mostly due to real support. If you're just "having fun" consider what you might get with the same amount of money (>2000€) in terms of test and measurement instruments...
2- Crossworks: 150$ for a non-commercial license, if you intend to ever sell your code/product it's a steep 1500$ for a commercial one! No explicit F7 Disco board support package, but F7 is supported (though not 746). Worth trying, but the fixed editor keybindings (I have got Emacs finger-bindings) and lack of editor automation are a sad omission.
3- Visual Studio+Visualgdb. 74€+taxes for the embedded version. Full F7 Disco support, regular updates to GCC and other tools (openocd), 30-day trial. The product works very well, gives you either "do it for me" or detailed control on the build process and includes all libraries and board support packages (not only ST), very good debug support. This is very much a question of taste: Visual Studio Community Edition 2015 is free (and not crippled in any significant way) and it's a very complete, stable and well supported IDE. It comes from Microsoft, though, and this can turn away someone.

What do I use?
For some time, I have been using System Workbench (it works!) and trying all of the above environments. I recently bit the bullet and bought Visualgdb. I do not regret the money spent.

Links:
Keil: https://www.keil.com/arm/demo/eval/arm.htm, http://www2.keil.com/stmicroelectronics-stm32/mdk
CoIde: http://coocox.org/
Em::blocks: http://www.emblocks.org/web/
Crossworks: http://www.rowley.co.uk/arm/index.htm
Visualgdb: http://visualgdb.com/
mbed: https://www.mbed.org/

Hope this helps!

[bigdawg]

Hi all, first post here, but I have been lurking for some time.
I felt I could contribute to the topic, so here I am...

Thanks a lot for such a detailed reply. I came extremely close to thinking that maybe this board is so new that none of the experienced people havnt had a chance to play with it much and hence no reply here.

I have used STM32 Nucleo and Discovery boards for some of my projects, and I also have a and F7 Disco, so I went through an evaluation process similar to yours.
Here are some pieces of advice, take them as personal,  experience based, opinions:
0- If these are your first steps in ARM/STM32 programming, you have chosen a (IMO) very good product, but a steep learning curve: the F7 Disco is a very complex board, with lots of sophisticated peripherals (both on chip and on board), and limited access to I/O pins (just the Arduino connectors). Arduino is a different world.

you are absolutely right; this board has so many peripherals, but that makes it a lot complex for novices like me.

1- Take your time to learn the platform. The amount of information available is daunting: the Reference manual for the processor is 1655 pages. You must know it by heart, including the errata (half joking, but read the MCU datasheet, and I was bitten by one of the errata).
2- STM32F7 does away with the classical STD Peripheral libraries, so it's either hand written code for register access or HAL. I'd go for HAL for anything more complex than a blinky.
3- Use STM32CubeMX to generate clock and peripheral initialization code. Doing it by hand is possible (and definitely a good learning exercise to be done at least once or twice), but tedious and error prone: life is too short. The generated code can be easily included in a project of your favorite IDE.

I have looked at that reference manual, and its longer and more detailed than for any other MCU I have ever worked with. I have started to look through the HAL library manual (http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00189702.pdf) just so thatI can select a digital pin and write a blinkly program for it. even something as simple as that is complex since the actual pin numbers on the arduino connector are not the same (GPIO) numbers in the HAL library.

I am too inexperienced to even begin to write a code "by hand" so I'll have to rely on the library for now. In this regard I feel like NXP, TI boards have a less steep learning curve than this one; but than again, this one is probably more high performance than any of those cortex  M3/M4 ones.

Free:
0- Go Commando. Use you preferred editor, gcc, makefiles, openocd. You'll show how tough you are, and pull a lot of hair (the rest will grow white...). Advisable only if you have lot of time, patience and some experience, but you'll learn a lot...maybe too much.

not even an option  I cannot even begin to imagine how I am supposed to do all of that so I'll stick with more "low key" options!

3- System Workbench is Eclipse based, with all the advantages and disadvantages, but it was the first (AFAIK) to explicitly support the F7 (no surprise, coming from ST itself). It's also well integrated with CubeMX. For free, I find it a reasonable choice. I did not have any great problem with flashing.
4- CooCOX CoIde is a (very) pared down Eclipse IDE. Easy to use with F0-F4, some glitches and frequent crashes (at least for me). Unfortunately, no F7 support roadmap and glacial updates (at least lately). It can be coaxed to compile for F7 (just use F4, same instruction set) but no flash or debug support (IIRC), so I would not advise to use it (at the moment).
5- Em::blocks (now EmBitz) is lean and liked by many. It has almost complete F7 support (still a bit buggy, check the forum). I'm not so keen on its look and feel, but it might be viable and it's worth a try.
6- EmIde: last version is more than one year old, so no F7 support.
7- Coming from Arduino, you might want to consider mbed, similar in many ways, different in others. Not for me, but YMMV. F7 Disco is supported.

I have installed system workbench already so maybe I'll give it another look since you seem to use it without problems. I see very polarised reviews for mbed; some people seem to love it whereas other folks say its worse than leprosy  . would you say that it has a lesser of a learning curve? and can I still use those HAL libraries with mbed?

3- Visual Studio+Visualgdb. 74€+taxes for the embedded version. Full F7 Disco support, regular updates to GCC and other tools (openocd), 30-day trial. The product works very well, gives you either "do it for me" or detailed control on the build process and includes all libraries and board support packages (not only ST), very good debug support. This is very much a question of taste: Visual Studio Community Edition 2015 is free (and not crippled in any significant way) and it's a very complete, stable and well supported IDE. It comes from Microsoft, though, and this can turn away someone.

What do I use?
For some time, I have been using System Workbench (it works!) and trying all of the above environments. I recently bit the bullet and bought Visualgdb. I do not regret the money spent.

I'll check visualgbd too, I didnt even know anything about it but after your reply I'll definately check it out.

BTW, as a side question, are there any tutorials/books etc available to get people started on STM32 boards/processors? I came across this book: http://www.cs.indiana.edu/~geobrown/book.pdf but unfortunately it seems like those libraries have changed.

Is it just me or do people work professionally in embedded technologies think too that other companies like TI, NXP, atmel etc have way more support/dumb things down enough for a beginner to start using their stuff much easily than STM  ? anyways, I have this board and I really like its features so I guess I might as well stop complaining and start learning 

[newbrain]

Some additional considerations:

- I would not like to give the impression that I'm and expert in the embedded field. I work with SW (a lot) and HW (seldom), but there are real professionals in this forum.

- That said, I've been playing with micros for almost 40 years now (designed and built my own 6502 board in '77, and wrote its monitor) ...so I do have some experience (and yes, you can get off my lawn).

- I've checked again Crossworks after answering, and it's much better than I remembered. Definitely worth a try, if the cost and license do not bother you. I still prefer VS+vgdb, though.

- I might have forgotten other options and possibilities, let's hope someone else chimes in. The MCU and the board are still fairly new, so things are changing day by day.

- HAL and mbed. Long story short, mbed like Arduino platform has its uses. It's easy to move the first steps, and there's a community behind it (less than with Arduino). I'm left wanting for more with both (even forgetting about their poor excuses for an IDE...). mbed is multi-vendor (good) but online only (bad). HAL is used by mbed STM32 target, see e.g. serial_api.c, albeit I fear that trying to use both at the same time would not be a good idea. Also, the openness of mbed is a bit under discussion (not that Arduino is free of problems...).

- I have no experience with TI's or NXP's platforms. Some time ago I was given a free F429 Discovery at a demo event, and with Nucleos 10$ a pop, I got addicted...a nice pusher job, was that. Now I crave the heavy stuff (F7...).

- Simpler libraries based upon HAL exist, ST provides BSPs for all of the Eval/Nucleo/Disco boards, with loads of example code for all the peripherals. Alternatively, you could check something like this: http://stm32f4-discovery.com/

- I can't help you with books. I like reading datasheets and programmer's references...now, don't look at me like that!

- If you're not doing this for work (but even then...), find the way that gives you the most fun. These days we have so many free or cheap options for both SW and HW, that is not difficult to find something for one's tastes. Internet religion wars (Microsoft/Linux/Apple, mbed/HAL/bare metal etc.) are a waste of time and energy. Use what you feel comfortable with, and change with no regrets.

- Yes, that board is really sweet (but for the very few I/Os)!

[Bassman59]

Hi guys, I got the new STM32F7 (http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?icmp=pf261641_pron_pr-massmarket_jun2015&sc=stm32f7discovery-pr) board the other day and I am thinking of playing around with it, but since this is my first foray into the ST micro boards; I dont know which IDE is best/simplest to use. I went online, and found that there is system workbench for STM32 (http://www.openstm32.org/System+Workbench+for+STM32); however, its not user friendly at all, and it looks much harder to flash the firmware onto the board than the other boards I have worked with in the past like TI tiva or Arduino etc. Plus, I have looked up the forums, and it doesnt seem like many people are using it at all.

I'll be glad if someone can suggest some alternatives for the IDE which have some tutorials/videos I can refer to, and hopefully get a firmware for a simple blink or PWM control of motor going.

Try using Eclipse with the GNU ARM Eclipse plug-in. It includes some skeleton projects for the ST parts.

I ditched Atmel Studio 6 in favor of it for the SAM3U design I'm doing.

[bigdawg]

- HAL and mbed. Long story short, mbed like Arduino platform has its uses. It's easy to move the first steps, and there's a community behind it (less than with Arduino). I'm left wanting for more with both (even forgetting about their poor excuses for an IDE...). mbed is multi-vendor (good) but online only (bad). HAL is used by mbed STM32 target, see e.g. serial_api.c, albeit I fear that trying to use both at the same time would not be a good idea. Also, the openness of mbed is a bit under discussion (not that Arduino is free of problems...).

thanks for a brief overview of mbed; I'll read up on it.

- I have no experience with TI's or NXP's platforms. Some time ago I was given a free F429 Discovery at a demo event, and with Nucleos 10$ a pop, I got addicted...a nice pusher job, was that. Now I crave the heavy stuff (F7...).

- Simpler libraries based upon HAL exist, ST provides BSPs for all of the Eval/Nucleo/Disco boards, with loads of example code for all the peripherals. Alternatively, you could check something like this: http://stm32f4-discovery.com/

- I can't help you with books. I like reading datasheets and programmer's references...now, don't look at me like that!

  I guess I'll have to start reading those too. In all honesty though; you are right, short term one can get away with not reading much from those references; but long term its a better idea to start reading them especially if I am going to stick by the m7 platform (which I am).

- If you're not doing this for work (but even then...), find the way that gives you the most fun. These days we have so many free or cheap options for both SW and HW, that is not difficult to find something for one's tastes. Internet religion wars (Microsoft/Linux/Apple, mbed/HAL/bare metal etc.) are a waste of time and energy. Use what you feel comfortable with, and change with no regrets.

- Yes, that board is really sweet (but for the very few I/Os)!

Oh yeah I am not at all doing it for work! I am a chemist by profession, and electronics is just a fall/winter hobby which keeps me busy over the weekends when I am too lazy to go outdoors and hunt/fish I really appreciate all your help.

[bigdawg]

Hi guys, I got the new STM32F7 (http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?icmp=pf261641_pron_pr-massmarket_jun2015&sc=stm32f7discovery-pr) board the other day and I am thinking of playing around with it, but since this is my first foray into the ST micro boards; I dont know which IDE is best/simplest to use. I went online, and found that there is system workbench for STM32 (http://www.openstm32.org/System+Workbench+for+STM32); however, its not user friendly at all, and it looks much harder to flash the firmware onto the board than the other boards I have worked with in the past like TI tiva or Arduino etc. Plus, I have looked up the forums, and it doesnt seem like many people are using it at all.

I'll be glad if someone can suggest some alternatives for the IDE which have some tutorials/videos I can refer to, and hopefully get a firmware for a simple blink or PWM control of motor going.

Try using Eclipse with the GNU ARM Eclipse plug-in. It includes some skeleton projects for the ST parts.

I ditched Atmel Studio 6 in favor of it for the SAM3U design I'm doing.

I'll check that out bassman, thanks for the suggestion!

[Brutte]

This micro (btw is F7 still a micro?) is too complicated to start with. You can blink it but won't understand why it blinks or why it does not when it was supposed to blink. I'd suggest picking something you are able to RTFRM.

Try using Eclipse with the GNU ARM Eclipse plug-in.

+1.
Some things that are worth adding: It is "Eclipse CDT" and not (raw) Eclipse and you would have to install this and other goodies as Eclipse is just a general purpose IDE (I have started php recently, by the way).
First thing you should do is to install GCC for x86 and do some "Hello Eclipse\n". When you get familiar with all the perspectives, views, options and debugging configurations then it is time to go with micros. Not the other way. IMHO.

[MT]

 Arduino is a different world.
1- Take your time to learn the platform. The amount of information available is daunting: the Reference manual for the processor is 1655 pages. You must know it by heart, including the errata (half joking, but read the MCU datasheet, and I was bitten by one of the errata).

The F429 reference manual is 1728 pages........ and yet you have to  wade trough the programmers manual of 245 pages just to turn on systick registers! The whole STM scenario is just hilarious!

[Bassman59]

Try using Eclipse with the GNU ARM Eclipse plug-in.

+1.
Some things that are worth adding: It is "Eclipse CDT" and not (raw) Eclipse and you would have to install this and other goodies as Eclipse is just a general purpose IDE (I have started php recently, by the way).

That is true, although the guy who did that plug-in wrote a very comprehensive set of installation instructions, so the CDT is installed as are the ARM "packs" which are some kind of magic.

[newbrain]

 Arduino is a different world.
1- Take your time to learn the platform. The amount of information available is daunting: the Reference manual for the processor is 1655 pages. You must know it by heart, including the errata (half joking, but read the MCU datasheet, and I was bitten by one of the errata).

The F429 reference manual is 1728 pages........ and yet you have to  wade trough the programmers manual of 245 pages just to turn on systick registers! The whole STM scenario is just hilarious!

Rejoice!
There's no Programmer's Manual for the F7, as yet, at least.
But the core is F4 compatible, bar the bit-banding IIRC, so your 429 knowledge doesn't go to waste...

I don't know if other platforms are simpler, I did not find any overwhelming problem with STM32Fx, and actually started with a 429 (but I find the ATmega documentation less readable and understandable, as an example).

Try using Eclipse with the GNU ARM Eclipse plug-in. It includes some skeleton projects for the ST parts.

How could I forget this one?
Still, it does not seem to include F7 support (at the moment at least), no mention of it on the site, in paticular the bundled openocd is 0.9.0 from may, which did not include the patches for F7 flashing. But, I might try it to see how it goes...

You can blink it but won't understand why it blinks or why it does not when it was supposed to blink. I'd suggest picking something you are able to RTFRM.

Yes, and no. The blink example, using the HAL is remarkably consistent across all the Fx cores.
So I agree that you might not understand everything that's going on at first (e.g. clock chains, power settings etc.) but the GPIO is similar to all the others I have seen, starting from the 6522: it's even easy to drive directly register-wise. Starting without the HAL? No way!
As said, I'm not acquainted with other 32bit (ARM) platforms, only several 8bit ones.

Then, one can work their way up, start using e.g. an UART (the on-board ST-Link provide a handy USB-UART bridge), simple timers then PWM, interrupts, DMA and so on. A long journey, no doubts about it!
It does not work any differently because there's a truckload of peripherals on the board, but for the fact one is mostly limited to the Arduino connectors as free I/Os.

[bigdawg]

 Arduino is a different world.
1- Take your time to learn the platform. The amount of information available is daunting: the Reference manual for the processor is 1655 pages. You must know it by heart, including the errata (half joking, but read the MCU datasheet, and I was bitten by one of the errata).

The F429 reference manual is 1728 pages........ and yet you have to  wade trough the programmers manual of 245 pages just to turn on systick registers! The whole STM scenario is just hilarious!

lol we had a long (3 day) weekend here, and I was goong through the reference manual thinking someone at STM could have made this thing a bit simpler. I mean I have worked on a LPC board before with 800 page manual, but this thing is just a beast.

[bigdawg]

This micro (btw is F7 still a micro?) is too complicated to start with. You can blink it but won't understand why it blinks or why it does not when it was supposed to blink. I'd suggest picking something you are able to RTFRM.

Try using Eclipse with the GNU ARM Eclipse plug-in.

+1.
Some things that are worth adding: It is "Eclipse CDT" and not (raw) Eclipse and you would have to install this and other goodies as Eclipse is just a general purpose IDE (I have started php recently, by the way).
First thing you should do is to install GCC for x86 and do some "Hello Eclipse\n". When you get familiar with all the perspectives, views, options and debugging configurations then it is time to go with micros. Not the other way. IMHO.

Brute, I have worked with other ARM boards like NXP's LPC 1769 and TI boards so this isnt completely new to me although this is my first STM board. I just feel like if I compare STM to other companies, than ST has probably the best bang for the buck, hardware price wise, although they really are bad when providing a IDE or documentation for running a simple blinky. And for whatever reason, they dont have std peripheral library on this board (only HAL) so they complicated it even more.

[bigdawg]

Yes, and no. The blink example, using the HAL is remarkably consistent across all the Fx cores.
So I agree that you might not understand everything that's going on at first (e.g. clock chains, power settings etc.) but the GPIO is similar to all the others I have seen, starting from the 6522: it's even easy to drive directly register-wise. Starting without the HAL? No way!
As said, I'm not acquainted with other 32bit (ARM) platforms, only several 8bit ones.

Newbrain, I was finally able to run the blinky using HAL libraries and using the system workbench as IDE. I got a few errors while trying to compile the program and flashing it (I think it was GCC not found), but apparently the firmware flashed just fine if I disregarded those messages and went to subsequent steps.

Thanks for all the help! I'll attach some screenshots here once I get home today so other people in future know which errors you can safely ignore 

[Gabri74]

0- I use both Windows and Linux, but the better IDEs are, for whatever reasons, Windows only. My STM32 coding is 99% under Windows.

For your information, Keil uVision works well under Linux on Wine with this limitations/bugs:
- debugger/programmer does not work because it needs specific Win$ dlls and there's no generic gdb-server target
- there's some kind of UI polling on the main page, so if you are doing nothing, CPU usage is quite high. But if you leave a dialog
opened (e.g. the file or about dialog) CPU usage drops to 0%
- if you have a valid Win$ license, it will work in Linux too
- Version 4.74 works flawlessly, but version 5.x has some problem downloading and installing MCU packages

I've also created a couple of entries in the tools menu to launch a Vim window for editing and to create sim-links under
/tmp/ for the build targets to be used by OpenOCD

[newbrain]

Newbrain, I was finally able to run the blinky using HAL libraries and using the system workbench as IDE.

Bravo! Glad to hear you managed it. I've some doubt it did not find GCC, if you got it compiled!

0- I use both Windows and Linux, but the better IDEs are, for whatever reasons, Windows only. My STM32 coding is 99% under Windows.

For your information, Keil uVision works well under Linux on Wine with this limitations/bugs:
- debugger/programmer does not work because it needs specific Win$ dlls and there's no generic gdb-server target
- there's some kind of UI polling on the main page, so if you are doing nothing, CPU usage is quite high. But if you leave a dialog
opened (e.g. the file or about dialog) CPU usage drops to 0%
- if you have a valid Win$ license, it will work in Linux too
- Version 4.74 works flawlessly, but version 5.x has some problem downloading and installing MCU packages

I've also created a couple of entries in the tools menu to launch a Vim window for editing and to create sim-links under
/tmp/ for the build targets to be used by OpenOCD

This is very interesting information, though I'm not going to try it, having both OSes natively or virtually available (too many computers, and MCUs, too little time...), and given the problems with debugging. It is, however, incredible how far Wine has come.

PS: I think you meant Keil$ rather than Win$ (si fa per scherzare...).

[bigdawg]

Newbrain, I was finally able to run the blinky using HAL libraries and using the system workbench as IDE.

Bravo! Glad to hear you managed it. I've some doubt it did not find GCC, if you got it compiled!

I am attaching a couple of error pages which popped up; I disregarded them and the program compliled and flashed correctly. This may just be a bug in the IDE or I did something. either way, it works 

[ale500]

In the Project's preferences page -> C/C++ Build -> Environment you can add the path to the arm-eabi-none-xx executables.

[EmBlocks]

....
5- Em::blocks (now EmBitz) is lean and liked by many. It has almost complete F7 support (still a bit buggy, check the forum). I'm not so keen on its look and feel, but it might be viable and it's worth a try.
....

I'm not aware that there are still bugs in the F7 implementation.

Side note:
EmBlocks/EmBitz is the only free IDE which is supporting live variables (watch variables on running target). Keep your mouse still on a global variable and you will get a tooltip with a 250mS update of the variable/expression. Also the watches  and memory viewing window is supporting live updates.

[newbrain]

....
5- Em::blocks (now EmBitz) is lean and liked by many. It has almost complete F7 support (still a bit buggy, check the forum). I'm not so keen on its look and feel, but it might be viable and it's worth a try.
....

I'm not aware that there are still bugs in the F7 implementation.

Side note:
EmBlocks/EmBitz is the only free IDE which is supporting live variables (watch variables on running target). Keep your mouse still on a global variable and you will get a tooltip with a 250mS update of the variable/expression. Also the watches  and memory viewing window is supporting live updates.

Thanks for the update, and sorry to have spread incorrect info, I appreciate the correction! That was when I last checked, admittedly, some time ago, when I first received the Disco board.
To my partial excuse, I at least advised to check the forums.

And yes, live variables are a godsend.

[EmBlocks]

It was not really intended as a correction, but maybe there were still bugs that I did not know.

[janoc]

- HAL and mbed. Long story short, mbed like Arduino platform has its uses. It's easy to move the first steps, and there's a community behind it (less than with Arduino). I'm left wanting for more with both (even forgetting about their poor excuses for an IDE...). mbed is multi-vendor (good) but online only (bad). HAL is used by mbed STM32 target, see e.g. serial_api.c, albeit I fear that trying to use both at the same time would not be a good idea. Also, the openness of mbed is a bit under discussion (not that Arduino is free of problems...).

I have investigated mBed recently for a project I was doing with the STM32F0/F3 parts, but I have found it quite lacking. You can have offline compilation now (there is an option to export your project and you load it into your IDE locally), but the major issue I have found is the lacking support for the more advanced things, such as the functions of the timer peripherals on STM32s. They support some basic stuff, but anything more advanced and you are on your own. In that case I found it simpler to just ignore the entire mBed and write my own code for everything.

For the larger chips you may want to consider some alternatives to the standard peripheral libraries and HAL from ST - e.g. a full RTOS like ChibiOS or libopencm3. RTOS is an enormous advantage if you are planning to use things such as USB, because it comes with a full USB stack and pre-made things like serial over USB ready to go. Just make sure to check the licenses - they will likely be okay for a hobby project, but for something you want to sell it may not be appropriate (or you may need a commercial license).

Re IDEs:

IDEs are often a matter of taste, so what follows may not apply to everyone because you likely don't have the same needs and background as I do (20 years of sw engineering).  So things like having to edit a makefile or using gdb from the command line are not an issue for me. I am also doing mostly hobby/small scale stuff - if you are building smartphones or phone system switches, your experience will likely differ. But perhaps it helps someone.

Personally I have found the proprietary toolchains and IDEs to be a waste of time for me. They are almost always a crippled combination of the (otherwise free) gcc and something like Eclipse, NetBeans or IntelliJ (which are also otherwise free). The only advantage are the bundled examples and code/project wizards which could save you some time when you are starting a new project from scratch.

I have found it more useful to spend a bit of time and build my own template projects for common things using standard tools - cmake, make, gcc and learn how to debug code using gdb and OpenOCD (+ frontends like Eclipse). In this way I can develop embedded code in the same way as any other stuff I would for a PC, using the same tools. Thanks to cmake I am not locked in to a particular IDE and toolchain, the same project can be compiled and debugged using Eclipse, Visual Studio and e.g. emacs if I wish and it is trivial to automate many things in a very clean way directly from the build. I am using this for both my ARM and AVR projects. The only case where I am relying on a vendor IDE is anything to do with PICs because I don't have a choice due to their proprietary tooling.

Considering platforms - if you aren't using one of the commercial IDEs and are going to go the free gcc + free IDE (e.g. Eclipse) route, I strongly suggest you consider Linux for development, even if it is only on a virtual machine. It is much much simpler to build your own up to date version of gcc (e.g. because you want to use that fancy new chip that had support added in the last gcc version), openocd (for JTAG/SWD debugging) and many of the support libraries in Linux than in Windows. Most of those tools come from Unix and have Unix-style build systems - i.e. makefiles and such. There are also many dependencies, these usually are readily available for Linux but for Windows you have to jump through many hoops. That can be an enormous pain to make work, having to muck with stuff like MinGW or Cygwin. Then there is also the issue of drivers - Linux makes it easy to talk to all kinds of homegrown hardware, whether over USB or other connections. With Windows you are going to deal with the need to install drivers/prepare .inf files constantly, even if it is for a silly thing like serial over USB. Not to mention that newer Windows versions require that the drivers are signed by Microsoft.

BTW, if you have to be on Windows, there is the "ChibiStudio" (http://chibios.org/dokuwiki/doku.php?id=chibios:product:chibistudio:start ). It is Eclipse preloaded with the ARM-specific plugins, the CDT plugin and bundled with all the other tools you may need to develop with ChibiOS on Windows (gcc, openocd, etc.), so everything works out of the box.

[EmBlocks]

..
..
IDEs are often a matter of taste, so what follows may not apply to everyone because you likely don't have the same needs and background as I do (20 years of sw engineering).  So things like having to edit a makefile or using gdb from the command line are not an issue for me.
..
..

I don't think that this is a matter of how long you are working in this business but, as you already mentioned, a matter of taste and what kind of person you are.

I'm now busy for more than 30 years in the SW/HW engineering. I started with only CLI systems (CP/M etc)  and used a lot of Unix command tools when I was working in an ASIC development department. Because I'm more visually than linguistic (I always make drawings to explain problems to others and even to myself)  it was a big relief when the GUI tools made their entrance. I never did get a wet pants by knowing the most complex piped command line instructions or scripts, like in the early days when there where competitions among colleagues.

But, I don't like the tendency tools are getting bigger but not correspondingly have more features. The first windows 3.1 Keil tools fitted on a couple of 3.5" floppies, now you need a i7 and a lot of memory to keep Eclipse and all those other Java based tools happy.

[janoc]

..
..
IDEs are often a matter of taste, so what follows may not apply to everyone because you likely don't have the same needs and background as I do (20 years of sw engineering).  So things like having to edit a makefile or using gdb from the command line are not an issue for me.
..
..

I don't think that this is a matter of how long you are working in this business but, as you already mentioned, a matter of taste and what kind of person you are.

I'm now busy for more than 30 years in the SW/HW engineering. I started with only CLI systems (CP/M etc)  and used a lot of Unix command tools when I was working in an ASIC development department. Because I'm more visually than linguistic (I always make drawings to explain problems to others and even to myself)  it was a big relief when the GUI tools made their entrance. I never did get a wet pants by knowing the most complex piped command line instructions or scripts, like in the early days when there where competitions among colleagues.

My point was not to start a debate on whether or not to use a GUI/IDE or command line tool for something.
It is about finding the right tool for the job and perhaps exposing few tools that aren't that well known or the first thing coming to mind when starting a project.

Unfortunately, I know many engineers who won't touch a tool because it isn't Visual Studio or they would have to actually configure the build themselves using a file (think Makefile, CMake, etc.) instead of using the retarded  "click a mouse to set hundreds of options" project system many of these IDEs have to manage compilation. Ever tried hunting down an incorrectly set switch in a larger/complicated build? Or having to add/modify settings for multiple projects/configurations at once? The result is a very error prone and carpal tunel inducing click-fest. And good luck if you are multiple people collaborating on a project and sharing the build files using a version control system - it becomes a merging nightmare extremely quickly, especially if the IDE uses binary files for the projects.

All this is unfortunate, because there are plenty of good tools around that are either free or inexpensive and often better at the task than the big bucks commercial ones. It only takes open mind and willingness to invest a bit of time to learn them.

[Brutte]

I know many engineers who won't touch a tool because it isn't Visual Studio or they would have to actually configure the build themselves using a file (think Makefile, CMake, etc.) instead of using the retarded  "click a mouse to set hundreds of options" project system.

The indisputable advantage of GCC is that once you learn toolchain for one architecture then it is (mostly) the same when building for other.. Typically Ctrl+C/V does the job. Be it x86, PPC, AVR8, MIPS, ARM etc. Not only source code but whole ecosystem (make, ld, IDEs, gdb, nm).

Of course I do not want to discourage proprietary IAR, Keil or Microsoft products here (I have never used those). I am sure the products and support is of first class but once there is a need to skip from one architecture to the other (which is not uncommon with embedded) then the whole learning curve starts from ground zero. Be aware of that before making the choice.