ARM begginer questions - Page 1
Forum section: electronics / general

author: Unknown
author_rank: Unknown
timestamp: February 17, 2014, 11:33:30 pm
content: Hi,I have experience with almost all the microchip mcu family and now i would like to learn more about ARM. I was thinking of starting with the STM32 family of chip and buying an ST evaluation board, and the ST-LINK/V2 programmer for future standalone project (both are very cheap). Can you reccomend some books or guide to start using the ST line of mcu? Is this in your opinion a good way to start learing using the arm mcu? Should i start withe the M0 series?Thank you for the help

author: dannyf
author_rank: Super Contributor
timestamp: February 18, 2014, 01:32:45 am
content: Assuming that you will code in C (coding those chips in assembly would be crazy), I would suggest that you dive into the datasheet / reference manuals.CM3 is a middle of the road chip. CM4 more processing power and CM0 to compete more with the 8-bits. However, they mean very little for most embedded applications: you care about the peripheral, not the core.As long as you code in C.I would start in CM3 but it makes little difference.

author: dannyf
author_rank: Super Contributor
timestamp: February 18, 2014, 11:28:41 am
content: QuoteWhat if I don't want to learn about programming the ARM core? As far as I am concerned, it might as well be a green monster sitting inside that little chip. As long as it does what I wanted it to do, it doesn't matter to me how the core does it.That's part of the reason, not all, that it is crazy to code in assembly.

author: Kjelt
author_rank: Super Contributor
timestamp: February 18, 2014, 12:23:58 pm
content: If you start with a certain arm processor it is important that the manufacturer supplies the hardware abstraction layers in a software language you are familiar with. As far as I know most manufacturers incl. ST do this in C so this is a logical choice.For TS: what is the application you have in mind? If you are interested in large applications such as IP communication and/or TS LCD applications I would definitely go for the M3 (STM32F207) or M4 (STM32F4xx) cores but probably myself would go for the NXP expresso boards since their compiler is free and has a huge free codesize (i believe currently even 256k). The boards aren't that expensive either (ebay, embedded artists).

author: dannyf
author_rank: Super Contributor
timestamp: February 18, 2014, 12:32:43 pm
content: QuoteIn that regard, the TI compiler / tool is totally free and limitless if you use it with the launchpads. CoIDE offers totally free and limitless compilers also for many chips from many vendors.

author: Unknown
author_rank: Unknown
timestamp: February 18, 2014, 04:50:23 pm
content: Thank you all, i will buy this boardhttp://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1199/PF254044?s_searchtype=partnumber

author: gocemk
author_rank: Regular Contributor
timestamp: February 18, 2014, 05:23:18 pm
content: Quote from: exapod on February 18, 2014, 04:50:23 pmExcellent choice. I have the same board and i am very pleased with it. Another positive thing is that the free CooCox IDE in it's latest version fully supports the STM32F303 MCU and everything works right out the box (programming/debugging). As far as books go, i think that you can't go wrong with this one:http://www.amazon.com/Definitive-Cortex%C2%AE-M3-Cortex%C2%AE-M4-Processors-Edition/dp/0124080820Maybe it is little on the expensive side, but i think it's worth it, and the featured examples are with STM32.

author: dannyf
author_rank: Super Contributor
timestamp: February 18, 2014, 07:06:20 pm
content: QuoteThat's a good book if you want to know the inner workings of the core.It is of minimum value, and potentially a waste of time, if you want to program the core to do things, especially in C.

author: gocemk
author_rank: Regular Contributor
timestamp: February 18, 2014, 08:28:34 pm
content: Quote from: dannyf on February 18, 2014, 07:06:20 pmI strongly disagree. The book covers everything, from assembly to advanced topics using C, like DSP, RTOS, etc... And there are PLENTY examples written completely in C, especially in the chapter for ARM CMSIS-DSP library. And like i said, it's all done with the STM32F4 discovery board which is suitable for the OP.

author: dannyf
author_rank: Super Contributor
timestamp: February 18, 2014, 09:04:14 pm
content: QuoteMy point exactly: how many times do you need to write your own DSP, RTOS, etc. vs. writing your own code to drive peripherals? Even if you do use DSP/RTOS, you can do so by treating them as blackbox (CMSIS' dsp libraries or vendor supplied RTOS) without understanding its inner working.Effectively, the (C) compiler is taking care of the lowest layer for you. All you need to know is "C = A + B;", without ever understanding how exactly the core does it. In C, you know, with reasonable degree of confidence that "C = A+B;" will work, on core A, B, or C.That's the beauty of programming in a high level language. It renders the core "bland", and allows you to focus on the most value-add: your algorithm / logic, and the peripherals.

author: fagiano
author_rank: Regular Contributor
timestamp: February 18, 2014, 09:30:12 pm
content: I found this "book" very useful when I fist approached STM32s"Discovering the STM32 Microcontroller"http://www.cs.indiana.edu/~geobrown/book.pdfciaoAlberto

author: gocemk
author_rank: Regular Contributor
timestamp: February 18, 2014, 09:38:30 pm
content: Well, it all depends on what you want to learn and how much time are you willing to spend on it. If not all that information is required, then i strongly suggest "Discovering the STM32 Microcontroller" by Geo?rey Brown. The book has several examples for programming the peripherals, including examples with sensors, lcd's, etc... The best thing is that it is completely free. It is for the STM32F1 (Cortex-M3), but all principles should apply for the STM32F303.You can download it from here:http://www.cs.indiana.edu/~geobrown/book.pdfCheers.EDIT: Looks like fagiano beat me to it.

author: dannyf
author_rank: Super Contributor
timestamp: February 18, 2014, 10:00:21 pm
content: QuoteThat is a fabulous book, indeed.Some of the examples there could have been more complete. But it is a great beginner's book.

author: Unknown
author_rank: Unknown
timestamp: February 21, 2014, 02:23:24 pm
content: I donwloaded the book and bought the board. Which compiler/IDE do you suggest i start develop? GNU, IAR, Keil or CooCox ?

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 02:42:27 pm
content: Which one of the boards did you get?I've been playing with the stm32f4 board and I've found the Keil (limited) free compiler works really well as TI supplies their samples in the (among others) Keil uVision format.It's a good starting point, later on you probably want to switch to CoIde or some other free environment, to avoid the 32kB code limits.

author: Unknown
author_rank: Unknown
timestamp: February 21, 2014, 03:10:22 pm
content: The STM32F3DISCOVERY with a STM32F303VCT6. If the switch is easy i will start with the keil. Thanks

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 03:13:43 pm
content: If your intent is to use CoIDE, I would start with it. You will find that setting up a project in CoIDE is very easy and coding in both environment is almost identical.I am a big fan of CoIDE.

author: gocemk
author_rank: Regular Contributor
timestamp: February 21, 2014, 03:27:02 pm
content: Take mine and dannyf's advice and go with CooCox IDE. When i bought the STM32F3 Dsicovery a few months ago, the STM32F303 was still not supported by CoIDE, so i went with Keil. When they finally brought support for the STM32F303 to CoIDE, i've downloaded and installed it and was very impressed. Setting up a new project from scratch is much, much easier with CoIDE then it is with Keil/IAR (especially IAR). Since then, i never looked back.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 03:38:56 pm
content: Agree about the value of CoIde, but can you load the TI sample projects directly in CoIde?

author: nctnico
author_rank: Super Contributor
timestamp: February 21, 2014, 03:49:45 pm
content: Ask TI for examples which can be loaded in CoIDE. If not then don't use TI's parts. You won't miss much.

author: Unknown
author_rank: Unknown
timestamp: February 21, 2014, 03:52:57 pm
content: I will start with the CoIDE, thank you very much for the help!

author: gocemk
author_rank: Regular Contributor
timestamp: February 21, 2014, 03:54:01 pm
content: Quote from: jaxbird on February 21, 2014, 03:38:56 pmNo, ST provides examples only for IAR, Keil, Altium TASKING and TrueStudio. But it is very easy to setup a new project in CoIDE using the .h and .c files from the provided examples.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 04:01:52 pm
content: Quote from: gocemk on February 21, 2014, 03:54:01 pmSo I still think still fastest to get going with stm32 is using IAR or Keil (etc) limited versions, once you grow beyond their limitations you will easily know what path to pursue. (hint hint CoIde)

author: gocemk
author_rank: Regular Contributor
timestamp: February 21, 2014, 04:12:26 pm
content: Quote from: jaxbird on February 21, 2014, 04:01:52 pmPerhaps. That's exactly what i did, but as i've said before that was because at the time the stm32f303 was still not supported by CoIDE. Also in my class at the university we were using IAR. If the OP starts learning using "Discovering the STM32", then CoIDE will be better then Keil/IAR. (IMHO)

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 04:20:47 pm
content: Quote from: gocemk on February 21, 2014, 04:12:26 pmSure, no arguments there, once you have some familiarity and experience with the platform it's no problem switching to an environment like CoIde.But for a beginner just starting out, surely Keil or IAR limited versions are much more productive as they will be able to directly load/compile/program and modify the TI samples to easily gain some basic experience with the platform.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, time that would have been better spent playing with and modifying the provided samples instead.

author: Unknown
author_rank: Unknown
timestamp: February 21, 2014, 04:31:51 pm
content: Thank you very much for all this help.For the moment i will try coocox and reading the "Discovering the STM32" book.

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 04:32:36 pm
content: QuoteMy 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.

author: gocemk
author_rank: Regular Contributor
timestamp: February 21, 2014, 04:44:18 pm
content: Quote from: dannyf on February 21, 2014, 04:32:36 pmI 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.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 04:48:51 pm
content: Quote from: dannyf on February 21, 2014, 04:32:36 pmI 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 05:02:56 pm
content: QuoteNot 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.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 05:25:07 pm
content: Quote from: dannyf on February 21, 2014, 05:02:56 pmAll 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 05:31:36 pm
content: 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.QuoteThey 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.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 05:53:51 pm
content: Quote from: dannyf on February 21, 2014, 05:31:36 pmThese 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 05:56:44 pm
content: 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.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 06:09:36 pm
content: Quote from: dannyf on February 21, 2014, 05:56:44 pmBut surely you are no beginner with any of these environments.. Actually I expect you are quite experiencedPut 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.

author: nctnico
author_rank: Super Contributor
timestamp: February 21, 2014, 06:14:37 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 06:15:29 pm
content: QuoteYou 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.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 06:19:56 pm
content: Quote from: nctnico on February 21, 2014, 06:14:37 pmI 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.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 06:22:14 pm
content: Quote from: dannyf on February 21, 2014, 06:15:29 pmNice try, I'm not that easily fooled

author: gocemk
author_rank: Regular Contributor
timestamp: February 21, 2014, 07:16:56 pm
content: 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

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 07:20:22 pm
content: QuoteIn CoIDE, once you have clicked any of the peripheral library functions, USE_STDPERIPH_DRIVER is automagically inserted into the preprocessor.

author: gocemk
author_rank: Regular Contributor
timestamp: February 21, 2014, 07:24:52 pm
content: Quote from: dannyf on February 21, 2014, 07:20:22 pmYup, one of the reasons i recommended it.

author: dannyf
author_rank: Super Contributor
timestamp: February 21, 2014, 07:33:36 pm
content: QuoteWasn't intending to fool anyone. What I said was factually true.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 22, 2014, 12:45:07 am
content: Quote from: dannyf on February 21, 2014, 07:33:36 pmIt was meant as a cryptic complimentAnyway, I believe we have successfully covered pros and cons of various approaches in getting started with STM32Now the OP got some insights and opinions on what path to choose right out of the box

author: Ribster
author_rank: Frequent Contributor
timestamp: May 20, 2014, 11:39:23 am
content: Quote from: dannyf on February 21, 2014, 07:20:22 pmAutomagicallyI'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

author: SirNick
author_rank: Frequent Contributor
timestamp: May 20, 2014, 10:38:48 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: May 20, 2014, 11:10:20 pm
content: QuoteCoIDE has limited support for lpcs. You may check out lpcxpresso: a little bit crippled. or limited versions of keil / iar.QuoteActually 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).QuoteWorth every penny of it, if you are interested in designing chips.Otherwise, the datasheet + compiler manual are the way to go.

author: SirNick
author_rank: Frequent Contributor
timestamp: May 21, 2014, 12:58:47 am
content: Quote from: dannyf on May 20, 2014, 11:10:20 pmI 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.)QuoteI 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.QuoteI 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.

author: dannyf
author_rank: Super Contributor
timestamp: May 21, 2014, 01:22:39 am
content: QuoteDepending 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.

author: dannyf
author_rank: Super Contributor
timestamp: May 21, 2014, 01:29:32 am
content: QuoteEach 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.

author: SirNick
author_rank: Frequent Contributor
timestamp: May 21, 2014, 01:35:32 am
content: OK, so LPC-Open == avrlibc then. I remember seeing that name, but didn't really know what it was referring to. I found and read through a lot of those functions you mentioned in the example code, so that should help differentiate what's library and what's project.I still don'tentirelyunderstand the significance of CMSIS, mbed, et al., but I think the answer to that can be found easily enough with some time on Wikipedia and friends. All I needed was a place to start.That helpsimmensely, thank you.

author: westfw
author_rank: Super Contributor
timestamp: May 22, 2014, 09:46:10 pm
content: QuoteMe either, but a big part of CMSIS seems to be an attempt to define standard functions for dealing with those parts of the Cortex CPUs that are common to ALL cortex Mx chips (the parts controlled by ARM: interrupts, systick, cpu special register access, etc) Also, it puts a standardization framework around vendor-specific things as well. SystemInit() will be the function that does early system initialization, peripherals will be defined as structures with particular name format mapped into the address space, stuff like that. They same sorts of things that might be included in a company's "coding standard." Helpful, but insufficient to cover everything that you need to do.

author: SirNick
author_rank: Frequent Contributor
timestamp: May 22, 2014, 11:44:33 pm
content: Ahh OK, that makes sense. I've noticed the struct approach in a lot of code samples I've been looking through. Seems like a neat way to do it.I was off to a rough start trying to make heads or tails of any of it without a proper Welcome to LPC primer, but things are finally starting to fall into place as I read through data sheets, Wikipedia articles, application notes, various articles... I'm sure prior experience with any ARM device would probably have helped.I still have a lot to learn (don't even know if these are big or little endian yet) but I'm itching to get started. The LPC812 is a neat little micro with its arbitrarily assignable peripheral pins and all that. And the LPC4078 is the ATmega I always wanted.Cool stuff!

author: dannyf
author_rank: Super Contributor
timestamp: May 23, 2014, 12:30:05 pm
content: From a C programmer's perspective, CMSIS is really transparent to you. Think of it as the "start-up" file, a little bit more standardized.Complication with CMSIS comes in with your toolchains: some take the approach that they want to manage your strat-up, others take the approach that a project / programmer should manage the start-up.Because of that, you may have to do different things in creating / setting up / defining a project.But after that, CMSIS basically disappears from the programmer's perspective.

author: Kjelt
author_rank: Super Contributor
timestamp: May 23, 2014, 09:32:45 pm
content: Little or big endian is a choice with Arm

author: SirNick
author_rank: Frequent Contributor
timestamp: May 23, 2014, 11:27:21 pm
content: Understood, but I assume it's not something that can usually be switched on any particularimplementation.While I didn't get a single hit for "endian" in the LPC user manuals I have, some forum posts on the web seem to indicate the LPCs are Little-Endian. (And the ARM core has a neat single-instruction, 32-bit endian reversal function. Nice!) Another mystery solved.

author: nctnico
author_rank: Super Contributor
timestamp: May 23, 2014, 11:51:38 pm
content: Quote from: Kjelt on May 23, 2014, 09:32:45 pmAre you sure? Maybe the early ARM microcontrollers could be switched but every ARM I have used is little endian by default.

author: westfw
author_rank: Super Contributor
timestamp: May 24, 2014, 12:35:26 am
content: Endianness is normally controlled by bit15 of the APINT register, but an ARM implementation need not support changing the value. For example, from TI's TIVA:Quote

author: gocemk
author_rank: Regular Contributor
timestamp: May 24, 2014, 09:14:06 am
content: This is from "The Definitive Guide to ARM Cortex M3-2014":Quote

author: Kjelt
author_rank: Super Contributor
timestamp: May 24, 2014, 06:40:48 pm
content: Ok so it is possible in theory but in practice the vendors make a choice and will not let you change it, that is a shame, but I learned something again

author: dannyf
author_rank: Super Contributor
timestamp: May 25, 2014, 11:20:46 am
content: QuoteDoesn't seem to be that definitive,

author: westfw
author_rank: Super Contributor
timestamp: May 26, 2014, 05:56:00 am
content: QuoteThat's the problem. Frequently, anyway. A guide to the CPU code only describes the CPU and the "core" peripherals that are defined by ARM. On a modern microcontroller, that's a relatively small part of the overall chip. The vendor data sheets frequently describe only the vendor specific parts of the chip, and point you at ARM for basic core documentation, and there is little or no documentation that ties everything together. :=(

author: SirNick
author_rank: Frequent Contributor
timestamp: May 27, 2014, 07:35:42 pm
content: I'm seeing this myself. I got spoiled by Atmel's excellent AVR data sheets. The LPC data sheets are kind of hit and miss. Not very well organized, little bits of essential info stuck in random paragraphs, very few inline minimum code samples (like the AVR ones), barely any typical (PCB) application diagrams...Even the RTC section had me frustrated. No mention of whether load caps are needed, and what's worse, it kept referring to a 32kHz crystal. Not 32.768kHz, but 32kHz. Turns out theymeant32.768kHz like you might expect based on what everyone else uses, but hey 32kHz is close enough. You know what we meant, right?Man, there'sno placefor ballpark figures in engineering reference documents.

author: dannyf
author_rank: Super Contributor
timestamp: May 27, 2014, 07:46:31 pm
content: Atmel, NXP and Microchip all have good datasheets. I would put Freescale there too. Renesas is OK, probably due to language issues.ST and Luminary / TI have some of the worst datasheets.

author: SirNick
author_rank: Frequent Contributor
timestamp: May 27, 2014, 09:00:32 pm
content: You don't like TI's sheets? Huh.. I've always had good experiences with them. Almost all of their general purpose stuff (op-amps, regulators, logic, etc.) is well documented. I have data sheets for the Sitara processor used in the BBB and it's pretty good too.The NXP sheet for a UART IC wasn't bad -- more organized and relevant than the LPC sheets at least. Those are the only NXP parts I've used so far though. The LPC Zone videos seem to miss a lot of opportunities too. Maybe it's just that department. *shrug*

author: westfw
author_rank: Super Contributor
timestamp: May 29, 2014, 04:52:38 am
content: Huh. I remember the Stellaris datasheets being pretty bad, back when they were from Luminary Micro, but I was quite happy with the TM4C123GH6PM datasheet. Everything in one place; even an instruction set summary. (Other TI datasheets/manuals I've found to be "weirdly organized", with sections that seem out of order, or long rambles about architectural details that don't seem very important once you get through the whole manual.)OTOH, an NXP "datasheet" for LPC408x I downloaded recently was awful. Apparently you should always download the "user manual" instead, except THAT lacks "pinout" info (?!), and you need to go to arm to get info on the core (like that instruction set summary.)Atmel AVR datasheets are OK, but it's always seemed that they are missing some overall "architectural summary" that would clarify/unify things. I haven't tried to use an Atmel ARM datasheet much, yet.Historically, I've really liked the Microchip datasheets, at least if you can avoid the "download a different PDF for each section of the manual" world that they were doing for some of their 16 and 32 bit chips.

author: nctnico
author_rank: Super Contributor
timestamp: May 29, 2014, 11:09:23 am
content: Quote from: westfw on May 29, 2014, 04:52:38 amThat is completely normal. Every more complex chip has a datasheet with the electrical specifications and a user manual for the software side.

author: Sailor
author_rank: Regular Contributor
timestamp: May 29, 2014, 12:01:57 pm
content: To the ARM 'newbies' here: You really should have 'The Definitive Guide... ' on your bookshelf, unless (a) you don't know anything about electronics, and (b) you don't want to know anything about electronics, and (c) you're never going to write anything that interacts with the real world.In the beginning it will just be one of those 'gee whiz' books that sits on the shelf, but once you become comfortable with the general manner of making things happen, it has a lot to teach you. For example, most people will never make any more use of the ARM interrupt system than they did on an AVR or similar, where you were stuck with a simple 1 -> n priority arrangement. Tuck yourself up in bed some night and start reading about the NVIC... and everything that it ties into. You will never use most of the capabilities of ARM, but when you hit that funny problem you need to know just what is available to you.P.S. just in case it's not already obvious, I'm a hardware guy, not software.

author: dannyf
author_rank: Super Contributor
timestamp: May 29, 2014, 12:19:45 pm
content: QuoteI am not sure. None of those benefits are tied to the core - which the book is all about. For example, the peripherals are all vendor specific and have nothing to do with the core.I for one was given a copy of the book and I have to say that the number of times that I turned its pages can be counted on one hand,The most useful to me have been the datasheets.QuoteThat may explain it.

author: nctnico
author_rank: Super Contributor
timestamp: May 29, 2014, 01:52:57 pm
content: NXP's user manuals actually contain a large section (over 80 pages!) about the ARM Cortex core and the core related peripherals but also describes what is implemented and what not. IMHO much more useful than a generic book.

author: westfw
author_rank: Super Contributor
timestamp: May 29, 2014, 05:34:33 pm
content: QuoteUm, I'm looking athttp://www.nxp.com/documents/user_manual/UM10562.pdfand I don't see it.Two short and contentless paragraphs in section 1.7, and a 2-page appendix (chapter 40) saying which optional features are implemented/not implemented. (I'd love to be wrong, here!) (Is some other manual dramatically different? Which one? It might be a more useful "general" reference to the NXP ARM chips.)

author: SirNick
author_rank: Frequent Contributor
timestamp: May 29, 2014, 06:51:57 pm
content: Maybe I don't have enough experience with high pin count devices, and this is just normal, but the 407x/408x pinout section is probably my biggest gripe. Dozens of pages in a table format of all the possible pin functions, in port order. There are no cross-references in pin order (probably because there are 7 different packages and that would be a lot of tables) if you just need to know what pin 27 does for e.g., and no section (that I've found) that will tell you what pins provide MII / RMII, UART, SPI, i2c, CAN, etc... You gotta scroll through the whole table, pages 11 - 50. (Or, preferably, just use search. Not very friendly on a phone / tablet.)They do at least provide a pin mux tool. Except it doesn't cover the LQFP100 package.

author: nctnico
author_rank: Super Contributor
timestamp: May 29, 2014, 07:04:50 pm
content: Quote from: westfw on May 29, 2014, 05:34:33 pmThe user manual for the LPC1100 series has an 80+ page chapter on the ARM Cortex core.

author: westfw
author_rank: Super Contributor
timestamp: May 29, 2014, 10:18:10 pm
content: QuoteQuoteWell - You're right! The LPC1104 UM has an entirely adequate chapter on the core. If the other manual had had the equivalent, I wouldn't have anything to complain about! I will reserve special curses for manufacturers whose documentation is inconsistent!

author: andersm
author_rank: Super Contributor
timestamp: May 30, 2014, 06:31:31 am
content: ST have a 250-pageSTM32F3 and STM32F4 Series Cortex®-M4 programming manualthat covers the core, instruction set and core peripherals. There's also versions for the Cortex-M3 and (I assume) M0, and there's nothing vendor specific in it. It is however much more brief than "The Definitive Guide."

author: dannyf
author_rank: Super Contributor
timestamp: May 30, 2014, 10:19:46 am
content: Still, the core is largely transparent to programmers using a high level language like C.

author: gocemk
author_rank: Regular Contributor
timestamp: May 30, 2014, 10:58:28 am
content: I really don't know how dannyf got the impression that "The Definitive Guide..." is only good/useful if you only want to design a chip. The examples in the book, are almost all in C and with STM32 mcu's. It has three chapters on setting up a toolchain, one for Keil, one for IAR and one for GNU. It also has a separate chapter on debugging and Keil RTX RTOS. Right now, i'm reading through the chapter on DSP processing and it's been nothing but helpful. Also, the software porting chapter (24) is VERY helpful if you need to port code from another(older) project written on another MCU.

author: Kjelt
author_rank: Super Contributor
timestamp: May 30, 2014, 11:16:08 am
content: I personally always prefer a paper book above a digital pdf unless I have to search for something.I have this book next to my bed and although almost all is already known to me it is still refreshing my memory and fun to read.For a beginner I would advise the book above dry pdf's.It is just as with for instance the (free)RTOS. You can get all the info from the web from their website and you have pages and pages of html to spit through or you buy the book:"Using the FreeRTOS Real Time Kernel - a Practical Guide - Cortex M3 Edition"I prefer the latter but I guess it is all a question of personal taste and where to spent your $ in the end.

author: nicknml
author_rank: Contributor
timestamp: May 31, 2014, 02:02:51 am
content: I got my first ARM board (for free) a few weeks ago. It's an XMOS StartKIT. So far I've played around with the 3x3 onboard LED matrix, and bit-banged i2c and spi. I have yet to attempt to use the ADC on it. Running multiple processes in parallel is awesome! It does like all other products have its quirks. One example, is that I wanted to run a pattern on the led matrix and mess around with the on-board pushbutton as parallel processes but since the pushbutton pin and LED pins are part of the same 32-bit port, it can't be done (would have been nice if the matrix was mapped to a 9-bit port but oh well.) I'm sure there is a reason why they map so many pins to a port, but for my purposes it can make things cumbersome. I do like that there are some one-bit ports.I've been thinking about getting an ST ARM board and am curious about how much of an additional learning curve it would be compared to a StartKIT.

author: westfw
author_rank: Super Contributor
timestamp: May 31, 2014, 03:06:04 am
content: QuoteThe XMOS chips are NOT ARMs.

author: nicknml
author_rank: Contributor
timestamp: May 31, 2014, 03:11:16 am
content: Quote from: westfw on May 31, 2014, 03:06:04 amOops, thought they were.UPDATE: the SOC does contain an an ARM Cortex-M3 processor.http://www.cnx-software.com/2013/12/29/xmos-xcore-xa-octa-core-arm-cortex-m3-soc-and-14-99-startkit-board/

author: westfw
author_rank: Super Contributor
timestamp: May 31, 2014, 03:22:30 am
content: QuoteWell, huh! I missed that entirely. Thanks for checking and clarifying!

author: dannyf
author_rank: Super Contributor
timestamp: May 31, 2014, 11:03:13 am
content: QuoteNice chip. Too bad that it never caught on.

author: miguelvp
author_rank: Super Contributor
timestamp: May 31, 2014, 05:36:48 pm
content: Quote from: dannyf on May 31, 2014, 11:03:13 amI've seen it used as the USB controller for high end audio DACs up to 32bits @ 384KHz.

author: joaoc
author_rank: Newbie
timestamp: June 12, 2014, 06:15:59 pm
content: Hi,I started with the ST nucleu F0 board with the coocox coIDE.In C it went well with no major troubles, but i can't seem to compile any code with C++, the IDE doesn't even recognize the #include (some times) when it recognize then the Code completion doesn't work...This is with coIDE version 1.7.6...Any tips?

author: dannyf
author_rank: Super Contributor
timestamp: June 12, 2014, 06:45:43 pm
content: I don't think CoIDE supports c++ out of the box, though gcc/eclipse both do. You likely will have to play with the xml files to fool the ide/compiler.

author: joaoc
author_rank: Newbie
timestamp: June 16, 2014, 03:04:45 pm
content: Version 1.7.6 should...what other IDE to use?

author: westfw
author_rank: Super Contributor
timestamp: October 03, 2014, 12:47:22 am
content: QuoteSorry to update this old thread, but I spent some time talking to the XMOS folk at ARM TechCon this week, and got some clarifications:1) The StartKit board has an xCORE-A chip, which does NOT include an ARM.2) The xCORE-XA chips DO have the ARM core (XMOS was showing off a new development board for this chip.)3) The linked article confusingly reports TWO *separate* announcements from XMOS; one for the XA architecture, and one for the StartKit (which does NOT have the XA chip on it.)4) The chips with an ARM core will always have N-1 XCORE processors, because the Nth xcore is dedicated to running the interface to the ARM.

author: BennVenn
author_rank: Regular Contributor
timestamp: December 08, 2014, 12:37:52 am
content: Hi old thread,In case someone stubles upon here looking for information on ARM assembly, I'd like to suggest 'Assembly Language Programming ARM Cortex-M3' by Vincent Mahout as a fantastic reference to all things ARM assembly. Also, Keil uVision is a free development studio (compiled size limitations) which has a very good debugger. You'll spend a lot of time with the debugger when you are starting out, in particular with clock sources and peripheral setup.Don't let the many registers deter you from programming these fantastic MCU's. Once you have a template to set your clocks, NVIC and basic peripherals you'll be coding as seamlessly as you would with an AVR, with 10x the speed, peripherals, RAM and hardware math!Well worth the time to learn