Author Topic: So how do you even start working with STM32 without paying an arm and a leg?  (Read 32143 times)

0 Members and 1 Guest are viewing this topic.

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Here is the problem: I am trying to move some of my projects to STM32. But despite my best efforts I can not set up a working development environment.

I am NOT willing to touch Keil or IAR as those will cost me an arm, a leg and a kidney, each year. And the free offer with very little optimization and the 32k code size limit makes no sense to me as all dev kits I have found here have at least 64k flash space.

So I am kind of stuck with GCC+OpenOCD stack using J-Link but what is the best IDE/toolchain combo? I tried the Eclipse-based SW4STM32 with and without Cube but it never worked for me - does not create projects under Linux and does not compile under Windows. On Linux I also have NetBeans (that have a working toolchain) but how to get STM32 libraries into there? (in fact I am more happy with GCC toolchain as I can swap out GCC itself for clang/LLVM and that compiler, being an open-source 100% drop-in replacement for GCC, have better optimization and faster compilation time than GCC, and shares a good portion of toolchain with it)

On Windows, how can I hijack the arm-none-eabi-gcc packed with Atmel Studio for SW4STM32 (so it may build?)

My J-Link is known to be good as it can SWD and JTAG program and debug ATSAM3X8E as implemented on Arduino Due.

I have three workstations with three different operating systems: one running Linux (Ubuntu 16.04 LTS amd64 with soft real-time kernel,) one running Windows (Windows 10 amd64) and one MacBook Pro running macOS Sierra.
« Last Edit: August 06, 2016, 11:41:22 am by technix »
 

Offline Dubbie

  • Supporter
  • ****
  • Posts: 1115
  • Country: nz
I really like visualGDB. The visual studio ide tools are really great to have and it works pretty seamlessly with all the arm chips I have tried so far.


Sent from my phone using Tapatalk
 
The following users thanked this post: zzattack

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Trash it and move to NXP LPC
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
I really like visualGDB. The visual studio ide tools are really great to have and it works pretty seamlessly with all the arm chips I have tried so far.


Sent from my phone using Tapatalk
Then how do I get the STM32 dev kit to work there?
 

Offline technixTopic starter

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Trash it and move to NXP LPC
Those chips are more pricey than the STM32s. I can get 48-pin STM32F103 for under one dollar each here from Shenzhen.

In fact my two dev kits are both fairly cheap. The 48-pin STM32F103C8T one cost me two dollars and the 144-pin STM32F103ZET one cost me $15.
« Last Edit: August 06, 2016, 11:32:29 am by technix »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3785
  • Country: de
There are several threads on the forum about this, but documentation and examples are only a google away:

E.g.:
http://fun-tech.se/stm32/index.php
http://vedder.se/2012/04/setup_arm_toolchain/

If you don't want to use the lite Codesourcery toolchain (limited) and don't want to compile your own GCC-based one (not hard, but takes a while), there are plenty of precompiled ones available. E.g. here:
https://launchpad.net/gcc-arm-embedded

You will want a bare metal toolchain - i.e. arm-none-eabi, not arm-linux-eabi or something like that. Don't bother with Clang/llvm - the bare metal ARM toolchains are pretty much non-existent and unsupported. GCC is very much the industry standard.

I have also posted how to use OpenOCD + GDB to debug, check my past posts.

Re IDE - that depends, most people use Eclipse, the SW4ST is also Eclipse based. The second link above shows how to set Eclipse up as well.

I am not sure what you mean by "getting the libraries in there". You just download them, build them using your toolchain (you may have to either add the files to your project, make a library project in Eclipse/Netbeans or prepare your own makefile) and use them as normal. It is normal C programming, nothing special there.

I guess your post is more about how to use Netbeans/Eclipse than really ARM programming.

« Last Edit: August 06, 2016, 12:01:47 pm by janoc »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3785
  • Country: de
Trash it and move to NXP LPC

Very constructive and to the point  :palm:

If he doesn't know how to set up a toolchain and/or debugger, do you think that will be magically resolved by jumping to a different ARM vendor that uses the same tools? Fanboism is really unhelpful.

 
The following users thanked this post: Kilrah, nugglix

Offline MT

  • Super Contributor
  • ***
  • Posts: 1616
  • Country: aq
You download a copy of EMbitz/Blocks, load one of the user examples into your Discovery/Nucleo kit and off you go.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2297
  • Country: gb

If you stick to STM32L0 and F0 you can get the free unlimited Keil MDK.

http://www2.keil.com/stmicroelectronics-stm32/mdk
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
So I am kind of stuck with GCC+OpenOCD stack using J-Link but what is the best IDE/toolchain combo?
Use the ARM-maintained GNU ARM embedded toolchain. If you really want to use an IDE, then the GNU ARM Eclipse plugin is among the easiest to set up. You can use its "packs" interface for downloading vendor support libraries if you need them. The same setup works on Windows, Linux, and OS X.

Quote
(in fact I am more happy with GCC toolchain as I can swap out GCC itself for clang/LLVM and that compiler, being an open-source 100% drop-in replacement for GCC, have better optimization and faster compilation time than GCC, and shares a good portion of toolchain with it)
What is the state of Clang for bare-metal development? Some time ago I saw that someone had managed to compile a hello world for a Cortex-M microcontroller, but their focus is still squarely on code running under a proper OS. Also, in most benchmarks GCC produces slightly better code. IIRC Clang is still a bit faster, but it has slowed down while GCC has sped up. Most of the Clang performance hype is based on Apple's claims, but their benchmarks were comparing their own, severely outdated GCC distribution against then-current versions of Clang.

Quote
On Windows, how can I hijack the arm-none-eabi-gcc packed with Atmel Studio for SW4STM32 (so it may build?)
Just call the compiler binary?

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: us
Trash it and move to NXP LPC

Very constructive and to the point  :palm:

If he doesn't know how to set up a toolchain and/or debugger, do you think that will be magically resolved by jumping to a different ARM vendor that uses the same tools? Fanboism is really unhelpful.

If the LPC (or STM32 for that matter) happen to be mbed compatible, there is no toolchain to install and no platform specific issues either.  Using the web based tools isn't the fastest toolchain but more time is spent typing than compiling by orders of magnitude.

In most cases, it is better to create a Makefile based project and just have the IDE invoke 'make'.  Whatever and whereever the tools and libraries may be, the Makefile deals with it.  Even Microsoft Visual Studio will handle Makefile projects for non-Microsoft toolchains.

I think the mbed compatible boards are going to cost a bit more than $2 - by an order of magnitude.  Somehow, that has never been my concern.  I'm only buying one, it doesn't matter what it costs.

 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Trash it and move to NXP LPC

Very constructive and to the point  :palm:

If he doesn't know how to set up a toolchain and/or debugger, do you think that will be magically resolved by jumping to a different ARM vendor that uses the same tools? Fanboism is really unhelpful.
Lpcxpresso installation is very easy. A single package install that includes the tool chain and ide. Works on Linux, Mac and Windows. When I switched to arm (for hobby) I first tried STM and then moved to NXP because of the free tools.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26891
  • Country: nl
    • NCT Developments
Trash it and move to NXP LPC
Those chips are more pricey than the STM32s. I can get 48-pin STM32F103 for under one dollar each here from Shenzhen.

In fact my two dev kits are both fairly cheap. The 48-pin STM32F103C8T one cost me two dollars and the 144-pin STM32F103ZET one cost me $15.
But look how far going for the cheapest option got you! The easy way out is to find some kind of free IDE + compiler package. LPCexpresso and mbed where already mentioned.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline OZ1LQB

  • Regular Contributor
  • *
  • Posts: 51
  • Country: dk
Hi.
technix i use atollic it is free and works fine for me
both ide compile and debug
 

Offline Tainer

  • Contributor
  • Posts: 37
  • Country: 00
On Linux I also have NetBeans (that have a working toolchain) but how to get STM32 libraries into there?
Pretty much the same way you link any other libraries. I'm also using netbeans. The only thing I miss is a plugin to display and manipulate port/registers during debug. I switched to libopncm3 some time ago and since then never bothered with Cube and other ST rubbish.
 

Offline veryevil

  • Supporter
  • ****
  • Posts: 221
  • Country: gb
I really rate Atollic as it's free and doesn't have code limit. Also based on eclipse so really easy to use
 

Offline Skashkash

  • Regular Contributor
  • *
  • Posts: 118
  • Country: us
Another possible bundled eclipse/gcc/openocd/gdb option might be chibistudio.

 Sounds a little weird.  But  it is a complete arm dev setup. Lots of chibios and non stm32 examples are included  by default.  But you could just ignore all those.


And if you ever wanted to experiment with an RTOS  chibios has some pretty extensive stm32 support complete with hw drivers.     

https://sourceforge.net/projects/chibios/files/ChibiStudio/
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Trash it and move to NXP LPC

Very constructive and to the point  :palm:

If he doesn't know how to set up a toolchain and/or debugger, do you think that will be magically resolved by jumping to a different ARM vendor that uses the same tools? Fanboism is really unhelpful.


it is if you stop for a moment and think about it. NXP gives you its IDE which is a self cointaned custom eclipse installation with everything already inside it.

so you just download, install and start coding.

the HAL is also easier to read use and understand, to me at least, and it is also integrated in the MCU reference manual, unlike ST which has a number of different files scattered across the internet, everyone with unique information that you won't find in the other
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Do we really need an exact repeat of this thread every week?  :palm:
 
The following users thanked this post: bingo600, Frank, RogerRowland, nugglix

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
This seems like more of a "how do I get all the vendor libraries in appropriate places and come up with a standard scheme for organizing a project?", than the usual "where do I get a free compiler?" or "which IDE is "best?" questions we usually see.

And it's complicated, which is a good reason that people spend $10k/year to own a "real" environment.  (that's 1/10th the cost of your $100k star programmer, who otherwise might have spent 10% of their time maintaining the environment.  (On the flip side, even pro environments are not "free" to maintain.))

It might be easiest to install one of the "limited size" tools, and replace whatever component is limiting the size with an OSSW version that doesn't have the limit (gcc-ld?)  That probably violates the license agreement, though...
 
The following users thanked this post: Kilrah

Offline ez24

  • Super Contributor
  • ***
  • Posts: 3082
  • Country: us
  • L.D.A.
Do we really need an exact repeat of this thread every week?  :palm:
I think it would get a better audience if once a day.
YouTube and Website Electronic Resources ------>  https://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline aandrew

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: ca
Trash it and move to NXP LPC

This kind of comment is worse than useless. What exactly would an NXP ARM give him that an ST ARM wouldn't? He's asking for development environment help and by and large that is all completely agnostic to the specific "brand" of part used.  ARM from NXP or ST or Freescale or Nuvoton or Cypress or *anyone* is pretty much the same when it comes to IDE.

That all being off my chest now, I have always preferred the good old command line. vim or Sublime Text for my editor, and gdb (not graphical) for debugging. I've always ended up fighting more with the damned GUI tools than the problem at hand when I've had to use anything Eclipse based, and the various code generators such as Processor (cough)Expert or STM32CubeMX have always been poor at best.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26891
  • Country: nl
    • NCT Developments
Trash it and move to NXP LPC

This kind of comment is worse than useless. What exactly would an NXP ARM give him that an ST ARM wouldn't? He's asking for development environment help and by and large that is all completely agnostic to the specific "brand" of part used.  ARM from NXP or ST or Freescale or Nuvoton or Cypress or *anyone* is pretty much the same when it comes to IDE.
IF (big if ) you know how to setup the compiler, libraries, include files and (if you want) the debugger. At some point you need to know this anyway so  it doesn't hurt to learn it from the start. But if you want a have a pre-packaged point&click environment to have a blinky running in 5 minutes then the pre-packaged systems vary between vendors and they all try to make it easy while keeping costs down (which ofcourse doesn't work).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Trash it and move to NXP LPC

This kind of comment is worse than useless. What exactly would an NXP ARM give him that an ST ARM wouldn't? He's asking for development environment help and by and large that is all completely agnostic to the specific "brand" of part used.  ARM from NXP or ST or Freescale or Nuvoton or Cypress or *anyone* is pretty much the same when it comes to IDE.
IF (big if ) you know how to setup the compiler, libraries, include files and (if you want) the debugger. At some point you need to know this anyway so  it doesn't hurt to learn it from the start. ...

Even if you know, releasing an open source project fit example that requires complex setup greatly reduces its accessibility.

The difficulty and cost of setting the environment is one of the factors that affects project's value.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26891
  • Country: nl
    • NCT Developments
Trash it and move to NXP LPC

This kind of comment is worse than useless. What exactly would an NXP ARM give him that an ST ARM wouldn't? He's asking for development environment help and by and large that is all completely agnostic to the specific "brand" of part used.  ARM from NXP or ST or Freescale or Nuvoton or Cypress or *anyone* is pretty much the same when it comes to IDE.
IF (big if ) you know how to setup the compiler, libraries, include files and (if you want) the debugger. At some point you need to know this anyway so  it doesn't hurt to learn it from the start. ...
Even if you know, releasing an open source project fit example that requires complex setup greatly reduces its accessibility.

The difficulty and cost of setting the environment is one of the factors that affects project's value.
As Rstofer wrote several times: A Makefile project is as universal as it gets and many IDEs 'import' these just fine.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf