ARM Processor On a Breadboard (hackaday.com)

An anonymous reader writes: A normal Arduino is easy to use and cheap, but it is a reasonably slow 8-bit processor with limited memory. Why do people use them? They are simple to use and set up. Hackaday shows how to take a cheap ($6) 32-bit CPU in a breadboard-friendly package, plug in a small number of parts (resistors, LEDs, and a cable), and use an online Arduino-like IDE to program it. The chip is way more powerful than an 8-bit Arduino and the code is comparable in complexity to an Arduino sketch that does the same thing. It's an easy way to get into embedded without having to suffer through 8-bit processors. And the new Arduinos also use 32-bit ARM, so that's an option too.

Comments

Teensy 3.1

[suso]

Or you just buy a Teensy 3.1 for around $20. Its a 32-bit ARM running at 72 MHz and runs Arduino code.

Re:Teensy 3.1

[Darinbob]

It's just another story about kids discovering that they could use small chips for the first time and then became excited the same as the day they discovered sex for the first time. Meanwhile old people are saying "slow down and take a shower, you didn't discover anything new".

Re:Teensy 3.1

[geoskd]

and greybeards/hams tend to use obsolete hardware and chant "right tool for the job" because they refuse to learn new things. same guys show up for an interview and wonder why they don't get hired.

Us greybeards would be impressed with these things if there was anything to be impressed about. This thing is far too little far too late. for $10, you can get one of these.

You young uns don't even understand enough to know what to get excited about...

Re:Teensy 3.1

[Tailhook]

Or you just buy a ST Nucleo for around $10. It's a whole family of STM32 ARM Cortex MCUs available on the same board with Arduino Uno R3 compatible headers and every IO pin exposed.

Re:Teensy 3.1

[Megane]

I got turned on to mbed a few years ago when an NXP rep left behind a few boards after a sales meeting. I didn't care much about the Code Red based boards, but the NXP1768 was one of the first mbed boards. It changed the way I program after seeing how mbed uses C++. Nowadays I mostly use the Freescale mbed boards, and I have a couple of Teensy 3.1 boards that I'd like to get working with mbed.

Re:Teensy 3.1

[Shirley Marquez]

The article is not about building a CPU from scratch, it's about putting an ARM microcontroller on a breadboard. Specifically an NXP LPC1114FN28, a Cortex-M0 chip that is one of the rare ARM processors avaialble in a DIP package. The high clock speeds are all inside the package; it has an on-chip PLL clock multiplier so even if you use an external crystal (optional; the chip also has an onboard 12 MHz RC oscillator) it's probably only going to run at something between 4 and 12 MHz. So long as you don't try to get any really high frequency signals off the chip, there should be no special challenges to breadboarding it.

On the other hand, unless you want to breadboard this to show that you can, it's probably a better idea to just use one of the many inexpensive ARM-based development boards that are available. Arduino Zero, Teensy, MSP432 Launchpad, STM32 Discovery, PSoC 4 and PSoC 5 Prototyping, and the various mbed-compatible boards are all possibilities.

Re:Teensy 3.1

[pjrc]

Hey, that's *me*. I'm the guy who makes Teensy.

First, thanks for the compliment. Really, the thought does count.

Indeed dev boards like Teensy do cost more than hardware that's subsidized by semiconductor manufacturers. They also cost more than Chinese clones. Those folks don't spend anything on software development, and they deflect all tech support and even some customer service back to the name-brand websites where they copied designs. Likewise, big semiconductor companies only put significant effort into supporting engineers at major corporations who are likely to design chips into high volume products like cell phones.

Projects like Arduino and Teensy are about helping ordinary people. We really do put effort into making things easier to use and we do respond to help individuals. We do invest a lot into software development that's aimed at allowing novices to achieve their goals. Obviously it's not possible to hand-hold everyone through every project, but the non-engineer user experience is dramatically better.

The simple reality is that costs money, especially ongoing software development as these 32 bit chips become more advanced and people wish to utilize that power for awesome projects. Name brand boards, where sales does fund software and documentation development will always cost more.

Software development means much more than just the tools. For example, years ago I wrote the FreqCount and FreqMeasure libraries, because all other exampls and Arduino libraries at the time has subtle timing errors. Since then, numerous people have wanted to measure 2 or 3 frequencies. Just a couple weeks ago I wrote a new FreqMeasureMulti library (released under MIT license) which uses the more advanced timers with input capture on every channel to allow simultaneously measuring up to 8 different frequencies. *That* is the type of software development which sales of boards like Teensy funds. I try very hard to keep costs low, but funding ongoing open source software development does cost something, which is necessarily reflected in the price of the hardware, since the software is all distributed for free.

There are many "Arduino Haters" in the world, and much of their frustration seems to be based on the high retail pricing for dev boards. Indeed, if you're an experienced engineer who's capable of developing all your code from scratch on bare metal, even things like filesystems and USB & networking stacks, then the idea of paying anything extra for well tested and easy to use software probably seems utterly silly. Paired with a simplified feature-poor IDE, it's maddening. But it really takes a special lack of human connection to refuse to see how easy-to-use platforms could be valuable for less experienced people, let alone utter beginners.

Of course, nobody uses boards like Arduino or Teensy in high volume products. Comparing costs of dev boards to the actual chips from distributors is silly. Sometimes it does make sense to embed a dev board into low-volume or pre-production units, especially if that lets you start selling and shipping sooner, but when volumes increase, of course you're not going to buy dev boards at high volume.

Teensy does use a proprietary bootloader. That's a business decision for a small company within a large marketplace with massive Chinese cloning. It's perfectly fine to object on philosophical grounds. The market is filled with lots of alternatives, much like how you can install Debian instead of Ubuntu. But bootloader corruption isn't much of an issue. Perhaps you're unaware that 32 bit Teensy uses 2 separate chips? You can't overwrite or corrupt the bootloader on the other chip, no matter what part of the main chip you overwrite. It really is a solid design, which has proven itself in real world usage over the last 3 years, by many thousands of people of wildly varying skill levels.

If you took the time to read all this, I hope you'll at least be able to appreciate that a tremendous amount of open source software

Power usage?

[MobileTatsu-NJG]

My Arduino projects don't require the power of a 32-bit processor, but do run on batteries. How much more (... or less maybe?) power is drawn by this processor?

Re:Power usage?

[Anonymous Coward]

http://www.ganssle.com/reports/ultra-low-power-design.html
Check 6 - Running Fast to Save Power (and actually the whole thing. Interesting, even though i currently have no need for ultra low power designs).

Re:Power usage?

[subreality]

My Arduino projects don't require the power of a 32-bit processor, but do run on batteries. How much more (... or less maybe?) power is drawn by this processor?

It's reasonably close. If you check the datasheets for "Static Characteristics" / "DC Characteristics" you'll find:

The LPC1114FN28 (the ARM chip) draws 9ma @50 MHz, 6ua @deep-sleep, and 220na @power-down;
The ATMEGA168PA (typical Arduino-ish AVR) draws 4.2ma @8MHz, 0.8ua @power-save, and 0.1ua @power-down.

These numbers are just for the chips - the Arduino draws considerably more (about 40ma @idle), and you can stretch your batteries a lot by hacking it. To give a sense of scale, the power LED on an Arduino probably draws 5-10 ma just by itself.

Note that this is a "Cortex M0" profile ARM chip - M means Microcontroller, and 0 means low-end. This is a 50 MHz chip with 32K of flash and 4K of RAM. It's more powerful than an AVR, but don't expect to boot Linux on your breadboard with this thing... that's a job for the Cortex A (Application) series.

Source:
http://www.nxp.com/documents/d...
http://www.atmel.com/images/At...

Why?

[BitZtream]

So let me be clear, I'm currently work on flight controller software (Drones) that I'm running on both AVR and ARM processors. A 72mhz ARMv6 chip ... meh, give me the AVR at 20mhz.

Its not all about bus width or clock speed. Most AVR instructions are 1 or 2 clock cycles, a handful are 3. ARM is rarely a single clock cycle, 3 being common. From a MHZ perspective, you just practically equalized them. The ARM at 72mhz has very little advantage from a CPU perspective. Having an MMU is nice, but once you start using it, you're likely starting to eat more cycles than you have spare and you're no longer real time.

The AVR has a fully orthogonal instruction set. Writing AVR assembly is actually enjoyable. Unlike ARM (god don't get me started on x86).

AVR chips are durable, you're not going to find an ARM that can handle the load/voltage of an AVR. I could go on for hours.

Of course, on that same note, I could argue for hours about why you'd want to use an ARM over an AVR.

They don't serve the same purposes, its stupid to pretend they really compete against each other. You simply can't take full advantage of the ARM CPU and do a lot of real time work, for example. So just use an AVR for the real time bits and leave the 'business logic' to something else.

The chip is way more powerful than an 8-bit Arduino

No, it isn't, you're just only looking at the MHZ and not the actual real world performance. Its not bad or anything, its just barely better.

and the code is comparable in complexity to an Arduino

Sure, but so is any processor that has an Arduino library for it, whats your point? I can write an entire OS in one line if you want. Of course, that one line is just going to jump to some actual code that does the real work ... kind of like how Arduino sketchs are just standard C++ files which are preprocessed to include the Arduino headers and libraries.

Re:Why?

[Tailhook]

Fanboi much?

The most popular flight controller around is the Naze32 with an STM32F1 ARM MCU. No one is having trouble with the instruction set, durability or any of that other stuff you're wrapped yourself around.

Cutting edge flight controllers have moved on to ARM Cortex-M4s. That MCU provides a floating point unit for faster signal processing of gyro and accelerometer data, implementing filters and solving PID calculations at much higher speed. Cortex-M7 is a thing now; six-stage, in-order, dual-issue superscalar pipeline with single and multiple double-precision floating point units in the same package and the same power consumption has the older parts. That's the future of flight controllers.

Re:Why?

[Tailhook]

A 72mhz ARMv6 from STmicro

Why do you keep bringing up ARMv6? ARMv6 is a CPU architecture and uses complex caches, TLB units and a virtual MMU. I don't know of anyone trying to use these for flight controllers. The Cortex-M architecture, which is the basis for all of the common ARM based flight controllers (OpenFlight, BrainFPV, Naze, etc.), is not ARMv6. I don't think you understand what you're talking about.

Floating point isn't actually a good thing in flight controllers, fixed point is preferred..

PID controllers using floating point are available now in Cleanflight. Read about them here. Other code bases, such as BrainFPV and OpenFlight use the floating point units as well. Fixed point is preferred only by fanbois using MCUs without floating point units.

Super scalers make execution timing unpredictable

No, they don't. Out-of-order pipelines and elaborate branch predictors do that. Cortex MCU pipeline is in-order and the branch predictor is designed by ARM to be conservative and not cause lengthy pipeline stalls so the Cortex line remains suitable for real-time MCU applications. The timing characteristics of every instruction in every mode of Cortex devices is well known. This `problem' of unpredictable timing with ARM MCUs is a fiction inside your head.

"suffer" from 8 bits?

[rubycodez]

8 bit processors are simple, functional and a joy to program; what moron thinks one "suffers" from using the proper sized tool for a job?

Re:"suffer" from 8 bits?

[rubycodez]

8 bit hardly dead in the manufacturing world, it's over 25% of mcu's sold each year (and percentage RISING!) and plenty of heavy duty IDE support them

Different use cases

[JanneM]

The ARM is more powerful, but is also bigger, costs several times more and draws more power. If you don't need the power - many or most embedded applications don't - you're increasing the cost and reducing battery life for nothing.

Don't get me wrong; A tiny low-end ARM system is fun and useful. Just like an ATTiny, or ATmega, or larger, more capable ARM systems. They all address different needs.

You'll struggle

[Anonymous Coward]

A lot of the physics doesn't lend itself to 0-255 integer values, GPS location too, really not 0-255 integer, and when you get to advanced features like camera tracking you really won't manage it.

I think you're kidding yourself about ARM taking several cycles per instructions, its often less than 1 due to pipe-lining parallelizing operations, and more registers mean less transfers to and from memory.

"No, it isn't, you're just only looking at the MHZ and not the actual real world performance"

Sorry, ARM blows it away in the real world. Its a faster chip, it processes bigger numbers per instruction (32 bit vs 8 bit), has more bandwidth to memory (moves more data per cycle). I think your comment is wishful thinking, but then again I'm an 8 bit guy at heart too.

Re: You'll struggle

[Anonymous Coward]

You are a moron. 8bit computers can work with any bit length of values, as well as any data type. In particular the arduino supports 16 bit words out of the box. They put people on the moon with that kind of technology, btw. Go f* yourself.