Author Topic: EEVblog #900 - STM32 ARM Development Board  (Read 21821 times)

0 Members and 1 Guest are viewing this topic.

Online EEVblog

  • Administrator
  • *****
  • Posts: 25866
  • Country: au
    • EEVblog
EEVblog #900 - STM32 ARM Development Board
« on: July 14, 2016, 09:41:46 am »
Dave takes a look at the ST STM32 L1 series low power ARM chips, and gets a cheap STM32L152C development board up and running with the IAR Embedded workbench compiler and STLINK/V2 interface.
Also a look at the STMcubeMX code initialisation application.

http://amzn.to/29CrU47
32L152CDISCOVERY  http://bit.ly/29wtzqH
Schematic & User Manual: http://bit.ly/2aaEXWo

PIC32MX: http://www.microchip.com/wwwproducts/en/PIC32MX320F128L

 
The following users thanked this post: jancumps, AF6LJ, OldTechUK

Offline vlad777

  • Frequent Contributor
  • **
  • Posts: 283
  • Country: 00
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #1 on: July 14, 2016, 10:23:03 am »
Is this it ?

GNU Tools for ARM Embedded Processors

https://launchpad.net/gcc-arm-embedded/

Mind over matter. Pain over mind. Boss over pain.
-------------------------
Please check out my YouTube channel: http://www.youtube.com/user/vlad7181  It's about electronics, programming and math
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11000
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #2 on: July 14, 2016, 10:28:48 am »
EWARM is nice but don't get too used to it unless you have a few K to spend on the full version once you need more code space.
Not sure if it's current but Future are showing $3395 for "baseline", which is up to  256K code.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: 00
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #3 on: July 14, 2016, 12:16:32 pm »
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: 00
 

Offline boffin

  • Supporter
  • ****
  • Posts: 567
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #5 on: July 14, 2016, 01:37:28 pm »
Thanks for the video Dave, interesting to watch.

I note you're a big fan of opening new tabs, and wanted to point out that holding down CTRL while clicking a link does the same thing as rightclick and selecting "open in new window"

Ooh, and almost forgot to ask, what software are you using for the multi source screen capture? It seems to work really well.

 

Offline vlad777

  • Frequent Contributor
  • **
  • Posts: 283
  • Country: 00
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #6 on: July 14, 2016, 01:44:09 pm »
Thanks for the video Dave, interesting to watch.

I note you're a big fan of opening new tabs, and wanted to point out that holding down CTRL while clicking a link does the same thing as rightclick and selecting "open in new window"

Ooh, and almost forgot to ask, what software are you using for the multi source screen capture? It seems to work really well.

Center click (mouse 3) on the link opens it in new tab also.
Mind over matter. Pain over mind. Boss over pain.
-------------------------
Please check out my YouTube channel: http://www.youtube.com/user/vlad7181  It's about electronics, programming and math
 
The following users thanked this post: ebclr

Offline Hemogloben

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #7 on: July 14, 2016, 01:57:56 pm »
Atollic TrueSTUDIO is an Eclipse based GCC dev environment.  I'm unwilling to go back and find the exact timestamp but the first document that mentioned GCC specifically mentioned Atollic TrueSTUDIO as the supported platform, Dave just didn't read the full line.

STCube only directly supports GCC via Atollic TrueSTUDIO, ie the only GCC version you get a proj file for is TrueSTUDIO.  I suspect this is because TrueSTUDIO is a simple installer whereas any eclipse cdt environment requires multiple installs and configs (even though GNU ARM Eclipse is a totally awesome effort).  Nice things about TrueSTUDIO include an unlimited version for even commercial development.  Pro / paid version has features that even include features that GNU ARM Eclipse don't include: Live variables, ITM console support / profiling, ETB support etc.

Not a shill; got a job at a new company and had to evaluate EVERY major Embedded IDE and I found TrueSTUDIO the most cost effective and laughed at Dave running into every major confusion I had.

Aside quick reviews of major tool chains:
  • Keil: Great config, probably great compiler.  Great debug support.  Editor sucks.
  • Crossworks: Beautiful editor with fantastic configuration screen. Okay editor.  Lacking Debug support.
  • IAR: Editor sucks.  Great everything else.  Too damn expensive.
  • TrueSTUDIO: Great compromise for the company I work for.  They recently changed corporate strategy and seem to be in flux; bit of a risk but they have many debug features and their free version is awesome.  Plus it's based on eclipse so tons of plugins.
  • Eclipse + GNU ARM Eclipse: Really tolerable environment.  Used it for 1.5 years before TrueSTUDIO.  Free and many plugins tools to help / fix problems.  Only issue is lack of advanced debug features and the fact that Liviu is likely stretched thin.

FINAL EDIT: We were looking for cross vendor ARM Cortex-M solutions so I didn't check out any vendor specific IDEs though SIlabs Simplicity and NXP both seem like feature-full options if you're willing to lock-in.
« Last Edit: July 14, 2016, 02:02:56 pm by Hemogloben »
 
The following users thanked this post: bitwelder


Offline jesuscf

  • Regular Contributor
  • *
  • Posts: 120
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #9 on: July 14, 2016, 02:25:51 pm »
Great video!

Very recently (like five days ago) I went to the very same process for the NXP LPC824 (ARM Cortex-M0).  Very quickly I got frustrated with LPCXpresso for exactly the same reasons as Dave in the video;  and that makes me feel less stupid!  One question for NXP: why do I have to register with you in order to use the GCC and Eclipse included with LPCXpresso?  Aren't those two supposed to be free and open?  Anyhow, I ditched LPCXpresso and went old school with GCC,  makefiles, and linker scripts.  It took me a couple of days to do what I wanted to do.  I used GCC from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads.   Now I want to do the same for the STM32F051 or a similar processor with comparable price and package options.
Homer: Kids, there's three ways to do things; the right way, the wrong way and the Max Power way!
Bart: Isn't that the wrong way?
Homer: Yeah, but faster!
 


Offline calin

  • Regular Contributor
  • *
  • Posts: 209
  • Country: us
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #11 on: July 14, 2016, 02:41:58 pm »
Here .. the real ARM GCC for Cortex M - officially supported by ARM https://launchpad.net/gcc-arm-embedded

[/size]You can always grab Eclipse IDE for C/C++ from here - http://www.eclipse.org/downloads/eclipse-packages

If you want you can install Eclipse Arm Plugin from here - http://gnuarmeclipse.github.io/ and have projects managed by eclipse. [/font]

These do rally give you a full complete C/C++ dev environment with HW debugging options and all. There are literally hundreds of plugins for Eclipse, What to use .. depends what you like. Now one word of advice, you want to be on your own feet, DO NOT RELY ON THE IDE .. real developers use make and control how the project is built, organized, compiler options etc. IDE is good for editing and visual stuff and can be used in parallel with your own make. Trust me .. is frustrating at the beginning to set your project build process but it will pay for your efforts then times what you invest.


BTW .. the GCC is slow is utter FUD and bull$#^ sold by guys like IAR and other "compiler vendors". They sell snake oil. Yes there are differences in code size, instruction order etc but no compiler is king @ everything. There are areas where on compiler gens marginally better code and is beaten in other hands down. There is no clear winner when you compare them - if you manage to get in that area where the compiler do really matter you are either really f-ing good @ this or have gone mad :) I still have to find one project in 20 years of career where the compiler is an issue for speed .. 99.99999999 % is the bad programmer :)

 

Offline gnasirator

  • Contributor
  • Posts: 23
  • Country: nz
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #12 on: July 14, 2016, 04:40:49 pm »
STM32 = Use TrueStudio!

I'm actually working designing µC PCBs and programming them using TrueStudio in the free version and it's great. No registration required, simply download and it's an eclipse based environment so supports standard plugins and the usual code navigation I love so much about eclipse. You can even get CubeMX as a plugin to run it inside TrueStudio :)

So yes, I'm a big fanboy of the CubeMX + TrueStudio combo!
Btw, the included FreeRTOS is awesome, too (freertos.org) and works a treat!

The Pro version offers some advanced features for debugging and code analysis but I've never needed any of those. Might come in handy for larger RTOS based firmwares.
Only downside to TrueStudio is that there is no (default) download and run button. All you an do is download and debug, so you have to stop debugging right away if you only want to download.
There is a way to fix it, though. Just let me know if you're interested.

So Dave (or anyone else), if you want to make your life easier, just use TrueStudio for your project :)
« Last Edit: July 14, 2016, 04:49:08 pm by gnasirator »
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2010
  • Country: au
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #13 on: July 14, 2016, 07:04:35 pm »
Btw, never despair when you encounter a 404. Just go to www.archive.org. I took the link from digikey, pasted it into the WayBackMachine at www.archive.org, and I got back the ZIP file containing the schematic as a PDF (which looks the same as the links already posted), plus original Altium .SchDoc files.
 

Offline Quarlo Klobrigney

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: us
  • Mild Mannered Time Traveller... Stuck In Forward
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #14 on: July 14, 2016, 08:47:37 pm »
Dave, I must concur, use Eclipse (yes I said Eclipse) with GCC as per Carmine's excellent starter book Mastering STM32 linked somewhere here. I suggest reading it as an eye (and mind) opener. I'm not a shill, but a guy who was banging his head to understand the architecture, trying every compiler - tutorial - video how to, etc. before "the book". Thanks Carmine and keep up the good work :-+.
Voltage, does not flow, nor does it go.
 

Offline iromero

  • Supporter
  • ****
  • Posts: 26
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #15 on: July 14, 2016, 10:02:54 pm »
For STM32 development i use SW4STM32 with STM32Cube, it does work pretty well (though the code generated by cube is really ugly). One thing I'd like is that stm32cube didn't generate main.c and let me just call their functions instead, so that i don't need to edit generated files, and so that regenerating from the cube does not (potentially) clobber my stuff and introduce a lot of changes for git.
 
The following users thanked this post: rs20

Offline invzim

  • Contributor
  • Posts: 15
  • Country: 00
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #16 on: July 15, 2016, 01:14:54 am »
Great video!  Got a couple of discovery boards a couple of years back, and they have been living in a drawer since as I got totally confused about which IDE/compiler to use, where to get it and how to set it up.  At that point I think the cube stuff didn't support GCC - which it does now?

 

Offline Tantalum

  • Contributor
  • Posts: 15
  • Country: lu
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #17 on: July 15, 2016, 01:21:22 am »
Well the L1 series is quiet "old".

The new L4 series (M4) is much more powerful, and much more power efficient (~100µA/MHz vs 240µA/MHz).
 

Offline iromero

  • Supporter
  • ****
  • Posts: 26
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #18 on: July 15, 2016, 01:40:37 am »
Great video!  Got a couple of discovery boards a couple of years back, and they have been living in a drawer since as I got totally confused about which IDE/compiler to use, where to get it and how to set it up.  At that point I think the cube stuff didn't support GCC - which it does now?
It used to be the case, and STM32 is still very annoying due to the huge array of half assed choices to develop with the things. It definitely would be much better if ST put a higher priority on making a "premier" IDE available to everyone and support it officially, like Microchip does with MPLabX, TI with their Code Composer or Cypress does with PSoc Creator. On the other hand, SW4STM32 (which i linked above) seems to be something pointing in that direction, it's Eclipse/GCC based and freely available for Windows, Linux and Mac and it does work very well once you get it set up.
« Last Edit: July 15, 2016, 01:42:52 am by iromero »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 7928
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #19 on: July 15, 2016, 03:21:10 am »
I note you're a big fan of opening new tabs, and wanted to point out that holding down CTRL while clicking a link does the same thing as rightclick and selecting "open in new window"

Or just click with the middle button.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #20 on: July 15, 2016, 04:58:52 am »
https://youtu.be/mkx4qZCCHqI?t=1650
https://youtu.be/mkx4qZCCHqI?t=1755
The look of pure joy  :-+
I remember making an advanced excel sheet for a few days for pinmap hell, one month later they released their Cube tool.  |O

Great video!  Got a couple of discovery boards a couple of years back, and they have been living in a drawer since as I got totally confused about which IDE/compiler to use, where to get it and how to set it up.  At that point I think the cube stuff didn't support GCC - which it does now?
Everybody has that drawer.
Using GCC is hell since there are dozens of different IDE's it can link with. And all the different flavours of Eclipse.
Not to mention the major revision you've missed if you shelf the project for a few months.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #21 on: July 15, 2016, 05:07:00 am »
Dave, I strongly suggest you read the loongish thread on the STM32 Cube ecosystem being terrible before you get too invested in the Cube & STM HAL.

It really is a horrible buggy mess. The Cube UI is nice, but better write your own code instead of using the HAL. Or you will spend days trying to debug issues in ST Micro's libraries and cutting down on code bloat so that you don't run out of flash.

This is the thread I am talking about:
http://www.eevblog.com/forum/microcontrollers/st's-(stm32cube)-software-ecosystem-is-terrible-how-can-we-fix-it/
« Last Edit: July 15, 2016, 05:10:59 am by janoc »
 

Offline thm_w

  • Frequent Contributor
  • **
  • Posts: 642
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #22 on: July 15, 2016, 05:33:02 am »
STCube only directly supports GCC via Atollic TrueSTUDIO, ie the only GCC version you get a proj file for is TrueSTUDIO.  I suspect this is because TrueSTUDIO is a simple installer whereas any eclipse cdt environment requires multiple installs and configs (even though GNU ARM Eclipse is a totally awesome effort).  Nice things about TrueSTUDIO include an unlimited version for even commercial development.  Pro / paid version has features that even include features that GNU ARM Eclipse don't include: Live variables, ITM console support / profiling, ETB support etc.
Single install here: http://www.openstm32.org/About+OpenSTM32
Was mentioend by iomero, also someones already linked this to dave in the YT video, and he said he will try it out.
 

Offline TheDirty

  • Frequent Contributor
  • **
  • Posts: 437
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #23 on: July 15, 2016, 05:34:20 am »
  • Crossworks: Beautiful editor with fantastic configuration screen. Okay editor.  Lacking Debug support.
What debug support is lacking in Crossworks?  I'm using crossworks, just wondering if there is something I'm missing.
Mark Higgins
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11000
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #24 on: July 15, 2016, 05:35:51 am »
Glancing at the init code shown in the video looks like it sets up registers a bit(field) at a time instead of combining all bits in each register into words, or creating an efficient const array.
By all means include comments documenting the settings in case you need to tweak them, but just spewing out a zillion bit settings is so lazy & inefficient.
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11000
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #25 on: July 15, 2016, 05:46:41 am »

BTW .. the GCC is slow is utter FUD and bull$#^ sold by guys like IAR and other "compiler vendors". They sell snake oil. Yes there are differences in code size, instruction order etc but no compiler is king @ everything.
It's not just about the compiler - a nice thing about IAR is it has a very tightly integrated IDE and debugger.
I used to use IAR on NXP ARMs a lot before I started bursting the free size limit & moved over to PIC32s, and still use it for AVR occasionally.
Compared to my experience of GCC (as implemented by Microchip), IAR is significantly  better for the overall task of "getting the job done" with many features to aid productivity - like lots of "did you really meant to do that" type compiler warnings,  doing stuff like pulling all included files into the project automatically, and GUI linker configuration for many of the common things you want to do.
If you do develop a lot of code professionally it probably is worth the money, though I've no idea how it compares to the competition these days.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4215
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #26 on: July 15, 2016, 06:09:43 am »
Glancing at the init code shown in the video looks like it sets up registers a bit(field) at a time instead of combining all bits in each register into words, or creating an efficient const array.
By all means include comments documenting the settings in case you need to tweak them, but just spewing out a zillion bit settings is so lazy & inefficient.

Although I agree it's less efficient, I wouldn't call it lazy necessarily, it's personal choice, but if I have a reasonable amount of space and it isn't time critical i.e. one off initialisation, then I much prefer bitfield assignments, frequently together with a short comment if necessary as I find it much more readable. An alternative approach is ORing bitmapping macros which gives you the best of both worlds, but for some reason vendor provided macros like this seems to have lost favour.

Almost as frustrating as assigning a register an apparently arbitrary hex value is when a code generator "helpfully" comments the bitfields affected but not where they are in the register or how wide they are, so you have to refer to the data sheets anyway. And in the case of Microchip's code generators like Harmony and Code Configurator, gets it wrong enough times to know it's not to be trusted.

Worse, when assigning these arbitrary hex values, the code generator is frequently unaware that some registers/bitfields require initialising before turning the peripheral on.

The aim is to have code where the maintainer need not refer to the data sheet at all.
 
The following users thanked this post: Kilrah

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2160
  • Country: gr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #27 on: July 15, 2016, 06:30:13 am »
Another GCC+Eclipse option, is CooCox CoIDE.

Alexander.
Become a realist, stay a dreamer.

 

Offline Quarlo Klobrigney

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: us
  • Mild Mannered Time Traveller... Stuck In Forward
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #28 on: July 15, 2016, 08:15:14 am »
Another GCC+Eclipse option, is CooCox CoIDE.
Alexander.
CooCox ist tot
Voltage, does not flow, nor does it go.
 

Offline daybyter

  • Frequent Contributor
  • **
  • Posts: 388
  • Country: de
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #29 on: July 15, 2016, 10:55:15 am »
http://www.stm32duino.com

I used the Arduino IDE to program my stm32.
 

Offline ajm8127

  • Contributor
  • Posts: 15
  • Country: us
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #30 on: July 15, 2016, 11:04:25 am »
Another GCC+Eclipse option, is CooCox CoIDE.

Alexander.

I've been using version 1.7.8 of CoIDE to develop a project and have been reasonably pleased with it. Kind of quirky, but that really doesn't surprise me. It was $0. I'm using the STM32F3 discovery board because I needed the FPU and the board was $10 with the built in STLink V2 programmer. Overall things work well enough.
-Tony
 

Offline RogerClark

  • Contributor
  • Posts: 14
  • Country: au
    • Roger Clark's blog
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #31 on: July 15, 2016, 01:46:04 pm »
http://www.stm32duino.com

I used the Arduino IDE to program my stm32.

Unfortunately at the moment we don't have a full Arduino "core" that works with the STM32L1 MCU, the main core we have is for the STM32F1 which I suspect is a lot different (though I don't suppose it would do any harm to try using it)

@grumpyoldpizza has a great Arduino core for the STM32L4 which he wrote recently https://github.com/GrumpyOldPizza/arduino-STM32L4


If this has spurred anyone's interest in the STM32 series of MCU's, the most popular boards on the forum (www.stm32duino.com) are...
 the "Blue Pill", which you can get on AliExpress for under $2 (USD) e.g. http://www.aliexpress.com/item/Free-Shipping-1pcs-lot-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduin0/32498344057.html?spm=2114.01010208.3.2.tpn8PO&ws_ab_test=searchweb201556_10,searchweb201602_4_10057_10056_10055_10049_10017_405_404_407_10058_10040,searchweb201603_8&btsid=64cb8fbd-5623-4c31-b309-8eb14e775924 

Or the "Maple Mini" (clone) http://www.aliexpress.com/item/STM32F103CBT6-maple-mini-ARM-STM32-compatibility/32675248693.html?spm=2114.01010208.3.1.dXL0b9&ws_ab_test=searchweb201556_10,searchweb201602_4_10057_10056_10055_10049_10017_405_404_407_10058_10040,searchweb201603_8&btsid=48434a56-c767-40ec-b3a6-51deccb18447



However, for Dave's commercial product, the Arduino IDE and this community supported core would not be applicable, so I suspect that Dave will need to use the STM32 Cube and the HAL, with either TrueSudio or OpenSTM32 Workbench ( http://www.openstm32.org/Downloading+the+System+Workbench+for+STM32+installer )
 

Offline ez24

  • Super Contributor
  • ***
  • Posts: 3049
  • Country: us
  • L.D.A.
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #32 on: July 15, 2016, 04:36:34 pm »
Dave, I must concur, use Eclipse (yes I said Eclipse) with GCC as per Carmine's excellent starter book Mastering STM32 linked somewhere here. I suggest reading it as an eye (and mind) opener.

A free Windows but tough (other OS are in the book) tool chain per Carmine (Mastering STM32):

Eclipse - Eclipse CDT - GCC ARM - Build Tools - OpenOCD - ST-LINK Utility - (then board drivers)
(I think)

I am somewhere around step 4 .   Whew  |O but it is free

YouTube and Website Electronic Resources ------>  http://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline newbrain

  • Frequent Contributor
  • **
  • Posts: 487
  • Country: se
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #33 on: July 15, 2016, 06:26:26 pm »
Another GCC+Eclipse option, is CooCox CoIDE.
Alexander.
CooCox ist tot
Definitely, and was  quite buggy to begin with (both the 1.7.8 and 2.something beta).
Some people here still like it, though.

There is also a free IDE (Eclipse+GCC+OpenOCD) provided by ST (actually, AC6):
System Workbench for STM32, it runs on Linux, Windows and OsX.
I tried it some time ago and it mostly worked, I don't know whether STM32L1 is supported though:
for other STM32s there's the option to generate a project for it in CubeMX, but I don't remember noticing it in Dave's video.
, Edit: re-checked the video and the SW4STM32 option is definitely there, at 33:39 so  :-+

Personally, I have been told by my doctor that I'm allergic to Eclipse, so I use VisualGDB: not free (but quite cheap), very good integration of GCC/GDB/OpenOCD (and others) in Visual Studio, support for several other architectures (e.g ESP8266) in addition to a truckload of ARMs (with automatic support libraries downloads). If a pre-cooked debugging set-up does not fit you, it's easy(ish) to define your own.
If you like VS (the Community edition is free as in beer but still very powerful), that's a no-brainer.
All of this, of course IMHO, YMMV etc...
« Last Edit: July 15, 2016, 06:46:58 pm by newbrain »
For the Snark was a Boojum, you see.
 

Online Brutte

  • Frequent Contributor
  • **
  • Posts: 499
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #34 on: July 15, 2016, 07:58:13 pm »
The STM32L-Discovery is one of my favorite STM32 tools.

I'd like to point out the gotchas one can experience with this tool:
  • It does not come with CR2032 battery holder. There is a footprint at the back but no holder or JP2 pin header. Just get those, this is a must have feature. With battery in place it is self-powered and runs 24/7. Then you do not have to debug from reset but simply attach the debugger to an forever running target.
  • There is neither HS crystal quartz nor filter caps for accurate clocking of the target. Thus with default configuration you cannot use a uC as standalone USB device. It can be clocked from St-Link MCO but that is not very convenient to do a USB device that requires two USB cables! If you do not need accurate clocking (for USB) then there is no need for HS quartz really. Just never, ever try to clock USB with internal HS RC as this would drive anyone crazy!!
  • The RESET line from ST-Link is jumpered (SB100, IIRC) with nReset of the target. For low power operation and ST-Link inactive this jumper has to be removed or the disconnected St-link would pull nReset low. After desoldering SB100 just use regular jumper wire or diode between pinheaders, reset line has important role during debugging but not for running.
  • When running it low power (from battery) you have to tie pin 2 of JP1 with pin 2 of JP2 to bypass uCurrent circuit. The uCurrent (mA and uA range) is behind the LCD.

These chips are supported by Standard Peripheral Library (now superseded by Cube but still available). I'd suggest starting with SPL as Cube can be a bit challenging for a first run.

The ADC in LQFP64 is ok but the highest speed and accuracy is available on 4 unmuxed pins only. Rest of the ADC pins is muxed, slower and less accurate. I suspect ADC in LQFP144 is even better as it has separate AREF pins.

I'd also point out there is an STM32L100 family available. About same functionality, targeted for economy market.
And there is STM32L4 with its own discovery. These have lower run mode current per MHz, more goodies, FPU, and do QSPI (you can even run a 16MB application from it).
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1324
  • Country: dk
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #35 on: July 16, 2016, 12:38:32 am »
STCube only directly supports GCC via Atollic TrueSTUDIO, ie the only GCC version you get a proj file for is TrueSTUDIO. 

Thats NOT correct   ;) , the new CubeMX supports STM's SW4STM32 , witch is Eclipsebased.
ST even has it as an Eclipse Addon , i just installed it on Eclipse Luna

http://www.st.com/sw4stm32



Ohh and debugging w. ie. a "Clone ST-Link" is easy on my linux mint17 , using OOCD & SW4STM32

/Bingo
« Last Edit: July 16, 2016, 12:42:02 am by bingo600 »
 

Online C

  • Super Contributor
  • ***
  • Posts: 1292
  • Country: us
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #36 on: July 16, 2016, 02:08:40 am »

Forums are known for short answers to big question answers.

Does Source Code size always change Machine Code Size?
Easy answer is NO.   
  One example using very long variable names.

When you MICRO look at something that is not looking at the big picture.

 Constant folding
https://en.wikipedia.org/wiki/Constant_folding

Just one example of where a great compiler and great language and it use makes life easer.

I see a lot of gripes here about CubeMX output, but no thoughts of how much of this output becomes a compiler constant with a great compiler.

Does all this code become just a few writes or is your compiler too dumb?

Is the changes some have suggested to make it easer for the source code users or the compiler?

setting up registers a bit(field) at a time can still be a constant for a great compiler.
In one case the compiler works for you
   and
  the second case you work for the compiler.

When you work for the compiler, you also have to do the safety checks and verify what is valid.
 

 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 14257
  • Country: nl
    • NCT Developments
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #37 on: July 16, 2016, 02:27:16 am »
Compared to my experience of GCC (as implemented by Microchip), IAR is significantly  better for the overall task of "getting the job done" with many features to aid productivity - like lots of "did you really meant to do that" type compiler warnings,  doing stuff like pulling all included files into the project automatically, and GUI linker configuration for many of the common things you want to do.
If you do develop a lot of code professionally it probably is worth the money, though I've no idea how it compares to the competition these days.
GCC does a lot of complaining too by default. Also Eclipse CDT + GCC is a pretty productive combo due to the excellent editor and code management Eclipse offers. Pulling in includes is the least of the problems (GCC knows where to find the includes by default as well so no drama there). So far Eclipse has outperformed any vendor provided IDE I have ever worked with but with great power comes a lot of ways to mess things up.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 1313
  • Country: 00
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #38 on: July 16, 2016, 03:34:31 am »
Hey guys, Wow, you'all brought the rain on this. Would this be a good next step from Arduino?
« Last Edit: July 16, 2016, 03:39:58 am by metrologist »
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11000
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #39 on: July 16, 2016, 04:04:51 am »
GCC does a lot of complaining too by default.
Wouldn't call it complaining - e.g. it will give you a "did you mean that"  warning if you do " if (a=1) "

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 14257
  • Country: nl
    • NCT Developments
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #40 on: July 16, 2016, 04:22:08 am »
GCC does a lot of complaining too by default.
Wouldn't call it complaining - e.g. it will give you a "did you mean that"  warning if you do " if (a=1) "
On that particular example: Eclipse CDT (or better put: Eclipse with CDT plugin) complains about such a thing the instant you type it (realtime syntax checking!) and GCC for ARM throws a warning during compilation.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline thm_w

  • Frequent Contributor
  • **
  • Posts: 642
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #41 on: July 16, 2016, 09:05:42 am »
  • There is neither HS crystal quartz nor filter caps for accurate clocking of the target. Thus with default configuration you cannot use a uC as standalone USB device. It can be clocked from St-Link MCO but that is not very convenient to do a USB device that requires two USB cables! If you do not need accurate clocking (for USB) then there is no need for HS quartz really. Just never, ever try to clock USB with internal HS RC as this would drive anyone crazy!!
You can use the 32kHz RTC crystal as calibration for HS RC. But maybe it adds too much complexity, and the step size is fairly big (0.5% step):
http://www.st.com/content/ccc/resource/technical/document/application_note/ef/e5/c7/ad/10/ae/43/14/CD00289137.pdf/files/CD00289137.pdf/jcr:content/translations/en.CD00289137.pdf

The L4 is a bit better 0.25%:
http://www.st.com/content/ccc/resource/technical/document/application_note/60/15/94/5b/15/bb/4f/9e/DM00210926.pdf/files/DM00210926.pdf/jcr:content/translations/en.DM00210926.pdf
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1489
  • Country: ch
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #42 on: July 16, 2016, 09:12:13 am »
Wouldn't call it complaining - e.g. it will give you a "did you mean that"  warning if you do " if (a=1) "

And there are improvements coming... someone tried to build an open source I work on with GCC 6, and it interestingly threw some very pertinent warnings about potential edge cases in production code that were never brought up before neither by GCC 4 nor independent validation tools.
 

Offline Hemogloben

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #43 on: July 16, 2016, 10:04:02 am »
  • Crossworks: Beautiful editor with fantastic configuration screen. Okay editor.  Lacking Debug support.
What debug support is lacking in Crossworks?  I'm using crossworks, just wondering if there is something I'm missing.

The biggest omission is some kind of graphical tasking viewer for RTOS development.  Their threads window is a joke; yeah, sure I COULD write javascript to make a decent view of the running tasks... or you could do your job and do that for me.  Plus at best that gives you a columnar view of info and not timeline / graphical options.

Lack of Watchpoint support; watchpoints have definitely saved me a number of times when I ran into out of bounds array access bugs that were in unrelated parts of code.

Other stuff on the Debug views are things that are really small nice to haves.  Live Expressions, Graphical views of variables over ITM.  These were minor nit-picks but after evaluating TrueSTUDIO and realizing I could effectively use ANY eclipse plugin to improve my development workflow... AND their subscription was $600 cheaper than Crossworks I stopped digging deeper into it.

That said, I liked the interface more than IAR or Keil and it had TONS of options for low-level stuff (JTAG, ITM, ETB configs etc) and like IAR and Keil the options for various leaner printfs are nice.  I generally work with similarly featured micros so I don't need most of those settings; plus I only have to deal with setting up linker files and writing printfs at the beginning of a project, I'd rather not optimize my IDE for something I only spend 5-10% of my time on.  Seemed like a smarter choice to make the act of writing, documenting, and testing code the priority. (And for that Crossworks was better than IAR or Keil, but I still thought TrueSTUDIO the winner; solely because of eclipse plugins).

It was also during a 1.5 week period where I had to get our bootloader building in all the different IDEs and run them through their paces.  That is a HECK of a lot of IDEs in a short time-frame and it's possible I didn't give them all a fair shake.

STCube only directly supports GCC via Atollic TrueSTUDIO, ie the only GCC version you get a proj file for is TrueSTUDIO. 

Thats NOT correct   ;) , the new CubeMX supports STM's SW4STM32 , witch is Eclipsebased.
ST even has it as an Eclipse Addon , i just installed it on Eclipse Luna

/Bingo

I forgot they changed that.  It used to be TrueSTUDIO (I haven't updated my personal version of CubeMX since last year so it still has the TrueSTUDIO option).  That said, annoyingly, even with the eclipse plugin, it won't generate Eclipse CDT project files.  It'll still only generate project files for Keil, MDK, and (now)SW4STM32; because of that the eclipse plugin always seemed kinda WTF (though I guess it was originally meant for use inside TrueSTUDIO and now probably for use in SW4STM32).
 

Offline abebarker

  • Contributor
  • Posts: 47
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #44 on: July 16, 2016, 06:18:36 pm »
I've been playing the STM32 series for several years now. I have tried the Cube software and I found it to be harder to understand than setting things up manually with the examples that come with the Standard Peripheral Library. The Cube software adds another couple of layers of abstraction and it is not easy to follow what is happening.

The most convenient IDE that I have come across for programming the STM32 series is Em::Blocks. I believe the developer recently changed its name to Em::Blitz. He had planed on making it licensed but has since decided against the licensing scheme so it is still totally free. It has everything that I like;
 - Its free
 - Its not code size limited.
 - It is based upon Code::Blocks (I love Code::Blocks)
 - It uses the GCC compiler
 - The debugger works.
 - It is easy to use
 - It is easy to set up
 - The developer was very responsive
 - It is NOT written in Java!!!

 http://www.emblocks.org/

There are some things I don't like about it;
 - Its not open-source.
 - It only works on windows (I recently switched to Linux)

Other than that I have really enjoyed using Em::Blocks. I have recommended it several other times to people and will probably do so again. I really enjoyed using it.

Note: You will still have to set up the ST-Link USB driver separately.
« Last Edit: July 16, 2016, 06:28:23 pm by abebarker »
 

Offline V42bis

  • Contributor
  • Posts: 7
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #45 on: July 17, 2016, 08:54:50 pm »
can't find the firmware source on the st site


Sent from my iPad using Tapatalk
 

Offline Quarlo Klobrigney

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: us
  • Mild Mannered Time Traveller... Stuck In Forward
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #46 on: July 17, 2016, 09:31:44 pm »
I clearly left them on the VAX. Do a $DISK1:[CORR] and you will see them.
can't find the firmware source on the st site
What firmware? :-//
Voltage, does not flow, nor does it go.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 4375
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #47 on: July 17, 2016, 11:20:20 pm »
https://youtu.be/mkx4qZCCHqI?t=2406

Yeah IAR stinks for non-professionals, you with your little $15 development board would have had a heart attack if you saw the prices.
They are for businesses that earn tons of money on their products.
They have nothing for hobbieists.
But if you want to know the prices (put a stiff drink nearby for the shock) here you can find them for 2012 and they have not become cheaper  ;) :
http://www.mouser.com/catalog/catalogusd/645/2360.pdf
 

Offline V42bis

  • Contributor
  • Posts: 7
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #48 on: July 18, 2016, 06:31:54 am »
the source code for what came with the board. I did find it.


Sent from my iPad using Tapatalk
 

Offline abebarker

  • Contributor
  • Posts: 47
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #49 on: July 18, 2016, 07:02:06 am »
can't find the firmware source on the st site


Sent from my iPad using Tapatalk

It looks like ST is now making you log in to get the software. That didn't used to be the case.



The firmware examples and Standard peripherals library is called  "STM32L1 Discovery firmware package (RN0079)".

The STM32L-DISCOVERY firmware package contains the following:
• AN3413 STM32L-DISCOVERY Current consumption and touch sensing demo V1.0.2
• AN3964 STM32L-DISCOVERY Temperature sensor example V1.0.0
• STM32L1xx Standard peripherals library drivers (StdPeriph_Driver) V1.0.0       
• STM32 Touch sensing driver V0.1.3

STM32L1 Discovery firmware package (RN0079)
http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries-expansions/stsw-stm32072.html




After a while I had decided to use only the standard peripherals library. This is the lowest level of the software stack. All the examples are built with it. All the code generated by Cube is a layer of abstraction added on top of it.

STM32L1xx standard peripherals library ver. 1.3.1
ST Part Number: stsw-stm32077
File name: stsw-stm32077.zip

http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries/stsw-stm32077.html

If you don't want to sign up with ST then you can get it from my dropbox.
https://dl.dropboxusercontent.com/u/51926927/(STM32L1xx%20standard%20peripherals%20library)(1.3.1)stsw-stm32077.zip


 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #50 on: July 18, 2016, 07:08:02 pm »
Cube MX seems to have all the files available for curl to grab from OVH CDN.
Code: [Select]
GET /s3/stm_test/software/firmware//stm32cube_fw_f1_v110.zip HTTP/1.1
It shows that even though ST MX Cube works, it is still uses stm_test as folder with an // in the url. Although valid, not very clean.
 

Offline roli

  • Contributor
  • Posts: 35
  • Country: si
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #51 on: July 19, 2016, 03:52:25 am »
Another vote for Em::Blocks IDE from me.
IAR and Keil are really haunting when you are a novice developer. And generating a new empty project with them is not quite as straightforward as it should be.
Em::Blocks is simple though. Select the chip, click next a few times and you have a project with STM libraries included. Besides the fact that the whole thing is free and doesn't have code size limits.

Overall the STM micros are really nice. And their development boards are dirt cheap. Their documentation is really nice as well. Software support a bit less so. Their libraries could be simpler and could include more useful stuff. And the toolchain selection is a pain as well. Their STLINK is great as well. I am using that to program ARM chips from Nordic and it works perfectly. And much cheaper than spending 50$ on a debugger/dev board - what you need to get started with Nordic.

I am currently mostly working with Nordic ARM chips (nRF51 series). And they have one of the best supports that I have seen. Ask a question on their dev boards and you will get a response from either someone in the community or a Nordic representative really fast. Not to mention the huge database of already anwsered questions. Plus a ton of tutorials and examples. Their software libraries are also much more powerful than the ones offered by STM. They already include stuff like task switching and common things like delays, ... Of course you probably wouldn't use a Nordic chip if your application doesn't need wireless connectivity. They aren't making general purpose micros.
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1324
  • Country: dk
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #52 on: July 26, 2016, 12:45:30 am »
That EM::Blocks does not support linux is a 100% showstopper for me.

I wonder why the author "destroyed" C::B in that way.

/Bingo
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 4375
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #53 on: July 26, 2016, 01:31:05 am »
Quote
Their software libraries are also much more powerful than the ones offered by STM. They already include stuff like task switching and common things like delays
Include free RTOS and you have the same.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1489
  • Country: ch
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #54 on: July 26, 2016, 02:58:10 am »
That EM::Blocks does not support linux is a 100% showstopper for me.

I wonder why the author "destroyed" C::B in that way.
Isn't Code::Blocks still being developed in parallel?
 

Offline TinkeringSteve

  • Regular Contributor
  • *
  • Posts: 154
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #55 on: August 13, 2016, 11:13:20 am »
To add options to the IDE suggestions (I may have overlooked their mentioning):

- VisualGDB - a Visual Studio plugin to use GCC + GDB + (OpenOCD / Segger / you name it), which costs about 70 bucks in the "embedded" edition (half for students)

- the Code::Blocks IDE also supports GCC / OpenOCD development for some time (I forgot whether you need to get the plugins elsewhere or it comes with it, but there are tutorials on setup which looked easy enough)
Code::Blocks usually runs is a lot faster / more smoothly than Eclipse, which is why I will give it a go some time.

The already mentioned Rowley Crossworks for ARM is also allright, a non-profit license is available for roughly 100 bucks, IIRC. The editor used to suck hard, but apparently it improved a lot.

The mentioned Em::Blocks (or what it's called today)... the guy somehow went off with his branch and botched it in a way which basically makes it impossible to ever get the new features from the currently developed Code::Blocks back in there, which makes me rather hesitant of investing time in that.

And as for ST's HAL / cube library... the structure of it is just horrible... If you have seen how a net made by a spider on caffeine looks like - that's what that library looks like. If you think that 4 or so layers of indirection before your damn callback gets actually called is cool, ... or that, since you already have ISRs which apparently get called out of nowhere, this should be made into a general programming paradigm and create lots of hardware init functions which get called out of nowhere...
Or if you think a library which prevents you from using the USART in full duplex mode although the hardware supports it is not retarded, by all means go for it... ;-) (this is only a fraction of the blunders)

The CubeMX code generator is useful for some things, though - one being to getting the rather complex clock settings of some if the STM32's right. (like the L4 which has several PLLs and multilicators and dividers and stuff)
I just wouldn't use the code it generates ^^ (or the library. I'm moving to mostly use just the CMSIS, the refrence manual and initializing registers as described therein)
« Last Edit: August 13, 2016, 11:28:15 am by TinkeringSteve »
 
The following users thanked this post: thm_w

Offline TinkeringSteve

  • Regular Contributor
  • *
  • Posts: 154
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #56 on: August 13, 2016, 07:25:47 pm »
Watching the video... let me add another remark:

You are some times referring to "the datasheet" which one has to look for clock configuration etc.

It is a bit different with stm32, more spread out into different documents, which are all rather huge, owing to the complexity of the beast.
The datasheet mostly contains information about what's in the chip, electrical characterikstics, pins etc.

Then there is a separate, huge, document: the reference manual.
This contains all the information on how to configure peripherals via setting register values, procedures, timings...

Those are found on the ST Micro page for the MCU, under the tab "design" or "design resources", where you'll also find a bunch of appnotes.

Then, there is a document, I think programming manual (like PM0056 for your puppy ), which is more general, for the e.g. M3 core of the processor.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #57 on: August 14, 2016, 04:11:36 am »
Then, there is a document, I think programming manual (like PM0056 for your puppy ), which is more general, for the e.g. M3 core of the processor.

AFAIK, the programming manuals are just that - how to actually program the part. I.e. description of SWD/JTAG programming, bootloaders, etc.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1489
  • Country: ch
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #58 on: August 14, 2016, 04:14:08 am »
With ST and I believe most ARM parts the "programming manual" typically includes the details of the actual processor core, registers, addressing, instructions, how to use it efficiently etc while the "reference manual" refers to the chip and its peripherals.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #59 on: August 14, 2016, 09:15:20 pm »
With ST and I believe most ARM parts the "programming manual" typically includes the details of the actual processor core, registers, addressing, instructions, how to use it efficiently etc while the "reference manual" refers to the chip and its peripherals.

Well, yes and no - look here:
http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f1-series/stm32f103/stm32f103rb.html

PM0075 is the flash programming manual
PM0056 is the Cortex-M3 core manual

 

Offline imanhp

  • Contributor
  • Posts: 7
  • Country: se
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #60 on: August 15, 2016, 07:37:14 am »
I second VisualGDB! visualgdb.com for Visual Studio (uses GCC compiler).

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

Now add the mbed library to the mix and your on easy street: http://visualgdb.com/w/tutorials/category/tutorials/embedded/mbed/
 

Offline Vasi

  • Regular Contributor
  • *
  • Posts: 55
  • Country: ro
    • My photo gallery
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #61 on: December 31, 2016, 06:08:49 am »
I recently got a Nucleo_64 board (Nucleo_L152RE, 512Kb Flash, 80Kb SRAM) as a present for my birthday. Is a fantastic board, very well designed, with access to all the microcontroller pins. So, first time in ARM programming and under Linux. I've installed OpenSTM32 IDE with everything the board needs (toolchain, libraries, STM32CubeMX, openOCD and STlink2 for Linux). It works nicely, blinking LEDs for now, with blocking delays or non-blocking delays. Next, I will try the serial communications, LCD and DS18B20 sensor (have to make libs, but I found already some github repositories), and so on. I really enjoy the board and I'm impressed with the STM32 micros! I see there are a lot of 5V tolerant pins and that is another plus for someone coming from 8bit 5V micros. I'm "jurnaling" my progress on the blog http://nucleobytes.blogspot.ro/ but just at the beginning and nothing yet to see (well just a way to prove that my enthusiasm is true and I'm not a spamer). 

Update May 20, 2017: done that (serial, LCD and temperature sensor), now I try to learn HAL i2c, a little bit different than AVR and PICs, I will use a PCF8583 peripheral.
https://github.com/funlw65/my_nucleo_l152re
« Last Edit: May 20, 2017, 10:26:29 pm by Vasi »
 

Offline fab672000

  • Contributor
  • Posts: 8
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #62 on: February 23, 2017, 12:47:33 pm »
Hey Dave,
Not sure how far you got with this, but I wanted to share a tool for which I did a humble contribution not so long ago :
The awesome Carmine Noviello CubeMX Importer python tool that imports cubemximporter configurations  and allows you to inject the output sourcecode and c++ project into a gnu eclipse arm project

... no size limit,  100% opensource toolchain that now can reuse CubeMX output !

Check this out:
---------------
https://github.com/cnoviello/CubeMXImporter

Also for a quick ramp up on the awesome gnu arm eclipse toolchain and related plugins/tools:
--------------------------------------------------------------------------------------------------

http://gnuarmeclipse.github.io/toolchain/install/
http://gnuarmeclipse.github.io/plugins/install/
http://gnuarmeclipse.github.io/windows-build-tools/install/
http://gnuarmeclipse.github.io/openocd/install/

Also, note that Segger jtag/swi hardware  debug probes work great with eclipse / gcc arm tools !
So don't feel you need openOCD to use hardware debuggers with the free gnu arm eclipse toolchain (Segger is awesome and develops very responsive probes IMHO!)

Hope that helps!

UPDATE:

1. Also check Carmine how-to pages here:
  http://www.carminenoviello.com/2015/11/02/quickly-import-stm32cubemx-project-eclipse-project/
  http://www.carminenoviello.com/2015/06/04/stm32-applications-eclipse-gcc-stcube/
2. Also pay attention to the recommended ARM gcc compilers versions you use as instructed in the gnuarmeclipse.github.io help pages, it will make a huge difference between a stable debugging env. and a bad one with recent (but unfortunately not fully compatible yet) gcc compilers.
3. Similarly you want to refrain updating to the latest eclipse cdt ide, use Mars.2 NOT Neon
-Fab
« Last Edit: February 23, 2017, 02:15:08 pm by fab672000 »
 
The following users thanked this post: EEVblog

Offline Darren

  • Contributor
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #63 on: March 07, 2017, 11:05:27 am »
I have to say that the STM32 platform is a complete turd. I have spent 3 days now trying to get the gcc and eclipse toolchain up and running and well suffice to say I failed miserably and the $10 board is now sitting in a glass of water on my desk in order to have the death it deserves.

I don't expect the thing to be as idiot friendly as the Arduino system but I don't expect to have to go running in circles and bumping into dozens of dead ends just to be able to load an example. That is 3 days of my life I won't ever get back.
 

Offline MrBungle

  • Supporter
  • ****
  • Posts: 75
  • Country: au
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #64 on: March 07, 2017, 03:32:43 pm »
...the STM32 platform is a complete turd...
...the gcc and eclipse toolchain...
Crapping on the hardware because of a third party toolchain and your own shortcomings.
Thanks for the laugh.
 

Offline Darren

  • Contributor
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #65 on: March 07, 2017, 10:42:19 pm »
Crapping on the hardware because of a third party toolchain and your own shortcomings.
Thanks for the laugh.

I hope you are not involved in product design, the hardware might be perfectly capable but the hardware is only half the story. Once you buy the Nucleo or Discovery board you are essentially left high and dry. It doesn't help that the libraries and tools seem to change frequently so a great deal of information is completely out-of-date and irrelevant.

You might not see it as a problem but I have used PIC microcontollers before and getting started was nowhere near as difficult as the muddle that surrounds the STM32. The barrier to get started is really high and this must be loosing ST a lot of new customers who like me just give up in dispair and use something else.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 4375
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #66 on: March 07, 2017, 11:24:07 pm »
You might not see it as a problem but I have used PIC microcontollers before and getting started was nowhere near as difficult as the muddle that surrounds the STM32.
The barrier to get started is really high and this must be loosing ST a lot of new customers who like me just give up in dispair and use something else.
Unless you are talking about the 32bit PICs you shouldn't mix apples and oranges.
The 32 bits ARM micro's from all manufacturers (NXP, Atmel, ST, .....) are all  a big hurdle from persons coming from the 8 bit world.
If it was really that easy to make a quick GUI plug (configure) and play some would have done it by now and all other competitors were out of business.
Since this is not the case one can wonder if those micro's are suited for the starting hobbieist or only for experienced persons and companies or those that have plenty of time to spend on the learning curve and fixing issues.
 

Offline Darren

  • Contributor
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #67 on: March 07, 2017, 11:52:22 pm »
There is nothing inherent about the Arm microcontrollers that should make it so hard to get started. I'm not talking about the complexity of the architecture of the system with all the extra registers etc. In the PIC example they have one primary IDE that they base all their information and help on. You can buy other compilers and IDEs for PIC but it is easy to get stated. You install the software load up the example code and flash your modified version. There is no reason why STM32 lacks a comprehensive set of tools to get started with minimal futzing around.

Due to the lack of any kind of getting started guide from ST I have had to go looking at blogs and even downloaded a book but most of that information is outdated. I appreciate nobody cares what I think, I'm just a nobody who is frustrated to hell due to failing to get anywhere with the STM32 platform due to the lack of a easy way to get started. I have never been a fan of Arduino but I can see why so many people use it now having experience the falling at the most basic first hurdle, ie installing an IDE and flashing the test software.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1886
  • Country: de
    • Frank Buss
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #68 on: March 08, 2017, 12:27:53 am »
So Long, and Thanks for All the Fish
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #69 on: March 08, 2017, 12:58:08 am »
Since this is not the case one can wonder if those micro's are suited for the starting hobbieist or only for experienced persons and companies or those that have plenty of time to spend on the learning curve and fixing issues.

Nah, come on. Ever heard about newer Teensy? Or the newer Arduinos? Or mBed? All are based on 32bit ARMs. And targeting really beginners.

That some companies have crappy development tools doesn't mean that these micros are somehow orders of magnitude more difficult to use than 8bit ones. Yes, it is a more complex architecture than something like 8bit PIC or AVR and the peripherals are more complicated, but if you start with something like Cortex-M0 and/or decent tooling and work your way up to the more complex chips, it is perfectly doable even for a hobbyist without some extraordinary time or money requirements. There are plenty of examples of hobby projects using ARM chips around.

Of course, if the person has the attention span of a typical 10min Youtube video viewer then it certainly could be difficult.



« Last Edit: March 08, 2017, 01:12:57 am by janoc »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #70 on: March 08, 2017, 01:09:19 am »
I have to say that the STM32 platform is a complete turd. I have spent 3 days now trying to get the gcc and eclipse toolchain up and running and well suffice to say I failed miserably and the $10 board is now sitting in a glass of water on my desk in order to have the death it deserves.

Why didn't you download the official STM IDE - aka the System Workbench? It comes preconfigured, including the toolchain:

http://www.openstm32.org/System+Workbench+for+STM32

The examples that ship with their CubeMX work with this as well.

There is also ChibiStudio that allows to target STM32 and comes preconfigured, ready to go:
http://www.chibios.org/dokuwiki/doku.php

Or download the free eval version of Keil if you aren't happy with Eclipse for some reason. Even mBed probably supports your board (to some degree).

Even starting from scratch, including compiling (!) your own ARM gcc toolchain, ARM gdb and OpenOCD is not that hard. It took me about half a day to set that up - but you don't have to do that. I did it only because I wanted a newer compiler.

I am no ST fanboy, their ecosystem certainly leaves things to be desired, but come on. Did you actually ask for help? Or even read their documentation (instead of random websites)? Because that would have pointed you to the System Workbench web site.

Then there are plenty of 3rdparty libraries and frameworks for these chips, many having been mentioned in this thread (and elsewhere) too, if you don't like the original ST provided ones, whether the Standard Peripheral Library or the newer Cube/HAL.
« Last Edit: March 08, 2017, 01:15:42 am by janoc »
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 4375
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #71 on: March 08, 2017, 01:13:53 am »
Well the whole forum is full of "I started with 32 bit ARM and now I am stuck on (fill in any peripheral)" topics, not for nothing.
Sure it is doable, dannyf has made a nice beginners guide on his blog for instance to get any of three toolchains running.
Still I understand that if you come from a 8 bit world going to 32 bit world with RTOS from scratch can be intimidating.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 1886
  • Country: de
    • Frank Buss
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #72 on: March 08, 2017, 01:20:19 am »
Still I understand that if you come from a 8 bit world going to 32 bit world with RTOS from scratch can be intimidating.

Depends on your project, but most of the time you don't need a RTOS.

I think the easiest way is to create a project with all the peripherals you need with CubeMX, or use one of the sample projects, and then use the IAR or Keil IDE to compile and upload it. For small projects the IDEs are free. Once you are comfortable with it, you can try to use Eclipse.
So Long, and Thanks for All the Fish
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #73 on: March 08, 2017, 01:21:51 am »
Well the whole forum is full of "I started with 32 bit ARM and now I am stuck on (fill in any peripheral)" topics, not for nothing.

Well, yes, but if you compare e.g. STM32F0 timers with something like PIC18Fxx timers or ATmega timers you will see why. The former can do things the ones in the 8-bitters don't even dream about. The price is extra complexity. However, there are plenty of libraries around that simplify the common tasks.

Still I understand that if you come from a 8 bit world going to 32 bit world with RTOS from scratch can be intimidating.

You do not have to use an RTOS. Sure you can, but it is by no means a requirement and in the smaller chips like the STM32F0 series it could be even counterproductive, given the available flash sizes.

I have done projects both using an RTOS (ChibiOS usually) and not using one and it is not really much more complex than an 8bit AVR or PIC once you have the basic code skeleton in place - and that you typically pilfer from an example. Both ChibiOS and libopencm3 have terrific examples that typically work out of the box with minimal changes, even for complex stuff like USB.
 

Offline Darren

  • Contributor
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #74 on: March 08, 2017, 02:01:07 am »
Unfortunately I didn't get as far as investigating the need for an RTOS or not. My goal was just to load up the demo that flashes the LED on the Nucleo F042K6 board and simply change the code to change the cycle time and then flash the modified version as the first step. That I never managed to complete.

To start with it took me a while to realise that example source was buried in a collection called STM32Cube_FW_F0_V1.7.0 and even then it is burried in a folder structure under STM32F031K6-Nucleo/Examples/GPIO/GPIO_IOToggle that required UM1727 User manual didn't really explain and the information was out of date.

Of course I am feeling overly annoyed at the situation, feeling sore at my apparent failure but nevertheless the transition is much more complicated that it need be at the outset.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 4375
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #75 on: March 08, 2017, 02:02:34 am »
Guys tell it to Darren, I do not have a problem with STM32 with or without RTOS  ;)
I just wanted him to feel that he is not the only person out there with this problem, witnessed by the amount of topics on this forum alone.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #76 on: March 08, 2017, 03:54:59 am »
Well, yes, but if you compare e.g. STM32F0 timers with something like PIC18Fxx timers or ATmega timers you will see why. The former can do things the ones in the 8-bitters don't even dream about.
And you get 15 of those. Similar over all F0,1,2,3,4's which is superb.
Never rewrite code again!
 
The following users thanked this post: Kjelt

Offline thm_w

  • Frequent Contributor
  • **
  • Posts: 642
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #77 on: March 08, 2017, 07:08:33 am »
Unfortunately I didn't get as far as investigating the need for an RTOS or not. My goal was just to load up the demo that flashes the LED on the Nucleo F042K6 board and simply change the code to change the cycle time and then flash the modified version as the first step. That I never managed to complete.

To start with it took me a while to realise that example source was buried in a collection called STM32Cube_FW_F0_V1.7.0 and even then it is burried in a folder structure under STM32F031K6-Nucleo/Examples/GPIO/GPIO_IOToggle that required UM1727 User manual didn't really explain and the information was out of date.

Of course I am feeling overly annoyed at the situation, feeling sore at my apparent failure but nevertheless the transition is much more complicated that it need be at the outset.

You picked the wrong solution, its OK. Don't get frustrated, try something else and move on.
If you skim through the STM32 discussion threads for toolchain/ide here you might get an idea of whats better for you.

But I will give the steps for what you wanted to do in Visualgdb:
- Create new project
- Select chip, debugger
- Select an example built-in or HAL project (the default example is blink an LED)
- Compile and run (hopefully)

Atollic, system workbench (eclipse), visualgdb (VS) are some of the commonly recommended. Atollic has sample projects as well built in.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #78 on: March 08, 2017, 09:12:37 am »
To start with it took me a while to realise that example source was buried in a collection called STM32Cube_FW_F0_V1.7.0 and even then it is burried in a folder structure under STM32F031K6-Nucleo/Examples/GPIO/GPIO_IOToggle that required UM1727 User manual didn't really explain and the information was out of date.

That is not explained in that manual, because UM1727 is generic document explaining how to use the various IDEs with the board, not where to find a specific example.

The examples are described in the Cube download:

* Click on the STM32CubeF0 link down on the page (http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef0.html)

* That page has the document AN4735: STM32Cube firmware examples for STM32F0 Series
http://www.st.com/resource/en/application_note/dm00210690.pdf. That is where all the available examples are described, along with a table showing which board are they for.

* You will want to have a look at UM1779: Getting started with STM32CubeF0 for STM32F0 Series http://www.st.com/resource/en/user_manual/dm00119724.pdf as well.

So the information is there, it may just not be very obvious where to look and what to look for.

 

Offline Jan80

  • Newbie
  • Posts: 1
  • Country: au
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #79 on: May 03, 2018, 07:04:30 pm »
Hi Guys,
I bought STM32L152RC discovery kit recently just to get familiar with that little beast.  I downloaded and setup everything as per the video and I uploaded temperature measurement example using IAR  (version 8.22.2.15996 fo ARM free small code license) and everything worked as expected.  After compiling and downloading current measure example it just brings up a single star on the display green and blue LEDs are off. I found out this star is the first visible character of init message, but it doesn't scroll or so. Everything is in default and it originally worked of the factory. Resets didn't help. Pressing blue USER button multiple times brings up the actual measure screens randomly. It's quite frustrating. Any ideas? Thanks
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #80 on: May 04, 2018, 05:04:52 am »
If you want help with something like that, it is probably better to post a new topic in the beginner's section instead of replying to a one year old unrelated issue.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4215
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #81 on: May 04, 2018, 07:03:50 am »
Coincidentally today I finally got around to getting an STM32 project started.

My experiences were not a million miles away from Dave's, there's no single clear step by step guide I could find that takes you through the various required bits of software, but by hook or by crook after a couple of hours I got a blinky working on one of the four Discovery boards I seem to have stockpiled with good intentions.

I went with the TrueStudio solution because it seemed to me that now ST owns Atollic, and there doesn't appear to be any software crippling anymore, this was a reasonable way to go. I think it still is, but I had a few problems with the debugger not working, then Eclipse playing up with the on board debugger (this is a common problem, I have had similar issues with LPCXpresso), and most recently breakpoints visible in Eclipse not being set.

The only out of the box demo I tried wouldn't compile because it couldn't find GCC, that turned out to be a couple of incompatible Tool Chain Discovery settings, one in the GUI and one for the project itself.

But I did get a blinky going from scratch on the board with STM32Cube, which thankfully seems to be a more lightweight framework than Microchip's Harmony.

The biggest problem remains knowing what all the required software components are for your board, and finding them as they are not all on the dev board's product page, you end up going around in circles too. I believe part of the problem is that unlike, for example, Microchip, ST have long supported many development platforms, so the tool chain matrix is large. It reminds me of the gazillions of Linux distros, and why Linux has yet to become ubiquitous on the desktop.

Even with ST's ownership with Atollic, not all Discovery boards have example out of the box code examples for TrueStudio to run out of the box. It's early days though, perhaps now they control the tool chain ST will pay more attention to providing a clean out of the box solution.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf