Toolchains and ARM land

[jimon]

So I have little fancy STM32F4 discovery board. And I have a question - what's actually happening in toolchain world ?

STM32F4 board is comes with STM32F407VGT6 chip, ok so it's Cortex-M4F MCU, which is ARMV7E-M architecture and instruction set, which is super set of ARMV7. So GCC and Clang/LLVM can compile to ARMV7. So I can download GCC or Clang/LLVM right now and generate code for ARMV7. This is what I do for AVR platform. But to use chip modules one need libraries, and this libraries and compiler are called toolchain.

I've looked at Keil MDK, they provide RTOS, for God's sake .. I don't need RTOS with HAL to blink a led I just want to gain some control on my life and bitbang this pin.

So I've found fancy GNU Tools for ARM Embedded Processors ( https://launchpad.net/gcc-arm-embedded ) And probably this is what I need, but what's about chip modules - how actually use them ? Should I just copypaste lib's from Keil MDK ?

PS. What is general feeling in ARM land ? Do people just use RTOS's as no brainer ?

[Brutte]

So I have little fancy STM32F4 discovery board. And I have a question - what's actually happening in toolchain world ?

Yet another guy making first steps with the biggest Cortex-M available on the market. Are you aware that TFRM0090 is 1400 pages long?

As for the choice of the toolchain to start with - that greatly depends on your make-fu. If you do not know what make is then pick a one-click IDE (uVision [32kB] or Coocox [free]).

Libraries: There are numerous peripheral libraries available for this jumbo. Start from the one provided by STM on their website. It is well documented and quite portable within family.

[jimon]

So I have little fancy STM32F4 discovery board. And I have a question - what's actually happening in toolchain world ?

Yet another guy making first steps with the biggest Cortex-M available on the market. Are you aware that TFRM0090 is 1400 pages long?

As for the choice of the toolchain to start with - that greatly depends on your make-fu. If you do not know what make is then pick a one-click IDE (uVision [32kB] or Coocox [free]).

Libraries: There are numerous peripheral libraries available for this jumbo. Start from the one provided by STM on their website. It is well documented and quite portable within family.

I haven't really thought it through, just this board was 14 euro on ebay, maybe it's a bit overkill for new starter.

Well, 1400 pages is ok, (I've read 1400+ pages of C++11 standard as part of http://www.cppgm.org/, and part's of intel software developer manuals, 6k+ pages, so it's ok). So this 1400 page doc says that there are "ADC_SR" (ADC status register). I have bare GCC ARM toolchain ( https://launchpad.net/gcc-arm-embedded ), there are no mention of this register anywhere in this toolchain, so how it gonna work exactly ?

My make-fu skills are good enough, I want to use Qt Creator and ninja build system for that one, so I just need GCC/Clang to compile code for me, and objcopy to strip.

[jimon]

Ok, looks like STM32CubeF4Embedded package have everything that is needed, like "stm32f407xx.h".

Anything else I'm missing ?

[Brutte]

I haven't really thought it through, just this board was 14 euro on ebay, maybe it's a bit overkill for new starter.

It is an overkill. You should have picked a basic Cortex M3 (STM32L1xx or STM32F1xx) for a first shot.

So this 1400 page doc says that there are "ADC_SR" (ADC status register).

and also describes at which physical address this register is located, which bit enables which mode etc..

I have bare GCC ARM toolchain ( https://launchpad.net/gcc-arm-embedded ), there are no mention of this register anywhere in this toolchain, so how it gonna work exactly ?

The toolchain only services the core (13 registers, ALU, FPU, stack, etc), core peripherals (NVIC, MPU, SysTick etc) and that would be it.
It does not provide any means for servicing vendor's peripherals (clock tree with PLLs, memories, timers, IOs, etc). That is why some code for vendor's peripherals is needed (based on RM0090 in case of your jumbo).

My make-fu skills are good enough, I want to use Qt Creator and ninja build system for that one, so I just need GCC/Clang to compile code for me, and objcopy to strip.

First walk, then run.
Start from a one-click IDE.

[Lukas]

My make-fu skills are good enough, I want to use Qt Creator and ninja build system for that one, so I just need GCC/Clang to compile code for me, and objcopy to strip.

Then you may want to take a look at this https://github.com/carrotIndustries/stm32-template example project I set up some time ago. There are also many other makefiles floating around...

[jimon]

My make-fu skills are good enough, I want to use Qt Creator and ninja build system for that one, so I just need GCC/Clang to compile code for me, and objcopy to strip.

Then you may want to take a look at this https://github.com/carrotIndustries/stm32-template example project I set up some time ago. There are also many other makefiles floating around...

Looks exactly what I need, awesome, thank you !

[dannyf]

You can bitbang a pin easily on pretty much any platform, with or without a library. I would suggest that you start with something you are comfortable with, Keil / CoIDE are both good starting point.

Then read the datasheet and you are done.

[langwadt]

So I have little fancy STM32F4 discovery board. And I have a question - what's actually happening in toolchain world ?

STM32F4 board is comes with STM32F407VGT6 chip, ok so it's Cortex-M4F MCU, which is ARMV7E-M architecture and instruction set, which is super set of ARMV7. So GCC and Clang/LLVM can compile to ARMV7. So I can download GCC or Clang/LLVM right now and generate code for ARMV7. This is what I do for AVR platform. But to use chip modules one need libraries, and this libraries and compiler are called toolchain.

I've looked at Keil MDK, they provide RTOS, for God's sake .. I don't need RTOS with HAL to blink a led I just want to gain some control on my life and bitbang this pin.

So I've found fancy GNU Tools for ARM Embedded Processors ( https://launchpad.net/gcc-arm-embedded ) And probably this is what I need, but what's about chip modules - how actually use them ? Should I just copypaste lib's from Keil MDK ?

PS. What is general feeling in ARM land ? Do people just use RTOS's as no brainer ?

download GCC and the Coocox IDE and you are good to go

[westfw]

For STM32 you have a bunch of choices.
Keil - you don't have to use the RTOS; they have more primitive functions as well.
CCA - ditto.
Imagecraft - a cheaper commercial compiler.
MBed - an "easy, web-based" IDE and set of libraries.
assorted gcc "packages" like CooCox.

In any case, there are several parts:
Compiler - trivial (as you said.)  ARM is ARM.
Per-chip definitions. (.h files that define the peripheral addresses and all their bits and stuff.)  Sometimes considered part of CMSIS support.
per-chip hw-specific libraries.  for talking to all those peripherals without having to understand the low-level HW details.  (These are of somewhat questionable value, IMO.)  ST has at least two of these - the "Standard Peripheral Libraries" and the (new) MCube HAL libraries.  The commercial compilers may have their own.  I'm not sure if MBed has its own, or whether it uses one of the other ST libraries.  There's an arduino-compatible set of functions for at least STM32f1xx (somewhat "in progress.")
libc-level libraries - (printf, strchr, and all that.  SW floating point.  Support of the compiler abstraction for HW floating point.  Etc.)  Aside from the commercial code, "newlib" and "newlib-nano" are popular.

It might be worth a couple thousand dollars for a commercial compiler, just to avoid the "churn" in the open source world :-(

[Sal Ammoniac]

Check out Rowley CrossWorks as well. Not free, but they do have a $150 personal license for hobbyists. CrossWorks is not Eclipse-based so it tends to be faster than many of the alternatives.

[Psi]

Em:Blocks is free and works great with the STM32 discovery kits.
Install, select the board, code/debug.

It uses gcc compiler so its unrestricted and can be used for commercial work.

[photon]

It might be worth a couple thousand dollars for a commercial compiler, just to avoid the "churn" in the open source world :-(

Agreed. But if you have the time, learning a GNU toolchain, while time consuming and challenging, will teach you a depth of knowledge of the hardware that provides more insight than a closed IDE without sources can.

[nctnico]

It might be worth a couple thousand dollars for a commercial compiler, just to avoid the "churn" in the open source world :-(

Agreed. But if you have the time, learning a GNU toolchain, while time consuming and challenging, will teach you a depth of knowledge of the hardware that provides more insight than a closed IDE without sources can.

At some point you'll have to dig into the toolchain either way because the 'point&click' IDE won't do what you want sooner or later. So learning GCC & tools is worth the effort because they offer the widest coverage of platforms. IMHO one of the things people don't seem to learn in school is what a C compiler actually does and how it does that. A lot is obfustigated by compiled in include & library paths and automatic selection of linker scripts.

[westfw]

It might be worth ... to avoid the "churn" in the open source world :-(

Agreed. But if you have the time, learning a GNU toolchain [might be worthwhile.]

The Gnu part isn't bad.  The vendor libraries (actually, I'm not sure that those qualify as open source) are my primary complaint.  Not just that STMCube HAL is replacing STM SPL, but that there is so little consistency from one vendor to another.  Do you realize that the closest thing to a standard multi-vendor microcontroller peripheral library is probably the Arduino core and libraries?  I mean: I happen to like Arduino OK, but that's pretty AWFUL!  (CMSIS was supposed to include a HAL layer for peripherals, but that was mostly abandoned, right?)

[jimon]

It might be worth ... to avoid the "churn" in the open source world :-(

Agreed. But if you have the time, learning a GNU toolchain [might be worthwhile.]

The Gnu part isn't bad.  The vendor libraries (actually, I'm not sure that those qualify as open source) are my primary complaint.  Not just that STMCube HAL is replacing STM SPL, but that there is so little consistency from one vendor to another.  Do you realize that the closest thing to a standard multi-vendor microcontroller peripheral library is probably the Arduino core and libraries?  I mean: I happen to like Arduino OK, but that's pretty AWFUL!  (CMSIS was supposed to include a HAL layer for peripherals, but that was mostly abandoned, right?)

Looks like this is called vendor lock-in

At least this people agreed on ARM EABI (Guess what, C++ ABI is not here yet even in x86/x64 world ) And it's so annoying that ARM do so little for development infrastructure, Apple spend enormous amount of man years to build clang/llvm, and it gonna rule them all in near future, GCC is dying in x86/x64 world. But ARM and other's just don't care, hardware is nothing without software, and software is nothing without hardware

[dannyf]

Looks like this is called vendor lock-in .....

You can spend your time on those philosophical discussions,

or actually learning about your chip / board.

[Brutte]

CMSIS was supposed to include a HAL layer for peripherals, but that was mostly abandoned, right?

Wrong

[westfw]

CMSIS was supposed to include a HAL layer for peripherals, but that was mostly abandoned, right?

Wrong

Which part is wrong?
According to the tutorial here: http://www.doulos.com/content/events/CMSIS3.php
CMSIS 1.0 included a "Device Peripheral Access Layer" and a "Middleware Access Layer", both of which were removed in CMSIS 2.0.
(The core peripheral access remains)

[Jeroen3]

Standardizing peripheral access will make the market boring. Vendors will use shelf-IP's instead of designing their own competitive peripherals.
They will only compete in price, energy and package size.

[langwadt]

Standardizing peripheral access will make the market boring. Vendors will use shelf-IP's instead of designing their own competitive peripherals.
They will only compete in price, energy and package size.

they already use some of the shelf peripherals, but limiting the cmsis to core peripherals make sense in that is should make it reasonable easy to get an OS running, but doesn't add a lot of 
overhead in abstraction layers

[nctnico]

IMHO CMSIS is nice for clock setup and dealing with the interrupt controller. Simple vendor specific peripherals are easy enough to deal with from standard code and the more complex peripherals (like USB, ethernet, etc) differ too much to create a sensible API without including an entire USB, network stack, etc.

[poorchava]

CooCox 

[v]

I would have a look at mBed - they have a good Arduino-style API with well written libraries to interface with a variety of board.

If you need to go deeper, and you are using ST, beware, the [ST ecosystem is terrible](https://www.eevblog.com/forum/microcontrollers/st's-(stm32cube)-software-ecosystem-is-terrible-how-can-we-fix-it/). But if you must...

I work in Eclipse with the GNU ARM Plugin, and OpenOCD as the debugger (its built into the plugin).

It was painful to setup like you wouldn't imagine, but once it works, it works. I generally dislike Eclipse. I am a *huge* JetBrains fan and use IntelliJ (and a little Sublime) for all other development. I wish CLion had a community version that we could make an embedded dev environment for. Best text-editor, refactorings, editor performance, diff tool, etc.

However, Eclipse feels amazing when you look at the other "industry-standard" IDEs for ARM development. I cannot stand Keil and IAR. They have such terrible editors I don't know how anyone writes well structured code, or refactors, or uses version control effectively.

To work productively I need: keyboard shortcuts to jump to files and symbols; find usages/call hierarchy; include browser; code style/smart-indent; file navigator linked to file system (none of these virtual files that get out of sync); auto-complete; ctrl-click code navigation; find text in files; refactorings; extract methods/variables shortcuts; local history; vcs integration; plugins.

I don't think this is unreasonable to expect a decent editor from these $4000 IDEs, but I think its very important to have good debugging features which are only available at these kind of price points. You will suffer one way or the other in ST.

CrossWorks has a big fan base on the usual forums, is cheap, and works pretty smooth for setup, flashing, debugging, but its editor doesn't have ctrl-click navigation and is pretty weak.

[Christopher]

I use freescale CodeWarrior (eclipse based) on Kinetis microcontrollers. Can recommend it! Comes with a lot of sample code & cheap dev board (FRDM-KL25Z)