If you had to start over today with STM32... which toolchain? GCC? Kiel?

[neslekkim]

The linker does not include unused functions. Still, many of the functions themselves - which you have used - are quite large when intended for desktop applications.

Whatdoyousay?, do you mean that the libraries for gcc mcu toolchains are made for DESKTOP applications?

[neslekkim]

Yes. Fortunately the ARM GCC targetted for microcontrollers (maintained by ARM) comes with a microcontroller C library which itself has two flavours: regular and nano.
https://launchpad.net/gcc-arm-embedded
The Readme.txt has a paragraph about choosing libraries: https://launchpadlibrarian.net/200699979/readme.txt

Ah cool, lots of usefull info there, should have read this earlier

[nctnico]

Yes. Fortunately the ARM GCC targetted for microcontrollers (maintained by ARM) comes with a microcontroller C library which itself has two flavours: regular and nano.
https://launchpad.net/gcc-arm-embedded
The Readme.txt has a paragraph about choosing libraries: https://launchpadlibrarian.net/200699979/readme.txt

Ah cool, lots of usefull info there, should have read this earlier

This is one of the points where some of the compiler's hidden magic bytes itself in it's rear. When a compiler (or better said: toolchain) is compiled the relative paths to the standard include directories and libraries are hard coded into the compiler toolchain (=pre-processor, compiler, assembler, linker, etc) binaries. This is the reason why the compiler doesn't trip up when you write #include <stdlib.h>. In the end the compiler needs to know where to find this file.

If you use a generic ARM GCC package it will probably come with libraries tailored for desktop/server applications. The compiler is perfectly fine for microcontrollers but you need to pair it up with a small C library (and associated header files) to get small code. When an ARM GCC compiler package is targeted for microcontrollers this pairing will already be done for you.

[neslekkim]

Btw, nobody is mentioning this?
http://www.mikroe.com/mikroc/arm/

Is it not worth it?

[jerry507]

Work has Keil Pro. The middleware is great. If you just need to write some embedded code, gcc is fine. I personally don't really see the value proposition though. For 1k you can buy something and be up and running in a day with support. But if you want USB device, or especially host? TCPIP? Just get Keil Pro. Worth every dollar. The middleware is really where it's at.

We also use IAR and I prefer it more. It has a great debugger interface that is better than uVision 4, can't say anything about 5.

I think it's a waste of time to compare the editors of the different IDE's. We use Visual Studio Express to do all the editor stuff. Far easier to use than Eclipse with all the same features. We maintain both a solution and a IAR workspace, but the overhead is <30 seconds per file so the efficiency gained back from the editor makes it up. Besides, OP is asking about toolchains and not editors

[Sal Ammoniac]

I'm a big fan of Rowley CrossWorks. I've been using it for about 5 years now and it does everything I need. Since it's not based on Eclipse, it's very fast and the UI isn't as cluttered. The $150 personal license is also very nice.

I wrote my own RTOS and write my own drivers, so I don't have any experience using the Rowley RTOS or drivers.

[jimon]

With non embedded software development background, I've decided to stick with this humble setup :

• gcc-arm-none-eabi
• STM32CubeFx
• OpenOCD
• Qt Creator Bare Metal
• ninja build system
• github
• sourcetree
• Notepad++
• Far File Manager

This setup costs 0$ (+ 7$/month if you want private repos) and IMHO I'm much productive with it then with ARM Keil because :

• same IDE setup for AVR and x86 projects
• same version control system across all projects regardless of architecture
• same debugger across all architectures (even if I use lldb, is sort of gdb-ish)
• total understanding what's actually going on when I press build or run

I understand that ARM Keil can cover some risks because you can say "it's not my problem, it's theirs (arm, avr, whatever)" and wait for arm to fix their ide/tools, but in my world I must deliver regardless if it's theirs or mine problem, so common shared setup helps with it because corner stones are also more or less shared

[jnz]

Work has Keil Pro. The middleware is great. If you just need to write some embedded code, gcc is fine. I personally don't really see the value proposition though. For 1k you can buy something and be up and running in a day with support. But if you want USB device, or especially host? TCPIP? Just get Keil Pro. Worth every dollar. The middleware is really where it's at.

We also use IAR and I prefer it more. It has a great debugger interface that is better than uVision 4, can't say anything about 5.

I think it's a waste of time to compare the editors of the different IDE's. We use Visual Studio Express to do all the editor stuff. Far easier to use than Eclipse with all the same features. We maintain both a solution and a IAR workspace, but the overhead is <30 seconds per file so the efficiency gained back from the editor makes it up. Besides, OP is asking about toolchains and not editors

Luckily this is what I did. Kiel's IDE isn't as nice as Rowley's but imo for what I'm doing, Rowley was the wrong choice. I'm a one-man team responsible for everything electronic my company does. Keil Pro's middleware is a god-send so far. The RTX seems adequate and I won't be pushing all that hard. But to day one be up and running with USB Host with a FATsystem and have a Ethernet/TCP/Webserver on deck any time I want it... That's just not going to happen with almost anything else.

I've had some stumbles in the past few days just wrapping my head around the new registers and all of the differences from PIC. But so far well worth the transition. I just finished PWM/Timers and I'll move over to CAN Bus next but I'm already laying out specs for the next round of products I'll make.

uV5 is noticeably thin on extra features, but everything actually important seems to be there. Rowley was a VERY nice product, and if I was just doing easier stuff, like a micro per specific function (this one drives a motor, etc), that's what I would choose. Keil Pro is not cheap, but go big or go home, this isn't my hobby.


Thanks to you and everyone else for the advice so far, I hope someone stumbling on this later will get something from it.

[bombledmonk]

It's only for posterity's sake now.  From what I understand in talking to an FAE who works with ARM the 1 year licenses from Keil do not expire in the traditional sense.   They simply stop providing upgrades/updates and restrict it from being reinstalled after the date of expiration.  Otherwise it sounds like it's fully functional in perpetuity on the machine on which it was installed.   Depending on the usage model this might make it much cheaper for someone.

MDK-PRO-T-ND (1yr) $3,799.99 vs MDK-PRO-ND(perpetual) $9,499.98

MDK-ARM-T-ND (1yr) $1,960.00 vs MDK-ARM-ND(perpetual) $4,894.99

[photon]

In old old day, one had compilers that optimized and linked in only code that was used (I used TopSpeed modula2), and thus could reduce codesize, isn't things implemented like this in the mcu world?, or is it because the architecture of the libraries ties in too much so one cannot optimize out all unused code in the linking?

Every linker I know only links in functions from a library which are actually used. This depends on how the library is compiled though (each function should be in it's own 'section').

Removing dead code is not automatic in GCC. The exact flags to use are -fdata-sections -ffunction-sections -Wl,--gc-sections. It does not matter how the library is compiled. The option -ffunction-sections will put every function into its own section irregardless of how the library is compiled. See http://stackoverflow.com/questions/6687630/c-c-gcc-ld-remove-unused-symbols or https://www.eevblog.com/forum/microcontrollers/stm32f4-weird-disassembly-output/msg458876/#msg458876

[nctnico]

There are some drawbacks to using -ffunction-sections -Wl,--gc-sections because the linker is not always able to determine which code is really unused. That is why libraries (for any toolchain whether GCC or not I have seen so far) are always compiled like this (quoted from the Stackoverflow link):
The standard libraries achieve the result you're after by splitting all of their functions into seperate object files, which are combined using ar. If you then link the resultant archive as a library (ie. give the option -l your_library to ld) then ld will only include the object files, and therefore the symbols, that are actually used.
So yes, it does matter how the libraries are compiled.

[AlfBaz]

There are some drawbacks to using -ffunction-sections -Wl,--gc-sections because the linker is not always able to determine which code is really unused. That is why libraries (for any toolchain whether GCC or not I have seen so far) are always compiled like this (quoted from the Stackoverflow link):
The standard libraries achieve the result you're after by splitting all of their functions into seperate object files, which are combined using ar. If you then link the resultant archive as a library (ie. give the option -l your_library to ld) then ld will only include the object files, and therefore the symbols, that are actually used.
So yes, it does matter how the libraries are compiled.

Very interesting.

Having a quick look at the linker's map output I see the standard pre-compiled library functions have there own .section regardless having used -ffunction-sections or not

by splitting all of their functions into seperate object files

I wasn't aware the compiler (or linker) could do this but looking at section headers of libgcc.a seems to show every function coming from it's own object file

[photon]

There are some drawbacks to using -ffunction-sections -Wl,--gc-sections because the linker is not always able to determine which code is really unused. That is why libraries (for any toolchain whether GCC or not I have seen so far) are always compiled like this (quoted from the Stackoverflow link):
The standard libraries achieve the result you're after by splitting all of their functions into seperate object files, which are combined using ar. If you then link the resultant archive as a library (ie. give the option -l your_library to ld) then ld will only include the object files, and therefore the symbols, that are actually used.
So yes, it does matter how the libraries are compiled.

A .o file has sections and a symbol table. So if there are 2 functions, say alive and dead, in one section, the linker has the symbol name of the functions and the start address of the functions. But the linker does not know where either function ends because of jumps. Since the linker builds the final text section from the text sections of the .o files it links, it has no choice but to include the section containing both alive and dead even though dead is not used. Unless, of course, there is only one function in a section. Certainly one function in one .o file satisfies this. Another solution would be to have the library maintainer compile the library with -ffunction-sections.

[AndyC_772]

Work has Keil Pro. The middleware is great. If you just need to write some embedded code, gcc is fine. I personally don't really see the value proposition though. For 1k you can buy something and be up and running in a day with support. But if you want USB device, or especially host? TCPIP? Just get Keil Pro. Worth every dollar. The middleware is really where it's at.

Is that where the real value is in the more expensive tools, then?

I've been using Rowley for the last year or so, and haven't had cause to think "I wish this tool had feature X". But then again, I'm writing single purpose, embedded code which runs on bare metal.

What I am missing, is the ability to implement higher level functions without considerable effort. For example, a while back I bought an STM32F4 dev board, which can be programmed by plugging it into a USB port and dragging & dropping a firmware file straight to the drive icon which appears on the Windows desktop.

I wouldn't have the first clue where to start implementing a feature like this on my own product. Suggestions?

[imanhp]

I would strongly consider using visulgdb (http://visualgdb.com/) for Visual Studio (uses GCC compiler). Note: I am not affiliated to visualgdb in any way.

Look at these tutorials: http://visualgdb.com/tutorials/arm/stm32/adc/ or http://visualgdb.com/tutorials/

I think (correct me if am wrong) only Keil is the only other debugger that has built in visual graphing of live debug data as a part of the debugger. One of my favorite debugger features.

I recently did a evaluation of all of the current ARM development tools for STMicros and visualgdb+VS came up on top.

Visual Studio is bar none the best IDE for software development. And the VS debugger is very powerful. http://visualgdb.com/debugging/

Debugging in my experience is the most important part of any toolchain. Writing 10k+ lines of code is easy. You spend most of you time trying to figure out what wrong with the code.

We do pretty much all of our development i Visual Studio no matter the target platform today. We do Xamarin C# cross platform apps for tablets/phones, C/C++/C# windows/linux apps and recently we started working with the visualgdb addon for VS for STMicro and Nordic Semi chips. It works like a charm. I literally got started in 5-10 minutes. It installs all of the package for you.

Its not uncommon that our developers make visualization/configuration software for most of the embedded projects that we do. With visualgdb there is no more context switching between different IDEs. I just love it and all of the developers here dropped the other IDEs/tools after giving this a go.

Get it. Try it and hopefully you will like it.

[Brutte]

I would strongly consider using visulgdb (http://visualgdb.com/) for Visual Studio (uses GCC compiler). Note: I am not affiliated to visualgdb in any way.

Sorry, I cannot see how this visualGDB is different from any rawGDB.. I do not have VisualStudio so it is hard to say how it works by just reading their website, anyway - thanks for the links.

First I thought VisualGDB is just a VisualStudio plug-in that prettyfies the semihosted output, displaying hex values as plots.. But now it seems this is a standalone software compiled for specific targets (cortex M, x86, MSP430, ARM11, etc). Does the tool instrument the code actually? If that is the case then it is an intrusive (data) tracing and the tracing available in uVision is non-intrusive thus that is like comparing apples and oranges.
BTW, Atollic TrueStudio (Cortex-M), and STMStudio (STM32) also does non-intrusive tracing.

[technix]

I am not going to use either of them if I have the option. The go-to C/C++ compiler targeting ARM (and x86/amd64 BTW) for me is LLVM/clang. It compiles faster, have better optimization especially link time optimization, and have better debug output.

I have once forced Arduino IDE to use the Apple-supplied version of clang to build code for ATSAM3X8E, another ARM MCU like STM32.

[briselec]

As an addition to my earlier post: A mistake often made is comparing code size results while using GCC with a standard C library inteded for desktop and server applications. The document linked to by Jeroen3 also steps into that trap. If you pair GCC with a small C library (or even a micro-printf) you can create really small code. This is also an area where commercial microcontroller compiler vendors try to make a difference compared to their competitors.

Um, did you actually look at the document - go straight to the conclusions and it states they didn't use printf  with GNU coming out on top in 6 of the 8 tests.

[nctnico]

As an addition to my earlier post: A mistake often made is comparing code size results while using GCC with a standard C library inteded for desktop and server applications. The document linked to by Jeroen3 also steps into that trap. If you pair GCC with a small C library (or even a micro-printf) you can create really small code. This is also an area where commercial microcontroller compiler vendors try to make a difference compared to their competitors.

Um, did you actually look at the document - go straight to the conclusions and it states they didn't use printf  with GNU coming out on top in 6 of the 8 tests.

You mean this document: http://tinyurl.com/nfa2qt5 ?
It's not about printf but the overall size of the library. Just removing printf doesn't remove every part linked in from the C library. You can argue whether a C library is part of a toolchain or not. You can basically bolt any C library onto a toolchain depending on whether you want the most features or reduced code size. In some of my projects I use a barebone printf which compiles to next to nothing in code size.

[jnz]

THREAD UPDATE:

So, I started this thread in May and I've been using Keil Pro for about 2 months now. I can confidently say, if I had selected Clang, or OpenWhatever, or GCC with free tools, there is just not a chance in hell I'd be where I am now. There have been huge challenges learning the new systems, getting to an RTOS, and all the peripherals I'm using. I can easily understand SFRs and datasheets, but it's just faster to learn with the libraries. The middleware so far has been great and "just works" (how often can we get to say that with micros!?). I do understand the limitations with Keil's IDE and some are annoying, but at the end of the day, I chose correctly. It was just too easy to pay the cash and jump ahead. I'm not even close to hitting performance walls, so take that for what it's worth. If I was an needed to optimize, I can go back and start working with SFRs and assembly again.

This is my work tho, and the only thing I actually care about is being able to deliver a working and reliable product. If I was a hobbyist, or mainly a hardware guy, I think my time testing Rowley was great.

Work has Keil Pro. The middleware is great. If you just need to write some embedded code, gcc is fine. I personally don't really see the value proposition though. For 1k you can buy something and be up and running in a day with support. But if you want USB device, or especially host? TCPIP? Just get Keil Pro. Worth every dollar. The middleware is really where it's at.

Is that where the real value is in the more expensive tools, then?

I've been using Rowley for the last year or so, and haven't had cause to think "I wish this tool had feature X". But then again, I'm writing single purpose, embedded code which runs on bare metal.

What I am missing, is the ability to implement higher level functions without considerable effort. For example, a while back I bought an STM32F4 dev board, which can be programmed by plugging it into a USB port and dragging & dropping a firmware file straight to the drive icon which appears on the Windows desktop.

I wouldn't have the first clue where to start implementing a feature like this on my own product. Suggestions?

Flat out, I've been able to integrate USB Host which I had never done before within a month of switching to ARM from Microchip. I'm a one-man team, so I'm pretty pleased with Keil so far. Support could be faster, esp for the price, but I've only needed it once really.

[Jeroen3]

I'm a one-man team,

Than indeed you have not have time to worry and debug the toolchain and open source libraries. Good choice. Is the client/boss also happy with the progress?
They tend to be more cheapskate in terms of buying "non-physical" tools, not sure why. Most likely because the progress is difficult to see.

And most important: did your ulink ever fail?

[jnz]

I'm a one-man team,

Than indeed you have not have time to worry and debug the toolchain and open source libraries. Good choice. Is the client/boss also happy with the progress?
They tend to be more cheapskate in terms of buying "non-physical" tools, not sure why. Most likely because the progress is difficult to see.

And most important: did your ulink ever fail?

Yes, I'm happy   If anyone else at my company even knew what I did they would be happy too. I'm making good progress so, yea, that's all that's important. It wasn't super hard sell, because I pretty much said this is what it'll cost and that's that. I could have saved a few thousand with other options, but no I'm pretty sure I did what was best for everyone. I can imagine it would be an almost impossible sell at a lot of companies though.

Never bought a ulink    I picked up a Segger Ultra+ on day one. There is a slight issue getting that to printf() over ITM, but once that was solved it's been a really great tool so far.

[ilg]

For a fair level of STM32 support, you can also consider the GNU ARM Eclipse http://gnuarmeclipse.github.io project.

It provides not only managed build support for GCC under Eclipse, but also SEGGER J-Link debugging support, ready to run templates for all STM32 families, several STM32 boards emulated in QEMU, etc.

A blinky project tutorial is available from http://gnuarmeclipse.github.io/tutorials/blinky-arm/.

The project is open source and is hosted on GitHub https://github.com/gnuarmeclipse.

[richardman]

I have been bantering our tools over at the epic "5 pages and counting" thread on the for sale forum. Please check it out, there is a large segment between "We love GCC even if it is not free" and "We don't mind paying $8000 for IAR/Keil" and that's the market we are targeting (as long as you don't mind Windows). $99 get you started with complete hardware, software, and even a C reference book.

http://c4everyone.com

[miguelvp]

Does your compiler support all of the STM32 chips? M7, M4F, M3, M0+ & M0?

I don't think the OP ever specified what flavour of the STM32 family he was planning to use.