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

0 Members and 1 Guest are viewing this topic.

Offline mikeselectricstuff

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

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
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4843
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #26 on: July 14, 2016, 08:09:43 pm »
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: 2368
  • Country: gr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #27 on: July 14, 2016, 08:30:13 pm »
Another GCC+Eclipse option, is CooCox CoIDE.

Alexander.
Become a realist, stay a dreamer.

 

Offline Quarlo Klobrigney

  • Frequent Contributor
  • **
  • Posts: 596
  • Country: pt
  • Behind every alfoil hat is a genius
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #28 on: July 14, 2016, 10:15:14 pm »
Another GCC+Eclipse option, is CooCox CoIDE.
Alexander.
CooCox ist tot
Voltage does not flow, nor does it go.
 

Offline daybyter

  • Frequent Contributor
  • **
  • Posts: 396
  • Country: de
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #29 on: July 15, 2016, 12: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, 01: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: 27
  • Country: au
    • Roger Clark's blog
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #31 on: July 15, 2016, 03:46:04 am »
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: 3091
  • Country: us
  • L.D.A.
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #32 on: July 15, 2016, 06:36:34 am »
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 ------>  https://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline newbrain

  • Frequent Contributor
  • **
  • Posts: 845
  • Country: se
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #33 on: July 15, 2016, 08:26:26 am »
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, 08:46:58 am by newbrain »
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #34 on: July 15, 2016, 09:58:13 am »
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).
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1465
  • Country: dk
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #35 on: July 15, 2016, 02:38:32 pm »
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 15, 2016, 02:42:02 pm by bingo600 »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #36 on: July 15, 2016, 04:08:40 pm »

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.
 

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19745
  • Country: nl
    • NCT Developments
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #37 on: July 15, 2016, 04:27:16 pm »
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: 1834
  • Country: 00
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #38 on: July 15, 2016, 05:34:31 pm »
Hey guys, Wow, you'all brought the rain on this. Would this be a good next step from Arduino?
« Last Edit: July 15, 2016, 05:39:58 pm by metrologist »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #39 on: July 15, 2016, 06:04:51 pm »
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
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19745
  • Country: nl
    • NCT Developments
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #40 on: July 15, 2016, 06:22:08 pm »
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

  • Super Contributor
  • ***
  • Posts: 2154
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #41 on: July 15, 2016, 11:05:42 pm »
  • 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: 1857
  • Country: ch
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #42 on: July 15, 2016, 11:12:13 pm »
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, 12: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: 41
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #44 on: July 16, 2016, 08:18:36 am »
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, 08:28:23 am by abebarker »
 

Offline V42bis

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


Sent from my iPad using Tapatalk
 

Offline Quarlo Klobrigney

  • Frequent Contributor
  • **
  • Posts: 596
  • Country: pt
  • Behind every alfoil hat is a genius
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #46 on: July 17, 2016, 11:31:44 am »
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: 5834
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #47 on: July 17, 2016, 01: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 17, 2016, 08:31:54 pm »
the source code for what came with the board. I did find it.


Sent from my iPad using Tapatalk
 

Offline abebarker

  • Contributor
  • Posts: 41
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #49 on: July 17, 2016, 09:02:06 pm »
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


 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf