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

0 Members and 2 Guests are viewing this topic.

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5833
  • Country: nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #75 on: March 07, 2017, 03:02:34 pm »
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: 3496
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #76 on: March 07, 2017, 04:54:59 pm »
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

  • Super Contributor
  • ***
  • Posts: 2144
  • Country: ca
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #77 on: March 07, 2017, 08:08:33 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.

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: 3108
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #78 on: March 07, 2017, 10:12:37 pm »
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: 3
  • Country: au
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #79 on: May 03, 2018, 09:04:30 am »
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: 3108
  • Country: fr
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #80 on: May 03, 2018, 07:04:52 pm »
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.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4838
  • Country: gb
Re: EEVblog #900 - STM32 ARM Development Board
« Reply #81 on: May 03, 2018, 09:03:50 pm »
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