ARM begginer questions

[exapod]

Thank you very much for all this help.
For the moment i will try coocox and reading the "Discovering the STM32" book.

[dannyf]

Just getting st-link and the right board etc. setup for CoIde up and running could take a lot of time for someone who has never used the environment before

My experience has been the other way around.

Downloading CoIDE + the gcc-arm, and setting up the compiler in CoIDE -> done in 10 minutes on a slow connection;
Setting up a project in CoIDE + CMSIS + peripheral libraries and get them to compile without error -> 5 minutes;
Setting up st-link and downloading the code + starting up debugging -> 1 minute.

Figuring out all of that and doing it in Keil / IAR can be an endeavor that lasts days or weeks, for a newbie. My projects are probably more complex than an average project but If I were to start a virgin project (I will explain that latter) in Keil / IAR, I would take me easily 10  - 15 minutes to get it going.

Now, I typically don't start virgin projects on Keil / IAR: I have created multiple project templates where everything is already set-up so I could simply copy them over and I am good to go.

The project wizard on CoIDE is best I have seen, even among the commercial products.

[gocemk]

Just getting st-link and the right board etc. setup for CoIde up and running could take a lot of time for someone who has never used the environment before

My experience has been the other way around.

Downloading CoIDE + the gcc-arm, and setting up the compiler in CoIDE -> done in 10 minutes on a slow connection;
Setting up a project in CoIDE + CMSIS + peripheral libraries and get them to compile without error -> 5 minutes;
Setting up st-link and downloading the code + starting up debugging -> 1 minute.

Figuring out all of that and doing it in Keil / IAR can be an endeavor that lasts days or weeks, for a newbie. My projects are probably more complex than an average project but If I were to start a virgin project (I will explain that latter) in Keil / IAR, I would take me easily 10  - 15 minutes to get it going.

Now, I typically don't start virgin projects on Keil / IAR: I have created multiple project templates where everything is already set-up so I could simply copy them over and I am good to go.

The project wizard on CoIDE is best I have seen, even among the commercial products.

I had EXACTLY, EXACTLY the same experience. Right now, a friend of mine who bought the STM32F429 board (which is still not supported by CoIDE) is experiencing the same problem with Keil. When you are learning new MCU, you need to build new projects again and again,  because they are relatively short (get UART to work, get the SPI to work, and so on...). Keil is intended for professional use: You spend 10-15 minutes to start a new project (all the includes, sources, drivers, etc...) but then you work on that project for days, weeks or even months.

[jaxbird]

Just getting st-link and the right board etc. setup for CoIde up and running could take a lot of time for someone who has never used the environment before

My experience has been the other way around.

Downloading CoIDE + the gcc-arm, and setting up the compiler in CoIDE -> done in 10 minutes on a slow connection;
Setting up a project in CoIDE + CMSIS + peripheral libraries and get them to compile without error -> 5 minutes;
Setting up st-link and downloading the code + starting up debugging -> 1 minute.

Figuring out all of that and doing it in Keil / IAR can be an endeavor that lasts days or weeks, for a newbie. My projects are probably more complex than an average project but If I were to start a virgin project (I will explain that latter) in Keil / IAR, I would take me easily 10  - 15 minutes to get it going.

Now, I typically don't start virgin projects on Keil / IAR: I have created multiple project templates where everything is already set-up so I could simply copy them over and I am good to go.

The project wizard on CoIDE is best I have seen, even among the commercial products.

I have nothing against CoIde (I think it's great), but for a beginner not being able to load the sample projects provided by the manufacturer is IMO a big disadvantage at the early stage of picking up a new platform.

Actually I am much against the way the Keil uVision organises the project content (pretty awful IMO), but it does work and you can load the complete platform demo workspace with all samples and compile/program/modify at will within a few minutes of installing it.

First time you start using a new platform it's pretty useless to be able to easily create a new project. What you need is the ability to run and modify code to observe behavior.

[dannyf]

but for a beginner not being able to load the sample projects provided by the manufacturer is IMO a big disadvantage at the early stage of picking up a new platform.

Not sure which sample projects you are talking about but there are plenty sample projects, from OEM or user supplied, available in CoIDE. The discovery demo projects are not readily available in CoIDE but they can be easily imported - as the libraries themselves are already in CoIDE and you just have to import code in user space.

The ability to check and sample other people's projects in CoIDE is very good, particularly for a newbie getting started.

[jaxbird]

but for a beginner not being able to load the sample projects provided by the manufacturer is IMO a big disadvantage at the early stage of picking up a new platform.

Not sure which sample projects you are talking about but there are plenty sample projects, from OEM or user supplied, available in CoIDE. The discovery demo projects are not readily available in CoIDE but they can be easily imported - as the libraries themselves are already in CoIDE and you just have to import code in user space.

The ability to check and sample other people's projects in CoIDE is very good, particularly for a newbie getting started.

All the Discovery boards (AFAIK) come with a "Firmware" package, that contains lots of samples for the major hardware features packaged up in a nice workspace for the most popular (IAR, Keil etc) commercial environments and compilers.

You can load this workspace (in the supported environments) and easily play with samples for IO, DAC/ADC etc. etc.

[dannyf]

None of those demo programs are readily available in CoIDE, to the best of my knowledge. All of them can be easily imported into CoIDE and compiled and downloaded to the chip - as the peripheral libraries are already in CoIDE.

You can load this workspace (in the supported environments) and easily play with samples for IO, DAC/ADC etc. etc.

They actually don't allow you to play with the peripherals - they come in as one giant project with inter-linked code pieces. They do allow you to see how those library pieces are used to achieve certain functions - CoIDE has tons of samples for that.

[jaxbird]

None of those demo programs are readily available in CoIDE, to the best of my knowledge. All of them can be easily imported into CoIDE and compiled and downloaded to the chip - as the peripheral libraries are already in CoIDE.

You can load this workspace (in the supported environments) and easily play with samples for IO, DAC/ADC etc. etc.

They actually don't allow you to play with the peripherals - they come in as one giant project with inter-linked code pieces. They do allow you to see how those library pieces are used to achieve certain functions - CoIDE has tons of samples for that.

These are the samples offered for the stm32f4:



They are all in a workspace that can be loaded/compiled/modified/programmed/run in all the supported environments.

For CoIde, all I got initially was a Blinky example that didn't work.

[dannyf]

To convince myself that it can be done quickly, I ported the stm32vl discovery demo program to CoIDE, starting fresh.

From start to finish, maybe a couple minutes? The biggest was to check all the library packages in (I don't need them all but didn't want to waste time trying to figure out which ones I need and which ones I don't), make a change to stm32vldiscovery.h to include rcc/pwr/gpio/exti/misc.h files (due to how projects are set up differently in CoIDE vs. Keil).

Hit compile and I am done.

I am sure porting others isn't much different / difficult.

[jaxbird]

To convince myself that it can be done quickly, I ported the stm32vl discovery demo program to CoIDE, starting fresh.

From start to finish, maybe a couple minutes? The biggest was to check all the library packages in (I don't need them all but didn't want to waste time trying to figure out which ones I need and which ones I don't), make a change to stm32vldiscovery.h to include rcc/pwr/gpio/exti/misc.h files (due to how projects are set up differently in CoIDE vs. Keil).

Hit compile and I am done.

I am sure porting others isn't much different / difficult.

But surely you are no beginner with any of these environments .. Actually I expect you are quite experienced 

Put yourself in the position of someone who've just downloaded CoIde for the very first time after just receiving their much expected discovery ARM board in the mail. Excitingly waiting to get some code running.

First hitch of many is actually discovering that they need a gcc compiler to get anywhere.

After that they need to start importing the header files for the board they want to learn, and perhaps try to actually get something to compile. Not a simple task when you don't know what you are looking for.

That is why I still think there is much value in just taking the initial 300MB or whatever, download hit and run one of the officially supported environments, at least until you become familiar with the damn thing.

[nctnico]

You make it sound like designing a rocket for going to the moon from scratch. There are probably tons of tutorials on how to set things up.

[dannyf]

Actually I expect you are quite experienced 

You are too kind. On a good day, I am barely average. Most of the time, I switch between watching the olympics and doing a little work so I am not exactly there.

I cannot dispute your experience, nor your view. But I think the concerns for CoIDE's learning curve is exaggerated.

This is from a person who makes a living off of Keil / IAR.

[jaxbird]

You make it sound like designing a rocket for going to the moon from scratch. There are probably tons of tutorials on how to set things up.

I don't recall any rocket references .. but yeah, online random tutorials are often outdated or incomplete and unreliable  .

Surely I'm saying it's all very easy, just follow the instructions provided by the manufacturer, they actually recommend downloading one of the free demo/limited environments and playing around with the samples.

[jaxbird]

Actually I expect you are quite experienced 

You are too kind. On a good day, I am barely average. Most of the time, I switch between watching the olympics and doing a little work so I am not exactly there.

I cannot dispute your experience, nor your view. But I think the concerns for CoIDE's learning curve is exaggerated.

This is from a person who makes a living off of Keil / IAR.

Nice try, I'm not that easily fooled 

[gocemk]

In my experience with STM32F3 Discovery and Keil/IAR the problem was that in the manual for the board, in the section where they describe how to setup the different IDE's (IAR, Keil, Tasking...), they forgot to mention that when starting a new project if you want to use the standard peripheral libraries, you must add "”USE_STDPERIPH_DRIVER" in the preprocessor symbols. I kept getting the "assert_parameter" while trying to compile my project. Finally i found the answer on one of the ST forums. This is not the case for the newer boards, ”USE_STDPERIPH_DRIVER" is in the manual.

Nice tutroial on how to setup the Keil IDE for STM32 boards can be found here (and it's pretty fresh too, 15-th September, 2013):

http://fabioangeletti.altervista.org/blog/set-up-keil-for-stm32-discovery-boards/?doing_wp_cron=1393009563.8081309795379638671875

[dannyf]

you must add "”USE_STDPERIPH_DRIVER" in the preprocessor symbols.

In CoIDE, once you have clicked any of the peripheral library functions, USE_STDPERIPH_DRIVER is automagically inserted into the preprocessor.

[gocemk]

you must add "”USE_STDPERIPH_DRIVER" in the preprocessor symbols.

In CoIDE, once you have clicked any of the peripheral library functions, USE_STDPERIPH_DRIVER is automagically inserted into the preprocessor.

Yup, one of the reasons i recommended it.

[dannyf]

I'm not that easily fooled

Wasn't intending to fool anyone. What I said was factually true.

[jaxbird]

I'm not that easily fooled

Wasn't intending to fool anyone. What I said was factually true.

It was meant as a cryptic compliment 

Anyway, I believe we have successfully covered pros and cons of various approaches in getting started with STM32

Now the OP got some insights and opinions on what path to choose right out of the box 

[Ribster]

USE_STDPERIPH_DRIVER is automagically inserted into the preprocessor.

Automagically 

I'm using plain Eclipse (CDT version) with the libraries on a mac.
Works fine for me.
I love how Eclipse takes care of everything automagically when you hit compile.
No setting up makefile etc etc.

I started STM32 a while back and still am fiddling with the basics.
It was a huge stepup for me from AVR C.
Started out with CooCox, as someone here recommended me. Imho, it's the way to go.
They have a point where you can use KEIL etc. for the examples, but i would only use them for the examples..

Greetings

[SirNick]

Any similar recommendations for day one with LPCs?  I downloaded the Eclipse monstrosity and I think it compiled and uploaded successfully, as the LED blinking changed from two per second to one per second.  There's a lot going on that I feel like I'm in a new city without a map.  (CMSIS?  WTF is that?)  I have no doubt I could change code to get a different result, but I would like to understand what's going on to make that work.

Someone mentioned the Definitive Guide to Cortex Whatever a few pages ago.  $55 on Amazon.  Worth it?  Or is there a good intro somewhere online?  I don't need my hand held, but I would like a brief tour.  (I know gcc, can hack a Makefile, and have been doing AVR development for a little while now.)

So far, I've found a lot of "here's how to click buttons in Eclipse" tutorials.  Not at all what I'm looking for.  I need something that explains how to get from an empty canvas to a running program, and an API reference for whatever is the official support library -- like the GNU avrlibc pages, for e.g.

[dannyf]

Any similar recommendations for day one with LPCs? 

CoIDE has limited support for lpcs. You may check out lpcxpresso: a little bit crippled. or limited versions of keil / iar.

There's a lot going on that I feel like I'm in a new city without a map.

Actually fairly simple once you get used to the concept of a project, its content and its structure. After that, every IDE is roughly the same.

On top of that, if you wrap around your own way of programming, the IDE / chip actually disappear (mostly).

Someone mentioned the Definitive Guide to Cortex Whatever a few pages ago.  $55 on Amazon.  Worth it?

Worth every penny of it, if you are interested in designing chips.

Otherwise, the datasheet + compiler manual are the way to go.

[SirNick]

CoIDE has limited support for lpcs. You may check out lpcxpresso: a little bit crippled. or limited versions of keil / iar.

I got an Xpresso board and already installed the Xpresso (Eclipse) IDE.  I'm really not looking for an IDE though.  I just want to know what the LPC equivalent of (e.g.) avr/io.h is.  I can read the datasheet to determine what needs to be done to interface with the peripherals, but I could use a hint as to what should be done during startup to get the chip in working order.  (Kill the watchdog, set clock divider, stuff like that.)

Actually fairly simple once you get used to the concept of a project, its content and its structure. After that, every IDE is roughly the same.

I expect as much, but with the (working) examples I have, I'm having some difficulty telling apart what's boilerplate code and what is project-specific.  In general, it seems like the Xpresso platform is a bit of a mess right now.  They released 7.x which came with a few examples that seem to work OK.  The docs still refer to all the examples built (from what I can tell) for prior versions, because they cause some heartache when loaded into the IDE.  Then there's stuff like the pin mux util that hasn't been updated for the 100-pin variant of the LPC4078..... but that's a different complaint dept.  Anyway, if I knew my way around the platform at all, I would get more mileage out of the examples -- whether they work out of the box or not.  Right now, I feel like I'm depending on all the glue the IDE provides -- and I hate not knowing what's being done behind my back.  I want to at least understand which code files are the boilerplate support library(s) that everyone is going to use (and should be treated like a black box), and which files are bootstrap modules for the project itself that will ultimately be replaced by my own.  With the LPCX 7 examples it's kinda hard to tell, because some that look like project-specific modules do things that are usually in bookend libraries (like init.S and such) that typical linker scripts squish on to ALL compiled code in AVR land.

Otherwise, the datasheet + compiler manual are the way to go.

I have no doubt.  Just getting the hang of the terminology, which APIs and #defines to assume will always be there, and where exactly to start looking for details on all of the above.  The IDE came with some couple hundred MB of docs, IIRC.  I won't in my lifetime read all of that, obviously.    If there exists a good primer, I can save myself some time.  Otherwise I will just start climbing that learning curve, NBD.

[dannyf]

I just want to know what the LPC equivalent of (e.g.) avr/io.h is.

Depending on your approach - whether you use the library (lpc-open?) or not.

The bare-bone one is typically lpc12xx.h (for the lpc12xx series of chips and similarly for other chips). system_lpc12xx.h or files like that are cmsis header files.

If a library is used, you just need to follow the library's own convention. Typically, they break the header / source files by functionality / peripheral. So lpc12xx_adc.h would be for the adc - but you have to read the library manual to be sure.

[dannyf]

but I could use a hint as to what should be done during startup to get the chip in working order.

Each device may start up differently. But generally it is from the ResetISR(): it does some house keeping items (like the irq table), and from there, it calls SystemInit() which handles the clocks mostly, and the hidden __main() (compiler specific) and then jump to the real main() defined by the user.

Non-CMSIS start-up is rare and I don't think offered anymore on newer devices.

As to clock settings, the default is done in SystemInit(). Customizing it is very platform dependent / toolchain dependent. Usually it is done via SystemCoreClockUpdate() - in the CMSIS start-up file. Or you can write your own.