Intel powers an Arduino for the first time with new “Galileo” board

More ports and silicon than you can have a robot shake a stick at.

At IDF last month, Intel previewed its latest small chip initiative, Quark. Slotting in well below the Atom line, much less Haswell, Quark is aimed at that old chestnut, "the Internet of things." We were curious about when we'd see the first consumer Quark device, and it seems the time is now. At Maker Faire Rome today, Intel CEO Brian Krzanich introduced a collaboration between open source bastion Arduino and Intel's New Devices Group, and the first fruits of that collaboration are Galileo (PDF).

Typically driven by simple microcontrollers, basic Arduino boards are usually quite limited in connectivity, mainly USB and some Arduino-specific connectors. Expansion comes through those connectors, which allow daughterboards, called shields, to be layered atop the main board, adding additional I/O options. The ease of use—and ease of expansion—has long made the Arduino a favorite among the do-it-yourself crowd for things as simple as Christmas tree lights or as complex as a homebrewing robot.

The Intel Galileo reference board isn't a basic board. The Quark SoC is quite potent for a device of this type, resembling a Pentium 3 more than a microcontroller. Though the legacy Arduino connectors remain for compatibility with shields, Galileo features connectivity through USB (host and client), 100Mbps Ethernet, microSD, RS-232, and a full-size mini-PCI Express slot.

"Intel Galileo features the Intel Quark SoC X1000, the first product from the Intel Quark technology family of low-power, small-core products," the company said. "Intel Quark technology will extend Intel architecture into rapidly growing areas—from the Internet of Things to wearable computing in the future."

Intel will be donating 50,000 Galileo boards to universities around the world as part of the collaboration, and it will be available to hobbyists for $60 or less by November 29. That price makes Galileo quite competitive with existing Arduino boards, most of which aren't as feature complete. Intel promises full compatibility with Arduino software and existing hardware, which could make this a very attractive board for complex projects.

Today's announcement continues Intel's attempts to target the DIY market dominated by Raspberry Pi, BeagleBoard, and Arduino. Intel recently teamed up with the maker of the BeagleBoard to create the "Minnowboard," a $199 computer powered by open hardware and software.

Tiny computers have been run in large part by Intel's rival ARM lately. That's true of the Raspberry Pi and the BeagleBone Black. While Arduino traditionally used microcontrollers such as Atmel's, Arduino unveiled its first ARM-powered board one year ago with the Arduino DUE. Intel has boasted that its chips will provide more power, and, of course, compatibility with x86 applications. The Arduino/Intel partnership is a big deal for Arduino, but it's also important for Intel to prove its worth in this small but growing market.

It's a pity they didn't emulate the Arduino Mega footprint- I do like all the extra expansion on the mega more than the Uno. Very interesting board though, I'm certainly going to have to pick one up to play with.

I think that the RPi is an outstanding device; I've already bought one to give to a friend, along with everything needed to get it up and running. I now intend to by one for myself.

With all due respect to the concept and the tremendous effort by the Raspberry Pi Foundation, The RPi has one major flaw: the processor used.

The heavy lifting is done by a Broadcom BCM2835 system on a chip (SoC) which includes an ARM1176JZF-S 700 MHz processor.

The problem is that Broadcom is not at all open about the chip; so much so that Eben Upton--the major force behind the Pi--has stated that, in order to get all information from Broadcom, one would probably have to place an order for 100 000 or so chips, along with signing a Non-Disclosure Agreement.(Caveat: all this is based on my memory, when I tried to do some serious assembly-language programming on the Pi. So feel free to jump in with any and all addenda).

OH, BY THE WAY!:

The Operating System for the PI, Raspbian, is simply outstanding. Along with being an excellent Linux OS, it makes the RPI really sing by making use of the on-board math co-processor. Everyone needs to read your masterpiece on this great OS, along with the dialogue by the TWO gentlemen who created it:

I have been considering my feelings about the Raspberry Pi in light of my background as a hardware designer who had to learn programming in order to make his projects work; and in light of what I continue to learn about the selfless motivations of the Raspberry Pi Foundation. I would like to summarize (sic) my further considerations thusly (sorry, we Yanks never did learn to spell after 'That War')--

In defense of Broadcom, The Raspberry Pi Foundation, and the Raspberry Pi:

Broadcom has built a computer on a chip, just the same as if they had built a computer from discrete chips. One of the discrete chips just so happens to be an ARMv6 CPU. How they implemented memory control, communication, interrupt control, graphics, math processing, etc., is just as proprietary as if they had built a big-box minicomputer. Broadcom has every right to be protective of its intellectual property.

The Raspberry Pi Foundation saw in the Broadcom SoC an excellent SYSTEM around which it could implement, easily, its dream: a low-cost computer for the purposes of teaching young people to (a) not be intimidated by computers, and (b) LEARN PROGRAMMING EASILY.The aims of the Raspberry Pi Foundation specifically did not include the teaching of computer architecture arcania such as dedicated boot area, creation of a stack, interrupt vector area, interrupt processing, the worrying about memory allocation, memory-mapped I/O, special-purpose registers, and on and on and....Burn this into your brain: IF YOU'RE TRYING TO INTEREST ANYONE IN COMPUTERS, DO NOT SPOUT ANY OF THIS GARBAGE AT OR TO THEM!.

Because Eben Upton's goal was to create a teaching machine, and to NOT intimidate learners, he has resolutely--and admirably--not been forthcoming with any details which would detract from his goal. I would be very surprised if he did not also gladly agree to a Broadcom Non-Disclosure Agreement limiting him and the Foundation as to exactly what details of the Broadcom chip could be shared with outsiders.

For those of us who grew up with microcontrollers whose ENTIRE architecture--sometimes extremely complex, requiring a major assembly-language effort just to initialize the beast-- was exposed and available, we need to recognize exactly what the RPi is about, and "get over it".

Arduino and Intel created this NEW board--which does NOT compete with the RPi--for us. There's also OnSemi, Microchip, BeagleBone/Board, Atmel, and a whole host of others to provide fodder for us lovers of bare metal. There also exists a good selection of capable x86 motherboards in the sub-$100 range.

We 'know-it-all's need to get out of the way of the real geniuses, let them grow, and "get over it"!

Warmest...

p.s.: Loose-ends department:

I would like to explicitly state, if it is not perfectly clear, that I made a serious mistake in my original post, to wit:"With all due respect to the concept and the tremendous effort by the Raspberry Pi Foundation, The RPi has one major flaw: the processor used."

When putting everything in proper perspective, the RPi is the perfect device for its intended purpose. It's also a reasonably-capable general-purpose computing machine. Just don't push it, and then complain that it is not good at doing what YOU want it to do.Caveat: I teach university EE, ECE, and CIS. The RPi will be worked into my courses.

Ok, that's a joke but I'm really curious as to if this board will run i386 Linux distributions or Windows.

Why wouldn't it run a x86 operating system?

The processor used is a Intel x86 processor, its the only processor architecture Intel makes currently, besides the IA64 ( Itanium ). The limitation it has is the amount of memory and the frequency. It won't be running Windows for those reasons.

Ok, that's a joke but I'm really curious as to if this board will run i386 Linux distributions or Windows.

Its an x86 chip, with 16KB of L1 and a 400MHz clock speed. It'll probably be able to run Windows XP, maybe a stripped version of W7. A lite version Linux should be good to go, maybe something with a strictly CLi.

I wish they would have made the form factor something similar to the Pi or Arduino so we could have used it as a drop in replacement, if wanted.

Oh why would they make this device w/o GigE? Come on....how much extra $$$ would that be? $5?

I'm skeptical about if the CPU would even be able to effectively make use of it? At 400mhz we're probably looking at a late P2/early P3 equivalent. At that time period GigE was only just starting to trickle into the data center and was several years from becoming mainstreamish. I've read that 10Gb ethernet controllers need most of a CPU core to be able to operate at capacity, and this CPU is probably around an order of magnitude slower than the cores in current high end chips so the proportional load would be similar.

Edit: I'm not sure why you're getting down voted. The fact that there're good reasons why the answer is no doesn't make it an unreasonable question to ask.

Ok, that's a joke but I'm really curious as to if this board will run i386 Linux distributions or Windows.

Why wouldn't it run a x86 operating system?

The processor used is a Intel x86 processor, its the only processor architecture Intel makes currently, besides the IA64 ( Itanium ). The limitation it has is the amount of memory and the frequency. It won't be running Windows for those reasons.

Having an x86 CPU does not necessarily imply having a BIOS or UEFI, or that you've got other various things that are part of the PC "standard".

Oh why would they make this device w/o GigE? Come on....how much extra $$$ would that be? $5?

I'm skeptical about if the CPU would even be able to effectively make use of it? At 400mhz we're probably looking at a late P2/early P3 equivalent. At that time period GigE was only just starting to trickle into the data center and was several years from becoming mainstreamish. I've read that 10Gb ethernet controllers need most of a CPU core to be able to operate at capacity, and this CPU is probably around an order of magnitude slower than the cores in current high end chips so the proportional load would be similar.

I agree, one FAQ I read said:The basic rule or formula in the industry applicable to TCP/IP protocol is 1 MHZ of CPU for each megabit of data and allowing for application processing. This equates to a 1-GHZ CPU for a wire speed transfer in one direction or a 2-GHZ CPU for a bi-directional transfer in full-duplex mode when using the TCP/IP protocol stack. Using other protocols including UDP/IP or direct-IP can provide better performance with lower CPU utilization.

Ok, that's a joke but I'm really curious as to if this board will run i386 Linux distributions or Windows.

Why wouldn't it run a x86 operating system?

The processor used is a Intel x86 processor, its the only processor architecture Intel makes currently, besides the IA64 ( Itanium ). The limitation it has is the amount of memory and the frequency. It won't be running Windows for those reasons.

Having an x86 CPU does not necessarily imply having a BIOS or UEFI, or that you've got other various things that are part of the PC "standard".

It doesn't come up much (since the main reason to be x86 is support for x86 OSes and their applications, so the market for x86-but-requires-custom-OS-ports-just-like-ARM! isn't too large); but this issue has arisen a few times: The original OLPC laptop was x86, Geode SoC based; but used openfirmware, booted from NAND(I don't even know if it was abstracted behind an eMMC or similar controller, I think the openfirmware might have actually handled the raw NAND itself...) Microsoft eventually got XP working, but it was a port not an install.

Ok, that's a joke but I'm really curious as to if this board will run i386 Linux distributions or Windows.

Why wouldn't it run a x86 operating system?

The processor used is a Intel x86 processor, its the only processor architecture Intel makes currently, besides the IA64 ( Itanium ). The limitation it has is the amount of memory and the frequency. It won't be running Windows for those reasons.

Having an x86 CPU does not necessarily imply having a BIOS or UEFI, or that you've got other various things that are part of the PC "standard".

Agreed. This is more likely to be an issue for Windows than Linux because the latter is much more modular at the low level. I remember reading something about Intel's first phone oriented Atom SoC not being able to run the then current version of windows because of assumptions about the minimum level of hardware that any PC would include were broken: IIRC it was the lack of the (legacy???) PCI bus.

Ok, that's a joke but I'm really curious as to if this board will run i386 Linux distributions or Windows.

Why wouldn't it run a x86 operating system?

Why would one want to? It's not like any currently supported closed source operating systems would run well on it. One would probably be better off forgetting about intel completely and buying a beaglebone black instead.

It will certainly be able to run x86 Linux and Windows as VM on Linux. As for Windows on raw hardware, it would need the whole BIOS/UEFI/ACPI/PnP/alpha_bet_soup legacy compatibility, which probably isn't present.

Additionally, there's the question of Quark's ISA. Does anyone know which ISA extensions would show up in CPU-Z CPUID? Xeon Phi (Larrabee) does not support x87. Phi core can run Linux, but probably not Windows for that reason.

Actually this thing is quite attractive as it supports both host and client USB (interested in how that works exactly as generally PCs are host only)... the RPI only uses the USB connector for charging.

Also due to the RS232 port I can program it via a USB to serial or one of the old wyse terminals I have sitting around. Also something difficult to do on the RPI without using up GPIO slots.

The pdf didn't say anything about linux though -- only compatibility with the arduino sw environment. Does that mean I would have to expend a lot of effort to run linux? One of the attractive things about the RPI is that the setup time is quite minimal -- I can get to the "good part" without a lot of time wasted trying to setup the environment. And the advantages of a full multitasking OS with POSIX APIs compared to arduino are innumerable...

The pdf didn't say anything about linux though -- only compatibility with the arduino sw environment. Does that mean I would have to expend a lot of effort to run linux? One of the attractive things about the RPI is that the setup time is quite minimal -- I can get to the "good part" without a lot of time wasted trying to setup the environment. And the advantages of a full multitasking OS with POSIX APIs compared to arduino are innumerable...

this is not a RPI competitor. it has no video out. its purely set against the arduino atmel and chipkit pic32 boards. instant on, IO pin banging hardware.

There's your catch. About 250Hz. The GPIO stuff is connected via some I2C bridge, as far as I read, which only operates at 100kHz itself. So with all the other overhead, mainly going through the kernel for device access, you end up with... crappy speed!

This board is certainly interesting, but for anything you practically wanna do, it's not just a more powerful Arduino. You like those 5050 RGB LED bands with independently addressable segments?You can bitbang those on a normal Arduino, but on the Galileo you practically can't.Also, forget your ideas of a more powerful Arduino scope. While the ADC can be set to 12 bit resolution, you're looking at a 250Hz sampling rate.

Oh why would they make this device w/o GigE? Come on....how much extra $$$ would that be? $5?

I'm skeptical about if the CPU would even be able to effectively make use of it? At 400mhz we're probably looking at a late P2/early P3 equivalent. At that time period GigE was only just starting to trickle into the data center and was several years from becoming mainstreamish. I've read that 10Gb ethernet controllers need most of a CPU core to be able to operate at capacity, and this CPU is probably around an order of magnitude slower than the cores in current high end chips so the proportional load would be similar.

I agree, one FAQ I read said:The basic rule or formula in the industry applicable to TCP/IP protocol is 1 MHZ of CPU for each megabit of data and allowing for application processing. This equates to a 1-GHZ CPU for a wire speed transfer in one direction or a 2-GHZ CPU for a bi-directional transfer in full-duplex mode when using the TCP/IP protocol stack. Using other protocols including UDP/IP or direct-IP can provide better performance with lower CPU utilization.

It really depends. My 6 year old 2.66ghz i7-920 can transfer 1gb/s over SMB and consume less than 0.5% CPU, which is about 53mhz of CPU.

Using iPerf, it consumes about 8% cpu transferring 1.5gb/s on the bi-directional test.

I assume SMB is less because of large-send offloading that the integrated NIC supports.

The new netmap network stack in FreeBSD can push 10gb/s of 64byte packets on a single 900mhz core, and that's with no hardware offloading, entirely software RAW packets, but essentially 0 application level processing because they were just trying to test the network stack. So processing data at 10gb/s would require some strong CPU crunching, probably closer to the 1mhz/mbit.

Actually this thing is quite attractive as it supports both host and client USB (interested in how that works exactly as generally PCs are host only)... the RPI only uses the USB connector for charging.

Also due to the RS232 port I can program it via a USB to serial or one of the old wyse terminals I have sitting around. Also something difficult to do on the RPI without using up GPIO slots.

The pdf didn't say anything about linux though -- only compatibility with the arduino sw environment. Does that mean I would have to expend a lot of effort to run linux? One of the attractive things about the RPI is that the setup time is quite minimal -- I can get to the "good part" without a lot of time wasted trying to setup the environment. And the advantages of a full multitasking OS with POSIX APIs compared to arduino are innumerable...

As mentioned in the ARM based Arduino article you can run linux on it out of the box.

Quote:

Yes. Intel® Galileo runs Linux* out of the box. It comes in two flavors; the default is a small Linux. If you add an SD card to your kit, you can add a more fully-featured Linux. Refer to the Intel® Galileo Getting Started Guide and Intel® Quark SoC X1000 IoT Development Kit Software GSG.

It's basically a slightly modified 486. I mean that literally, compare the block diagram (figure 3) with the old 486 one: http://intel-vintage-developer.eu5.org/ ... 2713_1.GIF The biggest change is that they doubled the L1 cache, and that for some variants it's write through.

It's definitely far below the capability of a 400MHz Pentium 2, much less a Pentium 3. Programs will need to make good use of its 512KB of SRAM to really run decently (typical for embedded programs), otherwise for normal Linux stuff L1 misses are going to be pretty expensive since there's no L2 cache.

It's basically a slightly modified 486. I mean that literally, compare the block diagram (figure 3) with the old 486 one: http://intel-vintage-developer.eu5.org/ ... 2713_1.GIF The biggest change is that they doubled the L1 cache, and that for some variants it's write through.

It's definitely far below the capability of a 400MHz Pentium 2, much less a Pentium 3. Programs will need to make good use of its 512KB of SRAM to really run decently (typical for embedded programs), otherwise for normal Linux stuff L1 misses are going to be pretty expensive since there's no L2 cache.

They're specifying the architecture you should target, which describes the instruction set (among other things). The part I'm talking about is the microarchitecture, which describes how the CPU actually works. And clearly it works like a slightly modified 486, not a Pentium. I doubt they're recommending that you compile the code to be scheduled or optimized for a Pentium. For example, you'd hardly want it to insert nops that could improve performance on a Pentium in order to better align pairing rules. Here they'd just slow you down.

Architecturally speaking, Pentium barely changes anything from 486 anyway. The biggest difference is that on 486 the FPU was optional, while on Pentium it isn't. The only core instructions Pentium adds are cpuid, cmpxchg8b, rdmsr, rdtsc, wrmsr, and rsm (and cpuid was added to some 486s too). The only one that a compiler might ever actually emit is cmpxchg8b which would still be pretty unusual. The rest are systems functions.

wasnt larabee a cutdown 486 core? i wonder if this was any byproduct, as a low power 486 core..

Probably. For all that some people have tried arguing the projects are unrelated; the core used in Larabee and later Phi is a tiny x86 core that's been updated to work with a current Intel process; starting over again with a slightly different core design would be wasteful of effort.

wasnt larabee a cutdown 486 core? i wonder if this was any byproduct, as a low power 486 core..

No, it started as Pentium derived. But the end product was a lot more different from a Pentium than this is from a 486. Aside from the 512-bit SIMD extensinos on LRB, which is where a bulk of the area goes, consider that it's also 64-bit, has 4-way SMT, and has embedded L2 cache.

There's your catch. About 250Hz. The GPIO stuff is connected via some I2C bridge, as far as I read, which only operates at 100kHz itself. So with all the other overhead, mainly going through the kernel for device access, you end up with... crappy speed!

This board is certainly interesting, but for anything you practically wanna do, it's not just a more powerful Arduino. You like those 5050 RGB LED bands with independently addressable segments?You can bitbang those on a normal Arduino, but on the Galileo you practically can't.Also, forget your ideas of a more powerful Arduino scope. While the ADC can be set to 12 bit resolution, you're looking at a 250Hz sampling rate.

Ouch... I was hoping that Intel had something neat up their sleeve(a horrifying-but-genius abuse of SMM, if that's still around, or something) when I saw that Intel was doing things single-chip, when both the Arduino guys and the UDOO team were sticking with Atmel + ARM (even though ARM SoCs tend to be a bit better on GPIO, that x86s, since they don't assume as much in the way of peripherals being available). It looks like they are just ignoring those more microcontrollery use cases. Pity.

Maybe somebody will take advantage of the miniPCIe slot's nontrivial bandwidth and hack together a proper GPIO-and-bitbanging card?

You can bitbang gpio on competing chips at up to 1MHz (higher on some) and if you need other buses or to run faster than its gpio is capable of you're going to been to connect another arduino via i2c to handle it.

Disappointing and doesn't seem like a good marketing effort from Intel.Thought they would have had a better demonstration of their soc building skills than this

Ok, that's a joke but I'm really curious as to if this board will run i386 Linux distributions or Windows.

Why wouldn't it run a x86 operating system?

The processor used is a Intel x86 processor, its the only processor architecture Intel makes currently, besides the IA64 ( Itanium ). The limitation it has is the amount of memory and the frequency. It won't be running Windows for those reasons.