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

[suso]

But are you going to run 72 MHz on a breadboard?

You're right, better overclock it to 168MHz just to be sure.

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

[Anonymous Coward]

>anything new
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.

Re:Teensy 3.1

[drinkypoo]

You just put the whole teensy on your breadboard, just like the way you would normally get an Arduino on a breadboard; you get an Arduino Nano. You can get them from China for less than $4, if you don't mind getting a knockoff.

Re:Teensy 3.1

[Damarkus13]

Did I miss someone suggesting you could actually build an ARM CPU (or even an 8-bit Amtel processor) on a breadboard? Can we at least try to read the summary?

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

[samerpav]

This. The online mbed IDE is pretty nice too. It even allows you to export your project to Keil/IAR.

Re:Teensy 3.1

[doublebackslash]

I'm just getting into FPGA stuff and I gotta say it is REALLY nice to get down to the metal in that sort of intimate way. I might grumble at the tools compared to what I'm spoiled with but my GOODNESS designing a tiny little soft core to do structured I/O at clock-speed (1 transfer per clock with routing and such, not that impressive but REALLY cool to dig into compared to hundreds or thousands of cycles in software!).

I don't know if I'm wired differently or if more people don't give it a try, but with the price point of some things coming out I feel like its going to get really popular. I'm using a ~$150 Zybo to develop for the Xilinx 7 series at work and Vivado is free for that chip (targeting a larger one later, and that DID cost but its obviously worth it). Thats a game changer. That brings it on par with the cost of buying a compiler in the 90s. There are even cheaper ones out there. The sucker even runs Linux so you can ship things from the pins to the kernel via DMA.

Honestly until I started working on this level I didn't appreciate it properly. Now its a world of possibilities opening up for me, and the software know-how is critical to do things like write drivers and applications on top of this hardware. No better cure for hubris than going outside of your comfort zone and starting from scratch.

Re:Teensy 3.1

[vovin]

Please don't suggest anyone use that crap. The Cypress IDE is a hideous mindf**k.

Re:Teensy 3.1

[Darinbob]

So don't use it. No one seriously working in embedded systems uses the IDE or tools that come from the manufacturer.

Re:Teensy 3.1

[Darinbob]

If you need to use a radio with IPv6 protocol to communicate then the ARM becomes more attractive. Some of these Cortex-M series SoCs have good power profiles, ranging from 0.1 to 1.0uA sleep currents.

Re:Teensy 3.1

[Megane]

That's the problem I have with their PSoC parts. How do you control the PSoC bits without using their IDE? I suppose somewhere behind all that there's a command-line tool, but you still have to somehow create the files that specify how stuff is hooked up. I mean, PSoC is a pretty cool idea, but I'd hate to have to use it professionally when the only choice is the manufacturer's IDE.

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

[c4757p]

Levels of abstraction, dude. If you design a CPU in an FPGA you are working at the same level as someone designing a CPU in hardware. Nobody hand-crafts every one of the tens of thousands to billions of transistors in a CPU.

Re:Teensy 3.1

[TheGratefulNet]

pjr is a great programmer and seems like a great guy, too.

BUT - the code is proprietary (boot loader) and don't say that BL's don't ever get corrupted or have to be reloaded; I've seen it happen more than a few times. if the chip gets corrupted and needs reloading I'm not going to WANT to buy a new chip from paul every time.

for one-offs its great. but the cost for the chips gets expensive when you add in his price points.

again, he's a great programmer and his stuff is top-notch, but it comes with a cost and its not very affordable if you have to build more than a few units with his chips.

Re:Teensy 3.1

[hwstar]

From what I have seen with the Teensy, is the designer is playing games to prevent clones from appearing by doing "genuine" detection in the tools. It is for this reason I have avoided the Teensy.

ARM processors are the future for the maker/hobbyist group.

The observations:

1. The AVR processors are getting a bit long in the tooth and don't compare with the power of an ARM processor.
2. The Arduino IDE is seriously lacking debug support, and its a pain to debug real time code with println statements.

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

Re:Teensy 3.1

[Shirley Marquez]

You're correct; there is currently no way to configure the CPLD elements of the PSoC series without using the Cypress IDE.

On the other hand, the PSoC chips have some appeal even in applications where you aren't going to use any of that, because they are the only ARM microcontrollers I am familiar with that are completely 5V-friendly not merely 5V tolerant. The chip actually runs at 1.8V, but every input and output has built in level shifting so it can accept 5V inputs AND produce 5V outputs. Each 8-bit port has a separate voltage reference pin so can have a mix of 5V, 3.3V, and/or 1.8V I/O in your system, though most of the inexpensive PSoC development board tie all the voltage references together. You can even power the chip from a 5V supply and use the on-chip regulator.

If you want to work with the Cypress chips without spending a lot of time in the Cypress IDE, you could create a bootloader and a fixed PSoC setup in the Cypress IDE, and then do everything else in the environment of your choice. The FreeSoC2 board from Sparkfun does exactly that, so you can program it with the Arduino IDE and never touch the Cypress software except to burn the supplied bootloader image (normally only once unless you erase it somehow).

Re:Teensy 3.1

[Shirley Marquez]

There is a whole series of Nucleo boards now, with a choice of Cortex M0, M0+, M3, and M4 processors. And they are all under $11. Not a bad deal at all.

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]

Battery operation can sometimes be improved at higher clock speeds depending on the application. If the idea is sleep most of the time, but wake up and execute some code before going back to sleep, then you are going to have more flexibility with a mcu that has fine-grained control over clock speed. You need to find that intercept point where efficiency is at a maximum for the wake-time / clock speed ratio.

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

Re:Power usage?

[fisted]

+1 very good read, thanks AC

Re:Power usage?

[Darinbob]

Depends upon what you do. Arduino projects typically aren't used to communicate their data in a complex way. You can talk over UART but it's pretty hard to get an IP stack into there.

Re:Power usage?

[obsess5]

Anything by Gannsle is a good read. If I remember correctly, he used to have a long-running column in the excellent, but now-defunct Embedded Systems Programming magazine, plus he used to be based a few miles up the road from me in Maryland. (The magazine in general--and Gannsle's other writings--were/are good reads for all programmers, not just for embedded systems programmers.)

Re:Power usage?

[Shirley Marquez]

Most Arduino boards run at 16 Mhz, so the power consumption will be higher. And if you want to lower the power consumption of the ARM you can reduce the clock speed. The running power use of that ARM is probably actually lower at the same clock speed than the ATMega328 but the sleep current is higher. And that NXP chip is not state of the art; a newer chip optimized for low power consumption like an STM32L0 will use even less power.

Aside from hacks like removing the LEDs, the sketch loaded on an Arduino affects power consumption. Even configuration of the ports matters. Enabling peripherals like the SPI and I2C interfaces uses some power. Using analog inputs takes a significant amount of power. Ports can even use extra power while they are not doing anything if you enable the on-chip pullups (about 0.25mA per pin), and pins that are not connected at all can use extra power because the CMOS transistors may hover in the active area (near 0.5xVdd). For minimum power consumption, unused I/O pins should be directly tied to Vdd or ground and the internal pullups should NOT be enabled for those pins.

Re:Bigger isn't necessarily better

[geoskd]

An 8-bit processor with limited RAM breeds tight, bug free code. Exactly what you need in the embedded (any?) world. Help get the kids away from bad habits!!

hehe, that was great! Go on, pull the other one. :)

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?

[Megane]

This is a Cortex-M0 chip. Cortex-M is intended for low-RAM embedded applications, so you generally won't find an MMU on them. In fact, this chip has only one or two MMU pages worth of RAM total. And they don't even run the classic ARM instruction set, they're Thumb-only, with the M3 and M4 using Thumb-2, and M0/M0+ using a Thumb-2 subset. It's Cortex-A that has an MMU and runs Linux.

But if you want to stay ten years in the past, go ahead.

Re:Why?

[thegarbz]

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.

The parent didn't have a problem either. The only real problem is your reading comprehension.

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.

Define cutting edge. So far I've yet to see a fancy 32bit flight controller do something that mine can't, and mine runs on an 8bit AVR, not even configured at full clock speed. So don't tell me about your fancy multi-stage pipelines, tell me about the real world benefit because so far I've experienced none. Heck I still have a naza controller (which had a 32bit ARM from the very beginning) unused somewhere in in the bottom of a drawer.

Re:Why?

[BitZtream]

Heh, I have about 12 naze boards, I'm in the commit logs for baseflight, it is EXACTLY what I'm talking about, it's not worth using over an AVR due to it being a 72mhz ARM with multi clock cycle instructions and memory wait states means it's not worth bothering over a large AVR with 0 wait state reads Due to read ahead and most instructions being single clock cycle.

No one is doing anything special with it.

I suggest you get a clue. The Naze software is a port of AVR software (multi wii) and it is far less powerful than something like ArduPilot which does everything your referring to and more including fully autonomous flight (which naze doesn't). Your arm doesn't do shit faster because the AVR isn't yet overloaded by handling and the ARM you are referring to is a bottom of the line POS.

Can an ARM. Be faster? ABSOLUTELY! A 72mhz ARMv6 from STmicro ... No, that's just a waste of money.

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

Super scalers make execution timing unpredictable, not what you want in real time applications.

Your pretty much wrong in every way. Not that ARM is in anyway bad, just that it doesn't fit every job, especially when you start off with the most worthless on on the planet

Re:Why?

[nascentmind]

Why would you want to use a full blow CPU instead of a microcontroller. ARM Cortex M are microcontroller series. Comparing a MCU and CPU is apples and oranges.

Re:Why?

[nascentmind]

The guy does not know the difference between Microcontrollers and CPU's. M3 and M4 does not have an MMU and multi stage pipelines. I really don't understand how he is doing drone software without knowing the controller internals.

Re:Why?

[nascentmind]

You need to get a clue on microcontrollers and CPU's. There are plethora of 32 bit microcontroller robots and drones available in the market. You can control a drone using a simple MSP430/MSP432 and conserve as much power as possible.

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.

Re:Why?

[thegarbz]

Fuck me your reading comprehension is as bad as the person I was replying to. I know there's 32bit ones on the market. I have one myself. Except that it performs no differently than the 8bit one I have right now.

So until you can come up with some concrete data on real world end user benefits other than "moar bits = moar betterer" please don't try and school me. Especially if you're going to end with some quote on power usage, which is a joke given most MCU's use only a fraction of a percent of the battery in any typical flight.

Re:Why?

[Shirley Marquez]

It also depends on the size of the data. If you are working mostly with 8 bit numbers and bit patterns, the 8 bit AVR will be competitive in speed with a low end ARM. If you use a lot of 16 or 32 bit numbers, the ARM will blow away the AVR. If you are planning to do anything with floating point numbers, an ARM with an FPU will demolish the performance of any processor that doesn't have one.

Something to watch out for when you move up to faster ARM processors (over 100 MHz) and want to do real time work: execution time is not completely deterministic and cannot be calculated precisely. Those processors run at higher speeds than their flash memory and depend on caching and/or prefetching; the manufacturers often speak of a "flash accelerator" or the like. If you suffer an instruction fetch or static data fetch miss, the chip will stall for a bit.

"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?

[gweihir]

Probably the "bigger is always better" crowd of morons. They would replace a hammer with a nuke if they could...

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

Re:"suffer" from 8 bits?

[thegarbz]

what moron thinks one "suffers" from using the proper sized tool for a job?

Having to learn good programming practices and dealing with low speed, memory etc is considered "suffering" by a lot of people these days. Sad really.

Re: "suffer" from 8 bits?

[rubycodez]

I don't know of ANY 8 bit mcu that has 8 bit addressing, usually 10 bit or more. The most popular one, Intel 8051 family (which is probably half the embedded market) has 16 bit addressing.

Re:Bigger isn't necessarily better

[gweihir]

Indeed. And it also helps you to learn how to use a small embedded CPU and its peripherals. After you have mastered that, you cans till go to larger CPUs.

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.

Re:Different use cases

[Megane]

You do realize that this isn't the kind of ARM that you run Linux on, right? This is a Cortex-M microcontroller, and it's meant to do the kind of stuff that AVR does, only with a 32-bit processor and a single address space that doesn't confuse C compilers. There's plenty of sizes of Cortex-M from 2K-128K RAM and 4K-1M flash, and they run the gamut from low power to hardware floating point. As for cost, you're talking about a buck or two per chip average (the big number-crunching monsters might cost as much as ten bucks), with lots of low-end ones under a dollar.

The main disadvantage for hobbyists is that the one in TFA is the only ARM chip you can get in a DIP package. But these days the Arduino form factor is pretty common in typical ARM boards, and it sure beats trying to rig up the chip like in TFA every time. Such boards usually cost from $10-$25, literally as much or less than a genuine (non-bootleg) Arduino.

Re:Different use cases

[JanneM]

I know exactly what this is. And it is still larger, more expensive and more power hungry than most AVR processors. At the extreme end, you can get an ATTiny in a 8-pin DIP package that costs less than 50 yen in single units and needs nothing more than the usual sprinkling of 10uf capacitors to work. If you need the additional processing power and memory, ARM is a good choice; but in many cases you do not, in which case it is not.

Neither is "better" in an absolute sense; which is the better choice depends on your application. It's not really an apples-to-apples comparison. They're targeting different parts of the application spectrum.

Re:Different use cases

[nascentmind]

When you say ARM draws higher power what do you mean? It does not depend only on the instruction set. It also depends upon the process behind the manufacturing of the microcontrollers. Currently ARM microcontrollers from TI are the lowest power i.e. the MSP432 line ARM Cortex M4 MCU's in the market.

Re:Different use cases

[Agripa]

I looked into this when the LPC1114FN28 came out and they do draw more power than the 8/16/32 bit microcontrollers that they seek to replace. Part of this is do to a fabrication process which supports higher frequency operation but the addition of things like a PLL and separate clock domains for peripherals which adds extra complexity (and bugs at least in the case of NXP) not required on a slower microcontroller has a cost here as well. Another power saving feature which is missing in general on ARM is support for dual external clock sources which include a 32kHz crystal source.

The extra cost of ARM in general, 2 to 4 times, for performance if it is not needed does not help.

The big advantage of ARM is not having to deal with more than one instruction set and programming environment if you need to use a separate microcontroller for I/O expansion. The problem with this is that there is a dearth of available ARM microcontrollers suitable for this task when replacing 8 bit microcontrollers. The price/performance ratio just is not there.

Or get a Digilent chipKit uc32, which is...

[jpswensen]

essentially an arduino with a 32 bit processor. They have even taken great care to make sure that the programming environment is identical and many of the Arduino shields work with minor code or hardware modifications. https://www.digilentinc.com/Pr...

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.

Re: Bigger isn't necessarily better

[Anonymous Coward]

Let's go about this differently. If you are starting out on an arduino like environment as a kid and just learning and then you graduate from that tier of development, you want to move to the next thing. Generally speaking, you can write your own firmware and nuke the arduino or similar boot loader with some bare metal code. An 8-bit micro has a much shallower bare metal learning curve to beat. A 32 bit ARM cortex has all kinds of clock tree and power management crap to set up just to make port pins work when you are talking bare metal. Lets not discourage the poor kids with a massive chasm to leap from arduino to bare metal. 8 bit keeps the leap much smaller!

Two-fold purpose

[Anonymous Coward]

I always saw that Arduino as performing two fundamental roles:

1. Give people an easy to use, highly applicable micro controller that has a multitude of uses for hobby and even professional end application
2. Open the door to other micro controllers that suit different, potentially more complicated purposes

I'm a latecomer to the Arduino bandwaggon; having come from an EE background I'm already aware of the plethora of micro controller options and I have a good idea about their suitability for purpose. The 8-bit Arduino is fit for a vast number of purposes exactly as it is. When you're entering the scene from the Arduino as your starting point and then moving up you move on past the 8-bit ATmega when you need something a little more powerful that the Arduino can't do.

ARM is a fantastic development platform, it's capable of an awful lot more, but that's not entirely what the Arduino is all about, at least not by my interpretation. The Arduino in that respect is a sincerely great place to start but it's also a great place to stay. You can do an awful lot with one of those little ATmegas. There are just so many micro controllers, so much to learn, so many applications that I don't think anyone can truly call themselves expert in all branches, so if you've found a limb on the micro controller tree that you find comfortable then you're not doing anything wrong by sitting there.

MHZ Envy

[NReitzel]

Now what red blooded engineer doesn't want a bigger tool?

There are a constant barrage of cable channels explaining how you can take the proper suppliments, all for a bigger tool. And mechanical devices!

So why should your average pundit who reviews microprocessor tools and toolkits, and then goes home to take his EnZip and Vacupro and SusTane products, and then sits in front of a TV alone and dreams of JustOver19 dates, know anything at all about "Fitting a tool to a Job" ?

Come on, you're expecting rationality. Ain't gonna happen.

Not new

[Kazymyr]

This was covered 1.5 years ago in this DrDobbs article: http://www.drdobbs.com/embedde...
Been there, done that, the breadboarded ARM is a cool toy but not very practical.

Re: Bigger isn't necessarily better

[KGIII]

This is one of those subjects where I just shut the fuck up and listen, for the most part. Sometimes I ask questions. I simply don't know enough. I can offer no opinions that are qualified. I can, and do, learn and that is a god thing.

I bought a half dozen of the RPi kits when they came out and I've only unboxed one. I played with it and did exactly nothing of value with it. I keep meaning to pick it up and learn more but I can't actually think of anything I'd want to do with it or with the rest of them. I'd donate them to the local school (they get a lot of my stuff) but they're just an elementary school. I'm not sure that they'd be able to take advantage of the donation. The IT guy (they have just one - the school has 56 students, up two from last year) might be able to use them.

Anyhow, I am quite curious and enjoy reading the banter between those who do know. I've reached the point where I think I understand enough of it to get started. I just can't think of a damned thing to do that isn't already done, done better, and actually will give me a sense of accomplishment. Maybe I can just get a Linux distro installed on one and call it good. That might be interesting enough.

Excellent!

[Futurepower(R)]

Excellent information. Thanks.

Re: Bigger isn't necessarily better

[Wolfrider]

> I bought a half dozen of the RPi kits when they came out and I've only unboxed one. I played with it and did exactly nothing of value with it. I keep meaning to pick it up and learn more but I can't actually think of anything I'd want to do with it or with the rest of them.

--There are *lots* of things you can do with a PI that are pretty neat. If you already know Linux, you can just leave the board up and running 24/7 with minimal power expense.

--I chose to implement my Squid server on a Cubieboard instead, but you can do basically the same with a PI.

--Some links to get you started:

https://communities.vmware.com...
^^ This is a complete drop-in Squid Vmware appliance that I created. Once you get a Linux distribution installed on the PI, you can install the Squid package on it as well and copy the config files over.

http://www.squid-cache.org/

http://www.instructables.com/i...

http://www.pcworld.com/article...

http://www.itpro.co.uk/mobile/...

http://www.digitaltrends.com/c...

--Your local LUG (Linux User Group) should be able to help you get started and maybe give you some ideas on what to do with the board(s). HTH

https://en.wikipedia.org/wiki/...

--I recommend you designate a Saturday (or whatever day is $convenient) and resolve to do something with at least one Pi board. Feel free to email me with progress reports ;-)

Re: Bigger isn't necessarily better

[KGIII]

You are awesome! Thanks. Your post is now bookmarked and I *will* make the time to get to it. This may result in an email. *chuckles*

Also, I live in a very remote area of NW Maine - near Canada. I'm actually closer to Canada than I am to my nearest decent sized town. I *am* the local LUG. (When did LUG go to Linux User Group instead of Local User Group anyhow?) I am not home at the moment, I won't be for a while as I'm out engaging in wanderlust but appear to have actually stalled in Buffalo. (It involves a female. Now.)

As an interesting aside, I guess I kind of, sort of, have a female friend whom I met due to being geeky enough to have a Live USB (Lubuntu IIRC) in my laptop bag. So, I've engaged in my wanderlust, gotten stuck, and have managed to convert someone to Linux. I'm pretty sure this means my life is in shambles but I am having a good time.

Also, I have VMWare Workstation - multiple licenses. I'll be sure to check the image out even if I'm nowhere near a PI. As I'm stuck in one location for an indeterminate time, I'll try to find a local source for a kit. If I can't find a local source then I've already checked with the hotel and they're happy to let me receive mail here - specifically packages. I'm now paying for two rooms so they're pretty happy. (Again, it involves a female and is a very long story.)

Thanks again. Hopefully I find it as exciting as I'd hoped when I first decided to buy them. I had a plan... I want to create an automated gate at the bottom of my driveway up to and including distributing RFID broadcast devices so that they gate opens automatically. I want to write my own cell phone app that lets me know if someone's gone through or if someone's waiting - then have a camera to see and be able to open the gate remotely. I'd also like to enable the gate to open automatically only for certain times for certain friends. It probably sounds harder than it really is - I don't think it should be too difficult. I just lost motivation and realized that I really don't need such a system.

Somewhere, I might have lost a spark. You may have rekindled it though. Thanks! Seriously, thanks. There's a bunch of lengthy responses I could add but, suffice to say, I'm out appeasing my wanderlust for a reason and this may actually reflect back on that reason. Of course, now there's the issue of a female but we're not, yet, sleeping together so I can just meander away if needed. That too is another very long story. Either way, I shall add you to the friend's list so that I can more easily spot your posts. You appear to be a fountain of knowledge (and helpful, to boot) and that's why I'm here on Slashdot.

Re: Bigger isn't necessarily better

[Wolfrider]

--Good on ya. :-)

/ but be careful, le femme can wreck ya if not careful ;-) // still, wish you the best