Comment by gamble | Hacker News Reader

Comment by gamble | Hacker News Reader

ARM.

Seriously, Cortex-M3 microcontrollers are much more powerful than any AVR or PIC at the same price, with roughly the same level of complexity as a high-end PIC/AVR.

ARM already dominates high-end embedded systems, and is quickly penetrating the low end. Atmel and Microchip both see the writing on the wall; control of Atmel's ARM line was a major factor in Microchip's failed hostile takeover bid for Atmel several years ago. If you have any professional interest in embedded systems, it may be a better bet to invest time in ARM rather than an 8-bit architecture.

There are a few arguments left in favor of PIC/AVR: ultra low power consumption, pin count, and price for the low-end chips, DIL package availability, and support for hobbyists in the forums. I'm not sure a difference of $1/unit and a few uW/MHz is relevant for hobbyists, and the Arduino is probably a better solution for people who aren't comfortable working with SMD. (Which honestly isn't that hard, anyway...)

How do the low-end ARM devices compare to 16bit and 32bit AVR and PIC offerings?

Recently, I have been doing a lot of development for both the (8bit) AT90USB162 and the (16bit) PIC24HJ. The PIC24HJ range of 16bit PIC microcontrollers packs an awesome punch at 40 MIPS, has mostly 1-cycle instructions and two hardware SPI peripherals (which, for me, is important. On the other hand, the AT90USB162 only has one). I have been interested in ARM, though, so am wondering if it would be worth switching before I become to reliant on other microcontrollers.

I've never done any development for the non-8-bit Atmel/Microchip products, so I can't really compare. The NXP Cortex-M3 I'm currently using for a project has one SPI and two SSP peripherals.

My impression from talking to other engineers is that there isn't a lot of investment in those architectures (financial or emotional...) and most people think that economies of scale will make ARM dominant in the long term. From a business perspective, neither company seems to believe they can afford to be without an ARM product line.

There is no 16bit AVR.

Cortex-M3 runs circles around any 8-bit parts in most settings - single cycle instructions, hardware multiply and divide, 32bit registers, good interrupt processing support. There are even power efficient parts (Energy Micro EFM32, STM32L, etc). The other nice part about CM3 is the family support: Its one compiler toolchain and one debugger toolchain. With CMSIS (a software library standard) its "easy" (if you don't use a specific peripheral in a specific way) to move code across vendors as well.

PIC24 is a good half step, but the proprietary toolchains are a major turn off. PIC32 is at least a MIPS core (with some vague gesturing on Microchip's part for their GCC port - good luck actually building their horrible code dump though), but doesn't appear to be energy-use competitive with CM3 or CM0.

Do you have a recommendation for a specific CM based microcontroller? Preferably one that is well stocked on mouser and has USB support.

Also, any tips on getting started? How do I program them? Ideally, I'd get an in circuit programmer, rather than a development/demo board.

The LPC1768 is quite popular and you should never have problems with stock. I got started with a $30 development board from NGX (google "1768 blueboard") paired with a $30 USB jtag programmer from the same store. The older LPC2148 was also quite popular for hobbyists, but it's ARM7 not CM3.

Since I was more interested in learning the micro then screwing around with toolchains, I just spent the money and got a personal license for Rowley Crossworks ($150). It took me under an hour to go from software installation to flashing an LED, so I'm pretty happy with that decision.

ARM is awesome. Specially the low end Cortex chips.

However, for hobbyists these chips are not that easy. None of them come in DIP packaging so instead of simply soldering them in a simple prototype board or sticking them in a breadboard you will have to find SMD adapters or create your own PCB.

That is where AVR and PIC win big time.

Can you link to some equivalent starter boards?

One ARM based board which comes in my mind is BeagleBoard (http://beagleboard.org/), its bit expensive 149$ but quite powerful.

Something based on the Cortex-M series (http://www.sparkfun.com/products/10664) probably is a better ARM starter board for someone who's getting started on the embedded stuff. Cortex-A series ARMs are completely different beasts in terms of complexity.

I second that. The BeagleBoard is amazing. It can do real time (the original one can handle roughly 25 fps) computer vision, thanks to its built in DSP. The newer one should be even better (but I've not heard as much about it).

Leaflabs makes Maple boards that are somewhat similar but less expensive, under $50. They are based on ARM Cortex M3. Worth checking out. ( http://leaflabs.com/devices/maple/ )

NXP sells CM0 and CM3 development boards for $30 on Digikey. For example:

http://ics.nxp.com/lpcxpresso/ http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&...

They come with a free license for code_red's customized version of Eclipse with support for firmware up to 128KB. It's apparently also possible to cobble together an fully-OSS toolchain, but I haven't tried yet.

Completely agree, ARM is where it's at.

Recipe for an open source, GCC-based ARM toolchain:

-GCC

-Newlib (an implementation of the C standard library aimed at embedded systems)

-Binutils

-GDB (optional; great if you pick up a jtag debugger and openOCD)

I pushed out a cross-compiler via this recipe that survived an entire semester of usage in labs along with an ARM Cortex-M3 board.

No limitations on RAM usage, full optimizations available. As far as I've seen, GCC does a nice job using the ARM thumb2 instruction set when you enable optimizations.

I felt compelled to put together my own linker script; one of the more painful parts. I'm not sure if the default linker script will work or not.

I've been meaning to put this toolchain recipe online somewhere, along with a tool I put together for flashing the GCC-produced executables to the Cortex-M3 via USB DFU.

- CMSIS for your part should already come with a binutils compatible linker scripts. The three I use (ST, NXP, Energy Micro) all come with them already. Obviously you'll need to modify the script if you're rolling your own bootloader or similar, but it should work otherwise.

- I like defaulting to the CodeSourcery G++-Lite toolchain. Its also ARM, Thumb, Thumb2 multilib capable for non CM3 parts (like ARM7/ARM9).

- USB DFU is not universal. NXP has cool idea (mass storage device, though buggy when used with Linux without mtools). ST's version kinda sucks (try cribbing from the Maple code maybe). No idea on Atmel.

I mostly just wanted to roll my own cross compiler, plus it was easier (for me) to distribute to the network machines that way.

USB DFU is a device class specified by the USB standard. I like the idea of following a standard more than getting locked in to a company because I have only implemented their bootloader protocol.

I've been using the STM32 series Cortex-M3's, and unfortunately ST puts it's own little layer ("DFUSE") on top of DFU.

It would be nice if these companies would just go ahead and conform to some bootloader protocol (USB DFU!) so developers can stop wasting time there trying to talk to boards.

I agree on the bootloader front. I wish they would just settle on a single implementation. NXP's version is however useful, since it requires no tools to operate (delete file from "disk", copy new file to "disk").

Reply on news.ycombinator.com