Experiences with different ARMs

[Dago]

I have been using 8bit microcontrollers so far for all my hobby and work projects. I'm currently working on an induction heater controller where I put a STM32F303 Cortex-M4 ARM to get to learn how to use ARMs as well (plus might have some more computational requirements depending on what I end up doing).

I chose STM32 because they seem to be the most common and have gcc support.

So far I'd say my experience with STM32 has not been too positive... The ST headers are inconsistent and messy, the pin layout of the microcontroller was a mess (whats the use of having alternate pins for a function if all the pins are like next to eachother?), the datasheet is a mess, there are no examples on how the registers are supposed to be configured to get the desired functionality...

Like for the advanced-control timer module the datasheet pretty much lists what the timer can do and gives some pretty vague advice on what you are supposed to do with the registers.

I checked the FlexTimer portion of Kinesis series ARMs from Freescale and the timer module had ~120 registers (!!). Didn't have time to delve too deep to the datasheet, not sure if it's any easier to use than STM32 which have about 24 registers for the advanced-control timer. The features looked quite comparable in both (if not slightly better in the STM32).

I pretty much started re-writing the header and configuration functions for the HW because the ST headers just generally bug me. Hobby project after all and that's what I felt like doing I also heard that the headers are quite buggy and I'd rather fix and debug code I wrote myself than by someone else.

I'm just generally interested in your experiences with ARMs, are there any ARMs that have nice and consistent documentation (like Atmel MCUs)?

[mrflibble]

If you like the STM32 silicon but are fed up with the libraries provided by the ST summer intern, then you might want to take a look at ChibiOS. It supports several other platforms, but stm32 support is particularly good. And if you are concerned about memory footprint (it being an RTOS and all that), it's actually fairly light weight.

My advice would be to use the ST libs a bit longer until you are REALLY fed up with it, and then make the switch to chibios. That way you won't even notice the learning curve.

[nctnico]

A long time ago I looked at several ARMs and the ones from NXP came out best so I have been using these ever since. The biggest advantage turned out to be that NXP keeps their peripherals mostly the same so code can be shared between many controllers. IMHO ST is looking too much at making a cheap product instead of making a good product with an elegant design. What I also like about NXP microcontrollers in general is that they can be programmed over the serial port so there is no need to 'waste' pins on a JTAG interface.

[dannyf]

The ST headers are inconsistent and messy,

Not sure what that means.

the pin layout of the microcontroller was a mess (whats the use of having alternate pins for a function if all the pins are like next to eachother?),

It is actually an improved version over prior chips (F1 for example). Yeah, it is not as flexible as the remappable pins on PIC24F but quite flexible in my view.

the datasheet is a mess,

Fairly good from my perspective.

there are no examples on how the registers are supposed to be configured to get the desired functionality...

They did talk extensively about how each module works and which bits do what. It will just take you time to understand it.

If you want code examples, look into the libraries.

The only firm that does provide examples (did actually) was Luminary.

I checked the FlexTimer portion of Kinesis series ARMs from Freescale and the timer module had ~120 registers (!!).

Use PE there. It is the best code generator / configurator I have seen.

I pretty much started re-writing the header and configuration functions for the HW

That's a dangerous route to go down.

A few alternatives:

1) Use RTE in Keil 5. It is not complete yet but very promising.
2) Use STM libraries: can be easily ported from chip to chip with minimal changes.
3) Use a piece of middleware to wrap around the STM library. When you get more time / comfort with the peripherals, you can link in your own routines that use direct register access.

I'm just generally interested in your experiences with ARMs, are there any ARMs that have nice and consistent documentation (like Atmel MCUs)?

Both NXP and TI do a good job in documenting their chips. ST is not far behind.

Your experience sounds more like a beginner's shock: being overwhelmed by the complexity of the chips. The complexity is needed because the flexibility / power of those peripherals.

To mitigate that, consider a better approach to programming and look into the libraries.

[Dago]

The ST headers are inconsistent and messy,

Not sure what that means.

the pin layout of the microcontroller was a mess (whats the use of having alternate pins for a function if all the pins are like next to eachother?),

It is actually an improved version over prior chips (F1 for example). Yeah, it is not as flexible as the remappable pins on PIC24F but quite flexible in my view.

the datasheet is a mess,

Fairly good from my perspective.

there are no examples on how the registers are supposed to be configured to get the desired functionality...

They did talk extensively about how each module works and which bits do what. It will just take you time to understand it.

If you want code examples, look into the libraries.

The only firm that does provide examples (did actually) was Luminary.

I checked the FlexTimer portion of Kinesis series ARMs from Freescale and the timer module had ~120 registers (!!).

Use PE there. It is the best code generator / configurator I have seen.

I pretty much started re-writing the header and configuration functions for the HW

That's a dangerous route to go down.

A few alternatives:

1) Use RTE in Keil 5. It is not complete yet but very promising.
2) Use STM libraries: can be easily ported from chip to chip with minimal changes.
3) Use a piece of middleware to wrap around the STM library. When you get more time / comfort with the peripherals, you can link in your own routines that use direct register access.

I'm just generally interested in your experiences with ARMs, are there any ARMs that have nice and consistent documentation (like Atmel MCUs)?

Both NXP and TI do a good job in documenting their chips. ST is not far behind.

Your experience sounds more like a beginner's shock: being overwhelmed by the complexity of the chips. The complexity is needed because the flexibility / power of those peripherals.

To mitigate that, consider a better approach to programming and look into the libraries.

Thanks for the responses!

Regarding the automatic code generators and what not, for (especially) learning I'm bit of a purist, I dislike IDEs and all kinds of automatic tools because they tend to be a "black box" which just do something and I don't know what. Might use them for work stuff when I actually have to get something done but for learning I tend to lean towards a plain toolchain that does exactly what I command it to. They are nice AFTER you know what they do or what the system does underneath.

The ST headers are inconsistent and messy,

Not sure what that means.

Means that after reading I basically had loads more questions and almost zero answers Much more complicated than say AVRs timer module yes but still similar amount of text explaining the module. Also spotted mistakes even with a cursory glance.

I've heard lots of good things about ChibiOS yes but seems like a sledgehammer for most stuff. Definitely gonna use it when I have a suitable application.

I kinda agree rewriting the headers might not be the best idea if I'd have a real pressure to get something done but for learning it has been great. debuggerSkills++

[Jeroen3]

Don't forget Atmel AVR datasheets have been written for dummies. Since a lot of "new" people use their 8 bit stuff. (refering to Arduino, and atmega being the entry-level standard on universities)

ST and NXP expect you know what you want to do before you refer to their "reference manual". Also don't forget the read the app notes. Those are key in understanding peripherals.

Where NXP has relatively simple peripherals, which sometimes requires some additional software.
ST has complex peripherals, but with st-standard-perhiperal-drivers. Where the C file itself describes how you should use it. Basically nothing much more than some C wrapper around the peripheral since you still need to load the peripheral structure yourself.

ChibiOS isn't a sledgehammer, it is a Swiss army knife. If you do not need something, just fold it back in using the conf.h files.

Dannyf is right, you're experiencing "beginner's shock", this is and will always be an issue since there are steep learning curves involved. Not everything is an Arduino.

[dannyf]

Regarding the automatic code generators and what not, for (especially) learning I'm bit of a purist,

I would encourage you to take a look at PE - it is exceptionally well done. Night and day from ST's Cube.

Means that after reading I basically had loads more questions and almost zero answers Much more complicated than say AVRs timer module yes but still similar amount of text explaining the module.

Unfortunately, there is no cure for that,

I think after a while, you will get used to it. The reliance on the libraries helps a little bit. It is basically the price you pay for the power in those chips.

[poorchava]

I use mainly ST ARMs and they are pretty good when you get used to some of the stuff they do.

As for the libraries being bad, but it depends on particular peripheral in question. For example library functions for NVIC, EXTI, RCC are very useful, GPIO one is good only for configuration, and ADC and TIMER libraries completely suck and are next to useless.

I find their documentation quite good, but you need to look carefully at pictures and diagrams too, as they quite often contain valuable information that can't be found in text.

Next good thing about STM32s is that there is a completely free IDE (CooCox) with no code limitation, while there is none for NXP (at least that was the case last time I checked).

Sent from my Samsung i9100 by Tapatalk

[andyturk]

I've used ST's M3 and M4 parts on a few projects and like them just fine. The pin configuration *is* a pain in the butt though. An added level of frustration comes in when you re-juggle which peripherals you're using (to deal with a pin assignment problem), spin your boards, and then while you're writing firmware, discover that you've accidentally chosen two peripherals that share a DMA channel. Ouch. Don't do that.

On the positive side, ST has a wide variety of different configurations to choose from and the footprints for each package are almost identical. I.e., if you're using a STM32 in a LQFP-64 package, you can solder just about any of their 64-pin mcus to the board and have it work (with a small amount of handwaving for decoupling caps).

I second mrfibble's recommendation for ChibiOS. In fact, it's what caused me to look at STM32 chips in the first place. You basically never need to touch the stinky written-by-interns code that ST provides. You can buy one of ST's discovery boards ($15) to start with and then put one of the dozens of ChibiOS examples on there. I think there's even some sort of Eclipse plug-in that lets you see which threads are running.

Anyway, back to ARMs. ST is good. The nRF51 series from Nordic Semiconductor is well done if you need to do something with Bluetooth. It's a Cortex M0 where about half the chip's resources are devoted to Bluetooth and half are left for your application. Their BLE stack seems really well-written and it removes a lot of the pain of building a BLE device.

I've also been playing with Cypress' PSoC5LP. It's a strange and magical beast that's part CPLD, part analog SoC with a Cortex M3 core holding it all together. I had some problems with earlier version of their IDE (which is *required* to use the chip), but now I can actually do builds and run a debugger under OS X and use the IDE (Windows only, inside a VM) only to do the routing magic. It's a very cool chip though.

[nctnico]

I use mainly ST ARMs and they are pretty good when you get used to some of the stuff they do.

Next good thing about STM32s is that there is a completely free IDE (CooCox) with no code limitation, while there is none for NXP (at least that was the case last time I checked).

For NXP there is CoIDE which I never tried because I have been using plain Eclipse+CDT for writing microcontroller software. So yes, there is a free IDE for any microcontroller supported by GCC.

[Bored@Work]

I'm just generally interested in your experiences with ARMs, are there any ARMs that have nice and consistent documentation (like Atmel MCUs)?

Short answer: No.

These MCUs are a completely different ball game than classic 8-bit stuff. One reason I always find it so funny when people argue that everyone should use 32 bit ARM core MCUs, because 8-bit is so old school and the ARMs have infinite more power.

Documentation of these ARM MCUs is typically a mess. Independent of the manufacturer of that MCU. One reason is that all manufacturers buy the core from ARM and build an MCU around it. They probably don't 100% understand what is going on in the core. So how should they document it? Then they bolt their own periphery to the core. And an underpaid, overworked technical writer has to describe this in a thousand pages of documentation. With little or no input from the original designers. And the input they get is probably already terse and written "for those in the know". And once they are done the marketing clowns and and useless managers mess their documents up in reviews.

And like others have written, I also think these driver libraries are typically written by the summer intern or the lowest bidder from Ebonia. Not only the ST libraries, but every of the ARM manufacturers I know has this incredible junk libraries. The manufacturers are in the hardware business, they don't understand software, they don't understand robust software practices, they don't want to pay for it, they don't understand the purpose of high level languages and the value good software adds to their product. To them every simple piece of software appears to be a giant problem and mystery. They would be extremely glad if the requirement for software would go away and they could just shift hardware.

[BTW, even the 8-bit MCU manufacturers screw up their software. Atmel has that giant piece of junk called ASF.]

If you decide to use a library you should plan for significant time to debug the library and not just your code. If you don't use a library and just program MCU registers directly you have to plan for significant time to figure out which registers when, why, how, and what value. A mixture of studying the documentation, studying library code, even if you don't use the library, knowledge and intuition is needed to make this work.

[nctnico]

Did you ever read an ARM datasheet + user manual? The documentation for (most) NXP's Cortex Mx ARM controllers contains a large section on the core and instruction set besides a good explaination of how the peripherals work. NXP also offers a large number of examples on how to use the peripherals. It isn't hard to copy&paste your own application starting from an example.

[Kjelt]

The documentation of the cortex core can be found with Arm. There is a lot of documentation!
The one important thing most forget is to find out which version of the core the manufacturer has licensed, there are some minute differences esp. In performance and small bug fixes between versions which can be relevant.

[nuno]

PSoC4 is not a very powerful ARM, but it was the only one I felt I would like to try - and I really liked it. To start, it has no restrictions on the IDE nor on the code generated by it, and the IDE is 100% free. It uses GCC underneath, although it can generate files to compile with Keil and some other commercial toolchain. The programming interface is documented. Cypress has a $5 prototyping kit and a $25 dev board.
Then the development is a game changer. You don't need to use the registers if you don't want to, you draw a schematic and the IDE generates an API for you, for the schematic components you wish (for all, by default). Many components have "wizard"-like configuration. The help for a component is a single file you can access from the local menu. This architecture has, besides the Cortex M0, some programmable logic and a few pure analog devices (a pair of ampops and voltage comparators, some analog routing). The programmable logic allows you to add stuff like simple gates or registers to your schematic (implemented inside the chip, as hardware). Give it a try.

[zapta]

If you like the STM32 silicon but are fed up with the libraries provided by the ST summer intern, then you might want to take a look at ChibiOS.

Product looks good. Licensing scheme sucks.

[westfw]

Atmel AVR datasheets have been written for dummies. Since a lot of "new" people use their 8 bit stuff. (refering to Arduino, and atmega being the entry-level standard on universities)

Nonsense.  AVR datasheets are approximately the same as they were when they first started shipping in 1997, LONG before arduino.   They're pretty good datasheets because they were out to get Microchip, and Microchip PIC datasheets are pretty good, too.

I actually found the TI Tiva datasheet pretty good; more complete and less "for information on the XXX peripheral, download the XXX peripheral guide.  For information on the instruction set, download the documents from ARM."  Also, for each peripheral, a quick summary of how to initialize it.  Some of this may be left over from Stellaris; usually I find TI datasheets "weird."

[poorchava]

I use mainly ST ARMs and they are pretty good when you get used to some of the stuff they do.

Next good thing about STM32s is that there is a completely free IDE (CooCox) with no code limitation, while there is none for NXP (at least that was the case last time I checked).

For NXP there is CoIDE which I never tried because I have been using plain Eclipse+CDT for writing microcontroller software. So yes, there is a free IDE for any microcontroller supported by GCC.

CoIDE supports only a few NXP ARMs. I've heard that there are problems with using LPCLink too.

[free_electron]

ST has a pin config wizard. You get to see a graphic representation of the chip. Simply click on a pin and tell it what peripheral you want to have there and how it should be initialised.

It writes the startup code for you. With documentation. You can learn a lot from that tool.

Second, download IAR kickstart and use the header files from that tool. The only maintained libraries are the ones used with either Keil or IAR. Others are lagging behind because there is no demand for them. The fact of the matter is : anyone in the industry that buys these parts in volume uses either Keil or IAR. You can grumble about it, but that is how it works.

[mikeselectricstuff]

ST has a pin config wizard. You get to see a graphic representation of the chip. Simply click on a pin and tell it what peripheral you want to have there and how it should be initialised.

It writes the startup code for you. With documentation. You can learn a lot from that tool.

Second, download IAR kickstart and use the header files from that tool. The only maintained libraries are the ones used with either Keil or IAR. Others are lagging behind because there is no demand for them. The fact of the matter is : anyone in the industry that buys these parts in volume uses either Keil or IAR. You can grumble about it, but that is how it works.

IAR also include a LOT of examples, usually several for each chip they support, usually targetted at specific devboards so they work "out of the box", which is very handy when exploring a new part, as having "anything" that compiles & works saves a lot of messing about.

[dannyf]

CoIDE supports only a few NXP ARMs.

True. However, you have the default option to compile them as ARM CMx chips and then put the device header files in the user space.

Alternatively, you can modify the start-up files for similar devices (even from other toolchains).

I've heard that there are problems with using LPCLink too.

I can report that jlink works flawlessly - I haven't met a person using lpclink in my whole life.

[TinkeringSteve]

Dago, if you're initially confused by the reference manual (you got that, not just the datasheet, right?), go to ST's site for that MCU series and get all the app note PDFs and example project *.zip files on there!
I haven't used that particular MCU before, but other STs, and they had numerous app notes and stuff.

Just note that the reference manual for the MCU describes things using the CMSIS library, the bare bones HAL by ARM shared between the different chip implementers (maybe then slighly customized).
The (slightly higher level) ST library, at least for the lower end STM32's like f100, were poorly documented back then, from what I've heard the libs and docs for the M4 are supposedly better, somewhat.

[dannyf]

were poorly documented back then,

They were fairly well documented, to me. And the F4 lib routines are similarly documented.

Their lack of examples utilizing those modules and a newbie's inability to understand the code may contribute to their poor reputation.

CoIDE does a very good job in terms of providing examples that are context sensitive. And there are tons of such examples from within the IDE.

[SirNick]

All the platform needs is a good orientation.  The datasheets aren't great, but they're probably sufficient once you are a little familiar.

Another thing that would help is a simple reference schematic for each part showing recommendations for power supply, clocking, and any tricky peripherals (e.g., USB SoftConnect) like you would find in any IC datasheet.  A well-documented dev board would be OK too.  (Although you still may not immediately see the difference between optional components and the bare-bones requirements.)

In most cases, it's pretty standard fare, but I had some initial questions that took a while to find answers to.  Here are some examples: V3.3 and the pins that supply internal 1.8v core regulators -- both OK with just a typical 100nF decoupling cap, or do I need larger caps and/or some isolation?  Does the RTC crystal need load caps, or is there sufficient load through the oscillator pins?  Is it recommended to tie USB VBus directly to the Vbus_detect pin, or should I clamp it with a resistor and Zener?  (It is a 5v tolerant pin, but who knows what's going to happen on the bus power rail.)  Does the JTAG Reset pin go to MCU Reset or JTAG TRst?  Does it need a pull-up?

A lot of those questions aren't just dumb newbie things.  The official answer in many cases is: "It depends."  Most sources tell you to look at the manufacturer's documentation.  E.g., JTAG requires pull-ups, but they "may" be internal.  Same with the RTC load caps -- required, but possibly not as external components.

It must be tough, as a vendor, remembering what it's like on Day One with a new MCU, because most of them seem oblivious to the fact that their potential users haven't been present in all those internal design meetings.  No one's born with that knowledge, and coming from other platforms, or even other vendors' take on the same platform, doesn't necessarily give you anything more than a "feel" for what's correct.

[Jeroen3]

The examples you name are related to EMC compatibilty. This is a very fuzzy field of design.

All the vendor can do is supply an Example or Recommendation, based on their testing/characterization setup.
So far I've only seen very detailed guidelines on the LAN8720 chip, multiple documents: Schematic, Routing, Placing checklist. Yet with MCU's this is highly dependent on the target application and thus requires some empirical design.

[nctnico]

A bit offtopic: I don't fully agree. The problem is that good rejection of interference often has degraded signal quality as a price tag. Most circuits shown in applications notes won't pass EMC testing and will have problems (defects) when there are spikes at the input or make the wiring emit too much radiation.

As a general rule you have to use TVS diodes for power and signal and a common mode choke on USB signal lines.

For ethernet you also need TVS diodes although there is little concensus on what kind of ethernet filtering is necessary. The transformer doesn't filter enough even if it has a common mode filter. In my experience the best is to use common mode chokes or ferrite beads with a Z of 30 Ohms (max) at 100Mhz. But it also depends on the ethernet chip. Many 'modulate' the ethernet signal with a 125MHz clock so you have a lot of harmonics of that clock in the signal lines.

[SirNick]

Aw man, I wasn't even thinking EMC compliance.. just stability.

Ever feel like the learning curve of electronics is kinda like climbing a mountain, just to find out that, when you reach the top, you're actually just standing on a plateau that was obscuring the real mountain behind it? 

PS: Those LAN8720 app notes are fantastic.  I'm using a similar Micrel part on a design I'm working on now, and should probably go back and make some of the suggested changes recommended in the SMSC docs.  Awesome, thanks for name-dropping that one.