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

0 Members and 1 Guest are viewing this topic.

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #50 on: July 18, 2016, 09:08:02 am »
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

  • Regular Contributor
  • *
  • Posts: 69
  • Country: si
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #51 on: July 18, 2016, 05:52:25 pm »
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.
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #52 on: July 25, 2016, 02:45:30 pm »
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: 6459
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #53 on: July 25, 2016, 03:31:05 pm »
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: 1852
  • Country: ch
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #54 on: July 25, 2016, 04:58:10 pm »
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

  • Frequent Contributor
  • **
  • Posts: 289
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #55 on: August 13, 2016, 01: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, 01:28:15 am by TinkeringSteve »
 
The following users thanked this post: thm_w

Offline TinkeringSteve

  • Frequent Contributor
  • **
  • Posts: 289
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #56 on: August 13, 2016, 09:25:47 am »
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: 3781
  • Country: de
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #57 on: August 13, 2016, 06:11:36 pm »
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: 1852
  • Country: ch
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #58 on: August 13, 2016, 06:14:08 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.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #59 on: August 14, 2016, 11:15:20 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.

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

  • Newbie
  • Posts: 7
  • Country: se
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #60 on: August 14, 2016, 09:37:14 pm »
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: 60
  • Country: ro
    • Visual Pin Configurator for Nucleo L152RE - produces SPL code.
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #61 on: December 30, 2016, 07:08:49 pm »
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

Update December 13, 2018 Ha! Forget HAL, forget LL, I am at SPL after a fight on ST Community see here the discussion https://drive.google.com/open?id=1uly44sRYAOdAUVoBpOGA6h1-EefFFpVY  saved as PDF as the old forums are gone. So I am also making my own CubeMX kinda application for Linux and UNIX systems...
« Last Edit: December 13, 2018, 04:10:54 pm by Vasi »
 

Offline fab672000

  • Newbie
  • Posts: 9
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #62 on: February 23, 2017, 01:47:33 am »
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, 03:15:08 am by fab672000 »
 
The following users thanked this post: EEVblog

Offline Darren

  • Newbie
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #63 on: March 07, 2017, 12: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, 04:32:43 am »
...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

  • Newbie
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #65 on: March 07, 2017, 11:42:19 am »
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: 6459
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #66 on: March 07, 2017, 12: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

  • Newbie
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #67 on: March 07, 2017, 12: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: 2365
  • Country: de
    • Frank Buss
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #68 on: March 07, 2017, 01:27:53 pm »
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #69 on: March 07, 2017, 01:58:08 pm »
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 07, 2017, 02:12:57 pm by janoc »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #70 on: March 07, 2017, 02:09:19 pm »
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 07, 2017, 02:15:42 pm by janoc »
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #71 on: March 07, 2017, 02:13:53 pm »
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: 2365
  • Country: de
    • Frank Buss
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #72 on: March 07, 2017, 02:20:19 pm »
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
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #73 on: March 07, 2017, 02:21:51 pm »
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

  • Newbie
  • Posts: 7
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #74 on: March 07, 2017, 03:01:07 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf