Toolchains and ARM land - Page 1
Forum section: electronics / general

author: jimon
author_rank: Regular Contributor
timestamp: February 26, 2015, 09:24:15 pm
content: 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 ledI 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 ?

author: Brutte
author_rank: Frequent Contributor
timestamp: February 26, 2015, 09:51:39 pm
content: Quote from: jimon on February 26, 2015, 09:24:15 pmYet 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  or Coocox ).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.

author: jimon
author_rank: Regular Contributor
timestamp: February 26, 2015, 10:12:22 pm
content: Quote from: Brutte on February 26, 2015, 09:51:39 pmI 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 ofhttp://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.

author: jimon
author_rank: Regular Contributor
timestamp: February 26, 2015, 10:24:07 pm
content: Ok, looks like STM32CubeF4Embedded package have everything that is needed, like "stm32f407xx.h".Anything else I'm missing ?

author: Brutte
author_rank: Frequent Contributor
timestamp: February 26, 2015, 10:36:15 pm
content: Quote from: jimon on February 26, 2015, 10:12:22 pmIt is an overkill. You should have picked a basic Cortex M3 (STM32L1xx or STM32F1xx) for a first shot.Quote from: jimon on February 26, 2015, 10:12:22 pmand also describes at which physical address this register is located, which bit enables which mode etc..Quote from: jimon on February 26, 2015, 10:12:22 pmThe 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 provideanymeans 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).Quote from: jimon on February 26, 2015, 10:12:22 pmFirst walk, then run.Start from a one-click IDE.

author: Lukas
author_rank: Frequent Contributor
timestamp: February 26, 2015, 10:53:49 pm
content: Quote from: jimon on February 26, 2015, 10:12:22 pmThen you may want to take a look at thishttps://github.com/carrotIndustries/stm32-templateexample project I set up some time ago. There are also many other makefiles floating around...

author: jimon
author_rank: Regular Contributor
timestamp: February 26, 2015, 11:00:33 pm
content: Quote from: Lukas on February 26, 2015, 10:53:49 pmLooks exactly what I need, awesome, thank you !

author: dannyf
author_rank: Super Contributor
timestamp: February 26, 2015, 11:03:06 pm
content: 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.

author: langwadt
author_rank: Super Contributor
timestamp: February 26, 2015, 11:47:36 pm
content: Quote from: jimon on February 26, 2015, 09:24:15 pmdownload GCC and the Coocox IDE and you are good to go

author: westfw
author_rank: Super Contributor
timestamp: February 27, 2015, 02:33:50 am
content: 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 :-(

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 27, 2015, 05:40:24 am
content: 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.

author: Psi
author_rank: Super Contributor
timestamp: February 27, 2015, 07:02:24 am
content: 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.

author: photon
author_rank: Frequent Contributor
timestamp: February 27, 2015, 07:22:18 am
content: Quote from: westfw on February 27, 2015, 02:33:50 amAgreed. 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 27, 2015, 08:23:14 am
content: Quote from: photon on February 27, 2015, 07:22:18 amAt 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.

author: westfw
author_rank: Super Contributor
timestamp: February 27, 2015, 09:19:12 am
content: QuoteThe 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?)

author: jimon
author_rank: Regular Contributor
timestamp: February 27, 2015, 10:19:35 am
content: Quote from: westfw on February 27, 2015, 09:19:12 amLooks like this is called vendor lock-inAt 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

author: dannyf
author_rank: Super Contributor
timestamp: February 27, 2015, 11:42:25 am
content: QuoteYou can spend your time on those philosophical discussions,or actually learning about your chip / board.

author: Brutte
author_rank: Frequent Contributor
timestamp: February 27, 2015, 02:42:49 pm
content: Quote from: westfw on February 27, 2015, 09:19:12 amWrong

author: westfw
author_rank: Super Contributor
timestamp: February 27, 2015, 05:12:25 pm
content: QuoteWhich part is wrong?According to the tutorial here:http://www.doulos.com/content/events/CMSIS3.phpCMSIS 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)

author: Jeroen3
author_rank: Super Contributor
timestamp: February 27, 2015, 08:01:24 pm
content: 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.

author: langwadt
author_rank: Super Contributor
timestamp: February 28, 2015, 01:15:48 am
content: Quote from: Jeroen3 on February 27, 2015, 08:01:24 pmthey 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 ofoverhead in abstraction layers

author: nctnico
author_rank: Super Contributor
timestamp: February 28, 2015, 07:32:47 am
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: March 02, 2015, 01:47:50 pm
content: CooCox

author: v
author_rank: Newbie
timestamp: March 06, 2015, 03:48:51 pm
content: 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.

author: Christopher
author_rank: Frequent Contributor
timestamp: March 06, 2015, 05:14:15 pm
content: I use freescale CodeWarrior (eclipse based) on Kinetis microcontrollers. Can recommend it! Comes with a lot of sample code & cheap dev board (FRDM-KL25Z)

author: dannyf
author_rank: Super Contributor
timestamp: March 06, 2015, 06:19:04 pm
content: QuoteGoogle KDS.

author: jimon
author_rank: Regular Contributor
timestamp: March 06, 2015, 09:16:45 pm
content: Quote from: v on March 06, 2015, 03:48:51 pmCan't really stand anything java/eclipse related, just principles.Another experiences :Apple iOS development, same arm-compatible chips, free toolset, good debugger ... well I also hate xcode, but it's another storyWindows phone development, same arm-compatible chips, free toolset, great debugger ... and MSVSAndroid development, same arm-compatible chips, free toolset, PAY FOR NATIVE DEBUGGING to Nvidia, or go die with VisualGDBWonder why embedded is so "different"We could have arm development in MSVS and that's it .. but instead people in embedded-releted companies are trying to develop "best text editor of all times" .. that's not even their field of businessI mean vim is there, emacs is there, notepad++ is there, "Not invented here" syndrome is studied and well known, what's wrong with them then ?

author: nctnico
author_rank: Super Contributor
timestamp: March 06, 2015, 09:49:44 pm
content: IMHO non Eclipse vendor IDEs are just bodges to lure in newbies with beads and mirrors. Those IDEs are not suitable or intended for any real work.

author: dannyf
author_rank: Super Contributor
timestamp: March 06, 2015, 10:23:13 pm
content: QuoteI think if you look at the whole market, overwhelming majority uses Keil / IAR.QuoteI would disagree: Keil / IAR have fairly basic / utilitarian editors and I like them very much.QuoteWhat editor is "best" is highly subjective - SI or Sublime would be my choices, not vim/emacs.I think you find eclipse "dominant" mostly due to selection biases.