Another look into ARM

[nctnico]

I think the reason why ARM is getting so popular is because the core architecture is very similar.

Oh, I agree.  But I'm not sure that it's a VALID reason, given that peripherals can be dramatically different, even on something supposedly trivial like GPIO.  If you were programming in a HLL, a lot of that similarity would be implemented by your compiler regardless of underlying hardware.   It's also not entirely clear than CA8, CM3, and CM0 are really any more like each other than PIC32, PIC18, and PIC16 chips.  There are some pretty significant instruction set and architecture differences.

I let the C compiler deal with that. The difference in architecture aren't that big either. All the old ARM microcontrollers I've seen seen used the ARM7TDMI core which can execute regular ARM code and 16 bit thumb code. Some have multiple busses which allow the processor to keep fetching instructions while a peripheral does a DMA transfer (all this magic is completely transparent to the programmer). The newer Cortex devices have the thumb2 instruction set and an integrated IRQ controller. If you come from a controller family which has the vectored interrupt controller then the operation isn't much different. All in all Cortex Mx devices is more like an upgrade from ARM7TDMI than a radical change.

Whether the peripherals are different depends on the vendor. If I look at ST they probably are very different. The peripherals on the STR700 series are a complete joke. NXP on the other hand always had good peripherals and kept as much from the ARM7TDMI controllers as they could. To me their Cortex Mx controllers feel just like the old controllers with a new CPU under the hood.

[poorchava]

Prices for 1+ quantities from one Polish online shops (this one deals mainly in microcontrollers and embedded stuff)
-ATMega8-16AU - 5.81PLN (1.38€)
-STM32F030F4P6 - 3.68 PLN (0.87€)
-LPC1111FHN - 6.62 PLN (1.57€)
-PIC16F628 - 6.87 PLN (1.63€)

Now please give me one reason to use AVR or PIC?

[AlfBaz]

Now please give me one reason to use AVR or PIC?

For you there is probably no reason.
For me on the other hand, I can have that PIC screaming it's tits off, doing exactly what I want in under 10 minutes.

The arms on the other hand by there very nature are several orders of magnitude more complex for somebody that hasn't used them before... It'll take me ten days just to get a tool chain set up

[Spock]

I give You a few from Polish _hobbyist_ perspective :-) :

- lack of DIP packaged ARM's. I know only two of them (LPC8xx and LPC1114).
One is 8 pin, second is hard to get. When I want to make some simple hacking, proof of concept I don't want to solder chip to some breakout board that costs more than ARM chip itself,
- IDE setup - I know it should be easy but believe me from time to time I really have some issues with some chips.
I do have LPC810 breakout board and from some reason this chip won't work with Segger J-Link under Linux. Don't ask me why. I tried everything.
Lots of chips means that there is no nice and good IDE to "rule them all" (under Linux).

Those two are serious limits from my perspective.

If I need 32bit PIC32 is also quite good choice. MPLAB X works like a charm under Linux, it's complete IDE, PICkit3 works, chip can be obtained with single pieces with reasonable price (3-4 Euro/12-15 PLN) in DIP28 package.
It takes few minutes to get such chip running on breadboard.

Of course from company view all those issues are non important

[dannyf]

-STM32F030F4P6 - 3.68 PLN (0.87€)

The F0 series is very aggressively marketed indeed.

For me on the other hand, I can have that PIC screaming it's tits off, doing exactly what I want in under 10 minutes.

I can get any major flavors of chips, arms or not, screaming its tits off in under 10 seconds.

Well, maybe not 10 seconds but definitely in 30 seconds - I have accumulated a fairly large library for the standard peripherals.

- lack of DIP packaged ARM's. I know only two of them (LPC8xx and LPC1114).

Some LM3S chips are soic - but you are generally right.

- IDE setup - I know it should be easy but believe me from time to time I really have some issues with some chips.

CoIDE excels in this area. However, their support of chips is limited.

[cloudscapes]

I came in the thread to post I was considering to take the jump from PIC32 to ARM to take advantage of the speed boost, DRAM memory interfaces and the ADC boost, then I saw about the PIC32MZ! Think I'll hold on a bit longer!

[dannyf]

the PIC32MZ

Don't hold your breath: they have been talking about that for quite some time now.

In the chip business, there is no need to wait for anything: there are many alternatives.

[AlfBaz]

there are many alternatives.

I know nothing about arm processors and I'm just a hobbyist so please take this as a genuine questionremark.

If those specs are anywhere near true, then a quick cursory google search for that speed, that amount of ram, peripheral laden MCU, readily available in single chip quantities, etc etc,  there appears to be slim pickin's

[cloudscapes]

the PIC32MZ

Don't hold your breath: they have been talking about that for quite some time now.

In the chip business, there is no need to wait for anything: there are many alternatives.

This is true, about alternatives. For me personally, I had such a hard time learning the PIC32's (and still am, in many ways) that starting over on a new platform is kind of daunting. Especially as a non-pro "just hobbyist". I'm willing to wait half a year longer if it means I can keep the compiler and specific knowledge I have.

Had I been in a pro environment, with deadlines and price considerations, I probably would have already switched to ARM by now.

[dannyf]

readily available in single chip quantities

If that (ready availability) factors into any of your consideration for a chip (between ARM and 14K core chips), you would have to side with ARM: the whole point about the 14K chip is that they are *****not***** available now.

[dannyf]

I'm willing to wait half a year longer if it means I can keep the compiler and specific knowledge I have.

That is a reasonable position to take.

My personal approach to migration is to replicate my peripheral library to a new platform. I would start with the bare minimum of setting up the chip and going into a loop; from there I write pieces that operate the gpio; then software delays; then timers; usarts, spi, adc, ...

It helps if there is a vendor library: you can build your library on top of that. And in the future, you can gradually swap out the vendor library calls with equivalent register operations to gain a little bit performance and reduce overhead.

With that approach, going from a new platform to another has been quite enjoyable and in the process, you build up a library from which you build your own application code.

[dannyf]

Here is my general take on 32-bit chips vs. 8-bit chips:

1) switching to 32-bit chips makes sense for three kind of people: a) you want to make a living off the 32-bit boom - that market is literally exploding now with opportunities after opportunities; b) you want the performance - much faster chips and much richer peripherals; c) you just want to learn - enough said;

1) staying with 8-bit chips makes a lot of sense for two groups of people: a) you have a large code base in 8-bit chips -> moving would be exceedingly expensive; b) you don't need the 32-bit performance - do you really need a 144Mhz Cortex-M4 with FPU, FSMC, DMA, 24 timers, 8 usarts, 2 1MSPS adcs, etc. to blink an led?

8-bit chips are considerably inexpensive and simple to code; 32-bit chips are more complex - those that complexity can be managed fairly easily - and diverse so building up the economy of scale is more difficult there.

[0xdeadbeef]

I loved Atmel AVRs back in the nineties, but come on, a decent 32bit controller is just so much less hassle.
With an Cortex M3 or Cortex M0+, you get 32bit multiplication (typically single cycle), 32bit division (M3) and usually also 32bit timers. E.g an LPC812 on the low end or LPC1768 on the high end is so much more capable than any comparable 8bit controller that the comparison is really futile.
Ok, if you need to count cents for a commercial product, an 8bit CPU might be still worth the trouble, but for a hobby project I don't really see why I should go back to struggling with limited ALU, peripherals and resources when I can have a modern microcontroller with full debugging capabilities, free development tools etc. for just a bit more.

[quint]

Just one note to add regarding ARM Cortex M series compiler toolchains.  I've been using the GCC ARM Embedded toolchain which can be found at https://launchpad.net/gcc-arm-embedded.  This comes pre-built for Mac, Linux and Windows and is maintained as an open source project by ARM employees.  So it seems like the most likely compiler to keep up with the latest ARM processors.  I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite or Summon ARM toolchain.  So far, I've had good luck with it, including using hardware floating point on some M4 processors.

[dannyf]

I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite

2nd that. I use the same toolchain as you do and couldn't have been happier. Never understood why anyone would use Codesourcery, etc.

[andersm]

To answer my on question, the new line will be the PIC32MZ series and rumour has it that more info will be available toward the end of this year with chips available early next year and to continue with unfounded rumours 200MHz, DSP, MMU, upto 2MB flash, upto 512k ram... personally I'm excited

The Chinese-language datasheet is "available", and most of the new and updated reference manual sections can be downloaded from Microchip's own Chinese-language site, so there's not many rumours left when it comes to the hardware. The only big remaining question is the launch date (and how buggy it'll be. Their track record doesn't look good on that front.)

Software-wise Microchip have been more tight-lipped and there's been no public indication of what their support is going to look like. For instance, with the MMU the chip could run a "full" OS like Linux, but will they provide more than the basic compiler and peripheral library?

[nctnico]

I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite

2nd that. I use the same toolchain as you do and couldn't have been happier. Never understood why anyone would use Codesourcery, etc.

Perhaps Codesourcery is easier to find. Finding a precompiled GCC for linux is easy (apt-get install....) but binaries for Windows are more scarce. The first I found was Codesourcery so I used that.

[0xdeadbeef]

Not perfect, but pretty usable, based on GCC toolchain, supports several ARM families and is free:
http://www.coocox.org/CooCox_CoIDE.htm

[andersm]

I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite or Summon ARM toolchain.

The CodeSourcery toolchain has been around for far longer, so it's more known and referenced in more guides and tutorials. They also do a lot of compiler work for other companies, so they also get around that way.

[Harvs]

there are many alternatives.

I know nothing about arm processors and I'm just a hobbyist so please take this as a genuine questionremark.

If those specs are anywhere near true, then a quick cursory google search for that speed, that amount of ram, peripheral laden MCU, readily available in single chip quantities, etc etc,  there appears to be slim pickin's

Personally I haven't found anything that I couldn't do on an M4F, that didn't otherwise really need a proper operating system to handle mass storage devices and internet comms.  Once you get to the point you need Linux etc, I think you can't go past just getting a cheap off-the-shelf solution (e.g. beagle bone black, RPi), and not have to worry about dealing with DDR ram etc.  Or possibly moving to a dedicated DSP if raw number crunching is in order.

There's a few eye catching specs on the website's I've seen.  But, we're so spoilt for choice at the moment, the only thing that would make me give it a second look is when it's on Digikey/Farnell for the same price as some other option that will fill the need.

[AlfBaz]

The thing is, I knew the mx32 core, tools and libraries very, very well and this is the main source of my excitement over the possibility of this new release.

However, I know arm is the way forward and to that end I've recently taken the plunge. What's holding me up is the plethora of choices and how boring it is to compare technical products that you know little about (remember I do this for fun).

With that in mind I've decided to just pick one manufacturer, one ide/compiler and get to know that. "Armed" with that knowledge I should then be able make better choices down the road

Know I'm faced with another decision... Is CMSIS worth learning? I've always been in favour of reading datasheets and hitting the regs directly but if the variation from device to device is as great as reported by some...

[dannyf]

With that in mind I've decided to just pick one manufacturer, one ide/compiler and get to know that.

A good strategy - they are quite similiar, even between the 8-bit chips and the 32-bit chips. Once you have mastered one, the other is easy.

In the direction, I would recommend CoIDE + one of those STM32 chips it supports - it is really really good, particularly the wizard.

A close 2nd would be CCS + one of those launchpads. The TI chips are far more powerful than the ST chips, but a little bit on the buggy side so a little bit more frustration from time to time.

Know I'm faced with another decision... Is CMSIS worth learning?

CMSIS is just for the start-up and some (simple) house keeping options. I don't think compiler vendors now offer non-CMSIS start-up files anymore. It is for the most part transparent to the programmer.

A real choice is between direct register access and vendor libraries. If you are comfortable with reading the datasheet, try direct register access. Otherwise, you can use the library (which also requires reading the datasheet) and later on if you wish, you can swap out the library calls one at a time.

The TI chips have the (some of the) "library" ROM'd on the chip so that helps save a little bit of rom space.

[AlfBaz]

Thanks for the tips Danny

[AndyC_772]

In the direction, I would recommend CoIDE + one of those STM32 chips it supports - it is really really good, particularly the wizard.

I'll second this, CoIDE does make it very easy indeed to add files from the STM32 standard peripheral library to your project, and the on-line help isn't bad either.

[gmb42]

I've mentioned it elsewhere, but also have a look at ChibiStudio.  Mainly for STM32, and for use with the RTOS ChibiOS, but it is open source unlike CoIDE.

The ChibiOS community is very helpful.