ARM begginer questions

[SirNick]

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't entirely understand 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 helps immensely, thank you. 

[westfw]

I still don't entirely understand the significance of CMSIS

Me 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.

[SirNick]

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!

[dannyf]

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.

[Kjelt]

Little or big endian is a choice with Arm 

[SirNick]

Understood, but I assume it's not something that can usually be switched on any particular implementation.

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.

[nctnico]

Little or big endian is a choice with Arm 

Are you sure? Maybe the early ARM microcontrollers could be switched but every ARM I have used is little endian by default.

[westfw]

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:

15 ENDIANESS
Data Endianess
The Stellaris implementation uses only little-endian mode so this is cleared to 0.

[gocemk]

This is from "The Definitive Guide to ARM Cortex M3-2014":

The Cortex-M3/M4 processors can operate in both little endian or big endian mode. However, almost
all microcontrollers will be designed for either little endian or big endian, but not
both. The majority of the Cortex-M microcontroller products use little endian.

[Kjelt]

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 

[dannyf]

This is from "The Definitive Guide to ARM Cortex M3-2014":

Doesn't seem to be that definitive,

[westfw]

["The Definitive Guide to ARM Cortex M3-2014"] Doesn't seem to be that definitive

That'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. :=(

[SirNick]

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 they meant 32.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's no place for ballpark figures in engineering reference documents.

[dannyf]

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.

[SirNick]

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*

[westfw]

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.

[nctnico]

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.)

That is completely normal. Every more complex chip has a datasheet with the electrical specifications and a user manual for the software side.

[Sailor]

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.

[dannyf]

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.

I 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.

I'm a hardware guy, not software.

That may explain it.

[nctnico]

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.

[westfw]

NXP's user manuals actually contain a large section (over 80 pages!) about the ARM Cortex core

Um, I'm looking at http://www.nxp.com/documents/user_manual/UM10562.pdf and 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.)

[SirNick]

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.

[nctnico]

NXP's user manuals actually contain a large section (over 80 pages!) about the ARM Cortex core

Um, I'm looking at http://www.nxp.com/documents/user_manual/UM10562.pdf and 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.)

The user manual for the LPC1100 series has an 80+ page chapter on the ARM Cortex core.

[westfw]

The user manual for the LPC1100 series has an 80+ page chapter on the ARM Cortex core.

[The UM for LPC408x doesn't]

Well - 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!

[andersm]

ST have a 250-page STM32F3 and STM32F4 Series Cortex®-M4 programming manual that 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."