Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Hardware Hacking Programming Build Hardware

ARM-Based Arduino Competitor At SparkFun 106

Gibbs-Duhem writes "The LeafLabs Maple, an ARM device designed to be pin compatible with the Arduino, and with a strikingly similar and familiar development environment, has reached a new milestone — being carried by SparkFun. By swapping the popular 'avr-gcc' compiler with CodeSourcery's 'arm-non-eabi-gcc,' LeafLabs manages to provide a nearly identical programming experience to Arduino despite targeting a completely different architecture. Also, while some Arduino shields are incompatible due to certain capabilities being allocated to different pins, several of them are currently supported and there are more to come."
This discussion has been archived. No new comments can be posted.

ARM-Based Arduino Competitor At SparkFun

Comments Filter:
  • Slightly offtopic, but the naming of the compiler seems strange to me. It indicates that it's not using EABI, but which ABI *is* it using then?
    • GCC target triples (which, in the spirit of Douglas Adams, have 4 elements) put the OS there. The first element is the CPU, then the vendor, then the OS, then the userland ABI. This just means a generic ARM EABI target.

      Well, more or less. In typical GNU style, everyone who uses target triples puts different things in the different fields. Presumably they're putting eabi instead of something like linux in the third field because there it's running on the metal, with no OS, and gcc instead of gnu in the

      • by u17 ( 1730558 )
        Good explanation, but I'd like to offer one correction. The -gcc suffix is not part of the triple, that string is just the name of the compiler binary, as in /usr/bin/arm-non-eabi-gcc. The actual triple is arm-non-eabi.
    • []

      arm vs armel

      Apparently there is some new version of ARM called EABI and instead of breaking compatability, debian decided to go with a whole new 'arch' to support the changes.

      'armel' is the 'new arm'. 'arm' is apparently deprecated.

      Please see [] and []

      • You know, if you don't know what you're talking about, it's better to just say nothing. The armel designation is used to indicate little-endian ARM targets. EABI isn't a 'new version of ARM' (whatever that means), it's a new(ish - about 10 years old) ABI, which adds support for some things like sane exception handling - it's the ARM embedded ABI, contrasted with oabi (the old Linux ABI). Debian defaults to the softfp version, which is painfully slow on architecture that have a real FPU, but they're in th
        • The armel designation is used to indicate little-endian ARM targets

          When it comes to debian arm architectures things are something of a mess. While armel literally means "arm little endian" it is also the name of a debian architecture and in that context it says a lot more than just little endian.

          There have been a number of different debian arm ports with different names

          "arm" was little endian old abi with parameter passing done in a way that depends on an old FPU (which is kernel-emulated for systems that don't have it resulting in APPALLING floating point performance on m

      • The "el" is "endian-little". A completely silly thing to do to an ARM if you ask me. Maybe it's for compatibility, which is really the only reason to every use little endian outside of an 9-bit cpu.

        EABI is "embedded Application Binary Interface". The ARM did not have a formal EABI like some other CPUs until relatively recently. So it really hasn't caught on that well except with newer projects that don't have to deal with compatibility.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      it should be "none", not "non", indicating that this compiler does not target any OS, just a blank EABI slate. The submitter got it wrong

    • There are only two ABIs for ARM. The older version, being the only version at that time, didn't have an official name. Unofficially it's sometimes referred to as OABI.
    • It means it has no operating system. Basically they've swapped one GCC for another GCC with the difference being the command line options you give to "configure".

  • How about an ARM that is a pin-compatible replacement for a PIC (24F)? And how about some SW that ports PIC24F firmware to that ARM? I'd love to try upgrading my PIC24F board to ARM, without changing any of my other HW or SW. If that ARM can run Android with my PIC code embedded in it on my old PIC board, I'd get right on it in the lab.

    Maybe an ARM with FPGA embedded in the SoC that can replace the PIC24F pin-for-pin (or superset the old pins), running Android, with the PIC simulated in FPGA. If that can ru

    • by inflex ( 123318 )

      While Microchip have produced some amazing new PIC devices, the trouble is for them that in many ways they've lost a lot of market interest. There's plenty of BIG players still using them but on the hobby/enthusiast/learning front they've gone from being "dominators" to "has beens" in a very few short years and now many of the bigger players are moving over as well (the consumer-hobby market devices are now dominated by AVRs).

      AVRs with their free development tool chain and sane hardware architecture has won

    • Its not a PIC24F but there is one (at least),719,895&Prod=CHIPKIT-MAX32 [] after I find something fairly permanent for my arduino pro mini to do, I might get one.
      • Er, that product is a PIC that's compatible with Arduino sockets. I'm talking about an ARM that's compatible with PIC sockets. No Arduino anywhere.

  • Kinda looks like a mini version of the Beagle Board [], fills the gap between 8-bit Arduino and the powerful (but >$100) Beagle.

  • Almost-compatible, that worked out really well in the PC market years ago.... not.

    I think they should just market and develop these things entirely within their own realm (sure, bring along the Arduino 'easy programming' layer), the ARMs have so much more to offer over the AVR Megas (that said, AVR Megas/Tinys are GREAT, use them all the time for our production runs).

    Still who knows, maybe it'll work more as a 'bridge' to ease the transition over for people who need more than what the current range of Mega

  • by YA_Python_dev ( 885173 ) on Saturday May 21, 2011 @09:09AM (#36201280) Journal

    Before you ask, this thing has 20 kB of RAM (yes, that's kilo, not mega), still better than the 2 kB of the Arduino but do not think of this as the same ARM that runs in your phone.

    And, yes, you can still do quite a lot of stuff in 2 kB of RAM (I created a pretty complicated protocol translator at work with an Arduino that even ran in the old ones with only 1 kB RAM).

    • by inflex ( 123318 )

      Are you talking -flash- or RAM? Even the mega168 only has 1K RAM (but obviously 16K flash).

      It's surprising what you can cram into 512 bytes flash and 32 bytes RAM eg, AVR Tiny5.

      • by inflex ( 123318 )

        God damnit - yes, of course you're talking RAM... sorry about that (I blame rapture!)

      • Yes, 16k SRAM, 4k EEPROM, 128k flash (120k accessible). Souped-up version has 64k SRAM, 512k flash (plus dual 12 bit DACs and some other improvements). The ARMs are 32 bit and the STM-made version in the Maple has many other advantages over the 8-bit Atmels in the Arduino.

    • by AdamHaun ( 43173 )

      Well, it is the same architecture (ARMv7) -- just a Cortex-M3 instead of a Cortex-A8. It's not quite an iPhone, but 72MHz and 128kB of flash is nothing to sneeze at for small embedded projects.

  • by TuringTest ( 533084 ) on Saturday May 21, 2011 @09:20AM (#36201320) Journal

    Great! But does it have all the characteristics required [] to compete with the Arduino?

    I've seen only technical bullet points in TFA, and technical bullet points are not the reason why the Arduino matters.

    • From a quick glance through the maple docs [] the answer appears to be yes.

    • It uses the same software as the Arduino so far as the new user can tell. Shields are mostly compatible, and nearly all the rest could be made so with a few jumper wires. The format of the headers is the same. (for the main model, at least) The extra RAM, flash, and peripherals make more projects possible than the Arduino. Maple is 100% open source, including the hardware, and while it isn't yet as big as Arduino's, the developer community seems active and helpful, both to novices and experts.

  • Am I the only one who doesn't get what is this post about? What is Arduino and why is it so important?

    • by inflex ( 123318 )

      Pretty much every non-electrical-engineering-background geek who tries their hand at electronics now is doing so using an Arduino device. To put it in OS terms, it's like the Ubuntu of Linux ;)

      What a device that does XYZ when you give it data 'A', then grab and Arduino and viola, you're an instant EE.

      If you detect a hint of cynicism in my post, you're right - while we love seeing many new people coming into the world of electronics design, at the same time it's a real fright when you see some of the hack-j

      • by cynyr ( 703126 )

        right but we need to start somewhere... I would agree, with the ubuntu statement, which is why I'm not sure i would use one. It feels like very quickly i would run into wanting to do something but couldn't because my hands were tied (no pre-up hook for networking devices for example). At which point i would have to go buy a "real" microcontroler....

        Now can i provide a PWM signal to a 4 pin 12Vdc computer fan with an arduino? because it is looking like a 555 timer won't make the high frequencies(24khz i thin

        • by inflex ( 123318 )

          As AC mentioned above, there's no restriction on using the hardware -without- the "easy coding" Arduino layer. Many of us do buy Arduino dev boards simply because it's a faster pretested/prefabbed/CHEAPER way of getting the microcontroller we want that we code the way we want (usually in ASM or C) without any of the Arduino software hindering us. Doing things that way means you can have a simpler daughterboard that's specific to your task at hand and you've got an easy module to replace/upgrade if need be

        • it is looking like a 555 timer won't make the high frequencies(24khz i think)

          What sort of 555s are you using? Getting a 24kHz signal from a 555 should not be a difficult thing to do.

        • theres an old uhm article about why the C language and/or Unix became popular, i think its called 'Worse is better'.

        • by hbackert ( 45117 )

          Now can i provide a PWM signal to a 4 pin 12Vdc computer fan with an arduino? because it is looking like a 555 timer won't make the high frequencies(24khz i think) that the PWM fans need.

          Yes you can. Not exactly 24kHz. But 32kHz. Which works very well with the Owltech fan (4 pin) I have. [] says: 21-28kHz. When I use lower frequencies I can hear a buzzing. It worked at 500Hz just fine, with the exception of the slight but annoying noise. Running the fan at 32kHz PWM works fine. No noise, and the fan spins fast and slow as required.

        • Yes, this is a small 8-bit processor with extremely little memory, you're not going to be doing much with networking. You'd have to look at a 16 or 32-bit processor (PowerPC, ARM, MIPS, x86, SH, etc). I think PWM is the sort of stuff these CPUs can be good at, depending on application. You don't need the 555 timer chip, just use the PWM peripheral on the processor itself.

      • My how times have changed. I remember tinkering with electronics in high school, and mostly what I have to show for it is a box of random parts and a whole lot of burnt out ICs, including a number of microcontrollers (oh, yeah, and a bachelor's in EE, which is how I learned how to actually use all those parts; there were plenty of burnt out ICs involved there too...).
    • I'm sure you're not the only one who doesn't get it, but so far you are the only one to complain about it rather than look it up or just move on with your day.

    • Before worrying about that too much, you should find out what Wikipedia and Google are.

    • by vadim_t ( 324782 ) on Saturday May 21, 2011 @11:18AM (#36201936) Homepage

      It's a microprocessor on a small board with digital and analog inputs and outputs, a serial port, easy programmability via USB, easy to use IDE and library of useful functions. The board accepts from 7 to 12V, and has pins that output the input voltage, 5V and 3.3V, which is very convenient.

      There are different versions of it, but the pinouts are standarized and it's made in a way that additional modules can be plugged on top of it, to provide functions like storage on SD cards or wifi.

      Why is it important? Because it allows people with near zero experience in electronics to make something that works.

      You can buy a microcontroller cheaply. But you'll need to spend many hours reading the datasheet, understanding how to hook it up, and how to program it. You'll end up working with a huge mess of wires on a breadboard, and need additional hardware for programming it.

      With an Arduino, you plug it into an USB cable and in less than 5 minutes you'll have your blinking LED. From there, you can say, buy a wifi shield and a solar panel shield, simply stack them, hook up for instance a temperature sensor to an analog pin, and with a bit of code you can poll that sensor over wifi.

      Projects done with it will likely be much more expensive than strictly necessary, but you'll be able to easily do things that would otherwise need a decent understanding of electronics.

      • by npsimons ( 32752 ) *

        Projects done with it will likely be much more expensive than strictly necessary, but you'll be able to easily do things that would otherwise need a decent understanding of electronics.

        I've not played with Arduinos, but the thing that gets me is how many "professionals" look down on them. From a purely economic point of view, Arduinos are the perfect electronics prototype system. Sure, they may be more expensive than necessary, but I would think you buy one (or a couple) and rapid prototype something with t

    • It's basically just an 9-bit CPU (one of a number of AVR ATmegas) on an evaluation board. The real reason it is popular (other than because it's already popular) is that it has a lot of no-solder connections to add your own peripherals plus it has a dumbed down graphical programming environment. A serious hobbyist is going to skip the environment, but at that point they can find cheaper or more powerful evaluation boards as well.

      Essentially it's the Visual Basic of the hardware world.

  • by Rufty ( 37223 ) on Saturday May 21, 2011 @09:24AM (#36201340) Homepage
    I've got a LeafLabs Maple. And a Cortino []. And an ARMimte Pro []. They're all ARM processors on an Arduino footprint board.(There's also Xduino [], but I haven't tried one.)
    The Maple aims to be as Arduino-like as possible; even to the extent that you should eventually be able to copy running code from the Arduino IDE, paste into the very similar Maple IDE, hit compile and upload and you're good. It's not quite there yet, but if you're just developing for the Maple it's nice now.
    The Cortino is a much more traditional embedded system. It's got an uploader. (Windows executable only.) And, well, that's it. Find your own compiler and runtime. I think I remember finding that the upload protocol was something standard, but I ended up using OpenOCD [] and soldering in the JTAG header. One brick wall of a learning curve, but I was so pleased at getting it to blink morse!
    The ARMite PRO is the Arduino-footprint offering in a range of boards. They are preloaded with a BASIC interpreter, but solder on a jumper and you can upload via a FTDI USB serial cable. I think it's just the same as the Arduino lilypads.
    Fun to play with; I need to get an Xduino now!
  • by Anonymous Coward

    I would also consider Netduino []. It's a bit cheaper and, like the Maple, it is probably capable of doing a lot of the things you're thinking of doing if you feel Arduino is holding your hobby project back. It uses the .NET Micro Framework.

    Wait, is this Slashdot?


  • Given the choice for a bit of microcontroller hacking, I would take the AVR every time over an ARM. The ARM instruction set and processor model is a huge kludge. The AVR's is quite neat and clean. I've designed ARMs into a few chips and I've yet to meet an engineer who has chosen ARM because they liked the ARM, it's always because higher management have brought into the hype. The details suck.

    • by Anonymous Coward

      I can't disagree strongly enough, and this is factually incorrect in almost every way. Besides the fact that 98% of cell phones use ARM CPUs [], the STM Cortex-M3 specifically has an incredibly versatile set of peripherals and power management abilities. Not to mention a hundred times the RAM and FLASH, and >5x the performance. While you might disagree with the rest of the world, it doesn't make you right. The instruction set is annoying if you're programming in assembly, but certainly less annoying than th

      • Really? Make it right? The guy posted a personal opinion. How can a personal opinion be factually incorrect?

        Mind you I couldn't agree more with him. Coding for AVR is simple and neat. Small embedded applications are far easier to code for an AVR than an ARM. The only reason one would pick ARM is if they are forced into it by the required featureset or management, and I have seen a LOT of applications with an ARM chip which could be satisfied on an ATTINY, probably taking advantage only on economies of scale

    • by Arlet ( 29997 )

      Having written plenty of code for both ARM and AVR, I have to disagree here. The ARM instruction set is very nice, powerful, and easy to learn. In comparison, the AVR isn't bad, but I certainly wouldn't favor it. The biggest problem with the AVR is the strict Harvard architecture, which means there's no good way that you can make a routine on the AVR that accepts either a pointer to RAM (such as a variable string) or pointer to Flash (such as a constant string).

      Besides, you can write many interesting progra

      • by AmiMoJo ( 196126 )

        The main difference between the two is that an AVR is designed to be self contained where as an ARM microcontroller has features for connecting to memory buses, e.g. DMA. I know you can have external SRAM on an AVR but it is quite limited and moving data off-chip in bulk is relatively inefficient and cycle consuming compared to an ARM where you can just DMA it.

        I prefer AVR for most of what I do but a large part of that is the fact that you can get AVRs in DIP format for easy prototyping. Unfortunately some

    • AVR is tiny. ARM is much larger with a 16 or 32 bit bus and can have vastly more memory. They're meant for very different purposes. If you're going to need a large CPU anyway, and the ARM can also handle the microcontrolling part, then the ARM is the right choice.

      However many systems use both. Large 32-bit CPU with a small 8-bit CPU on the same board.

    • by romiz ( 757548 )
      Note that it's an ARM Cortex-M3 chip, which means that the assembly is Thumb 2, and that the exception and thread model is different from the ARM7 chips that were common for this use in the past.

      And really, when your choice is between some old 16-bit C166 variant and ARM, I can assure you that engineers rejoice in getting rid of a lot of kludge. Such as 'multiplication' functions and far pointers.
    • While the ARM is perhaps harder to write assembler for, it has a beautifully orthogonal instruction set, great for a compiler (and lets face it, if you are writing more than 10% of your code in assembler, you must have some horribly stringent requirements).

      Having said that, the AVR is one of the nicer 8 bit instruction sets, and not a bad introduction to assembler. Since the AVR chips don't have some of the memory and I/O complexity of the more powerful microcontrollers, they are great for light projects. B

  • I actually had some conversation yesterday about this [having ARM powering microcontrollers and small embedded].

    I don't think this will succeed, and I believe there are a few reasons for it. I also created an "Arduino" clone, based on a different processor, called ZPUino [], and although the programming environment, libraries and so on can be nearly the same, specifics to the SoC are always tricky to implement and to provide viable alternatives.

    Why standard ARM will not replace Arduino:

    * Lack of

    • by AdamHaun ( 43173 )

      The SoC on this board has an internal ADC along with timers, PWM, and GPIOs. Not sure what you mean about latencies and jitter. Shouldn't a 32-bit CPU handle code and data accesses better than an 8-bit CPU? I'm not really a CPU architecture guy, so please correct me if I'm wrong.

      According to the datasheets, this STM ARM chip at 3.3V consumes a bit over half the power of the ATMega328 from an Arduino Uno running at 5V despite the former's CPU/memory advantage. Dynamic power is proportional to the square of s

      • by Arlet ( 29997 )

        Shouldn't a 32-bit CPU handle code and data accesses better than an 8-bit CPU? I'm not really a CPU architecture guy, so please correct me if I'm wrong.

        He means that ARM SoC usually have some jitter in the instruction timing This could be caused by cache fills, or by more complex memory buses, such as a bus which is also shared by a separate DMA controller. Because of the higher bus speeds, there is usually more delay, and this means longer burst access. So the DMA could be doing a long burst, while the CP

        • True, a 1MHz AVR is not what you use when you have to worry about sub-microsecond jitter. If you hate the ARM with caching inconsistencies then you get an ARM without caching instead of a performance oriented ARM.

      • The SoC on this board has an internal ADC along with timers, PWM, and GPIOs. Not sure what you mean about latencies and jitter. Shouldn't a 32-bit CPU handle code and data accesses better than an 8-bit CPU? I'm not really a CPU architecture guy, so please correct me if I'm wrong.

        In general

        A simple CPU is a predictable CPU
        A fast CPU is a complex CPU

        As you move up to more complex CPUs there gets to be more complexity between the core and the perhiperals. That complexity (caches, pipelining etc) causes the timing of your code to be harder to predict. Things get even harder to predict when you try to run an operating system or when you have internally generated non-maskable intterupts.

        Still I don't think it's too big a deal for most applications.

        I don't see any reason why you can't use an ARM SoC as the core of a hobbyist platform. It might not always be the best choice, but it does seem like a valid choice.


    • I suppose that the idea is that people will use the Maple board to make things that are more complex than your typical Arduino project. There are highly experienced people who know how to create advanced systems and algorithms, but who don't know how to work with electronics. Someone like that could use a Maple board to create an autonomous vehicle, or a music instrument, or anything that you can cram inside a 128 kB program memory and 20 kB RAM.

      I like your project, and I look forward to hearing more about

    • by Arlet ( 29997 )

      If all you want is a blinking LED, you don't need an ARM, but if you want to have a blinking LED controlled by a built-in web server, an ARM will work nicely.

      And why worry about some timing jitter when you're blinking a LED ? What kind of project are you doing that a few dozen nanoseconds is going to matter ?

    • The issue is probably not with "replacing". Real world systems do not choose one over the other, they use both. Some systems have a lot of processors under the hood. ARM + PIC + DSP, etc.

  • Considering digilent just announced THIS yesterday, ...,892&Cat=18

    Arduino Uno/Mega compatible, 80mhz, moar pins, on-board ethernet.


    This other thing is crap in comparison.

    • That does look like a good deal.

      The PIC32 chip runs at 80 MHz, it has 512 kB program memory, and 128 kB RAM, a 10-bit 16-channel 1 MS/s ADC, 4 32-bit timers, 1 16-bit timer, Ethernet, USB. Everything you need to make a powerful embedded wired network system.

      The $27 version is not bad either. Damn. I could go on at the risk of sounding like a salesman...

      What's the drawback?

    • by Osgeld ( 1900440 )

      I have a couple pic32 boards, I like avr's better but those things pack a pretty decent punch, and since its a real MCU it can handle more load on the pins and those pins are 5 volt tolerent (well the non ADC pins are) and much more GP

      course I am basing that vs my arm M3 board

    • That's a very nice board, but Maple certainly isn't crap by comparison. The Maple is cheaper, maybe more well-supported, nearly as fast. Many will prefer ARM to PIC - it is certainly more popular professionally. The peripherals are also different - while Ethernet and CAN could be vital for some things, the ST ARM has dual 12-bit ADCs while the PIC chip only has 1 10 bit ADC. The upcoming Maples will also have just as much flash as the PIC plus 12-bit DACs. Maple looks better for many purposes.

  • designed to be pin compatible


    are incompatible due to certain capabilities being allocated to different pins

    So are the shields incompatible with the Arduino? Or is the ARM device not pin compatible with the Arduino?


    • Most shields are compatible, most others can be made compatible with jumper wires. Take a look at the LeafLabs site, they mention some that have been tested. The forums there might be able to help you out if you have a specific shield in question.

  • You may be interested in the Microtouch. [] Have a look at the code for the demo programs. []

Sigmund Freud is alleged to have said that in the last analysis the entire field of psychology may reduce to biological electrochemistry.