Intel Galileo

Status
Not open for further replies.

PaulStoffregen

Well-known member
Looks like Intel doesn't want their X86 processors left out of the "Arduino market"....

http://www.intel.com/support/galileo/index.htm

So far, I can't find any word on the pricing, but here's a nice photo.

galileo.jpg

I took a quick look at the software. It look like the board runs uclinux and Intel has actually put some real engineering work into porting some Arduino libraries. Odds seem pretty good this board won't actually suck (I generally try not to trash-talk about the other Arduino compatible products, but to be realistic, Maple, Energia and ChipKit have pretty mediocre compatibility with many Arduino libraries).

I'm sure lots of people will help strong opinions. Discuss here..... ;)
 
More info....

http://blog.arduino.cc/2013/10/03/m...ting-new-product-and-collaboration-with-intel

http://makezine.com/2013/10/03/arduino-announces-two-new-linux-boards/

Looks like another board based on a fast TI ARM chip is coming too, but that one is being made by Arduino proper and scheduled for late 2014. If prior history is any indication, that means it's a very long way off. I got the impression we'll all be seeing the Intel board pretty soon.

The Arduino core library Intel has already published is really interesting. It looks like it compiles to a linux userspace application. Code execution ought to be screaming fast, since it's native code running 400 MHz X86 chip. But it's on top of a Linux system. The main gotcha looks like most of the I/O is done through I2C to a Analog Devices ADC chip and a Cypress I/O expander chip, but it's hard to tell for sure, since it all goes through a Linux uio device. From the FAQ:

What is the maximum rate at which GPIO output pins can be updated?

The GPIO output pins on Intel® Galileo are provided by an I2C Port Expander that is running at standard mode (100 kHz). Each I2C request to update a GPIO requires approximately 2ms. In addition to software overhead, this restricts the frequency achievable on the GPIO outputs to approximately 230 Hz.

I believe this Intel board will be really interesting for some projects, if it doesn't turn out to be prohibitively expensive.
 
Last edited:
It sounds like a Minnowboard ($199) with Arduino Uno R3 pins added on. I would imagine compatibility would be similar to what you see on the Teensy 3.0, in that at the digitalWrite, analogRead, etc. level things probably work, but you start getting into more complex issues when you try to run code that accesses the direct port registers, interrupts, etc. I wonder if you are running the Arduino stuff in bare metal, as a Linux thread, or possibly in a virtual machine. I.e. is it something like a Yun competitor, where you can run stuff on the Linux side as well as the Arduino side? Or when you are running Arduino code, are you wasting some of the capabilities of the machine.

Given the thing needs 5 volts and 3 amps of power, it cannot be powered off of the USB connection. For me, that is an instant non-starter, as I can't use common USB phone battery chargers to run off the grid like I do with the Teensy and Uno. Given the power supply can only take 5 volts, I wonder whether some people will fry their boards when they try to hook a Uno style connector with 9 volts.

From looking at the picture, the mounting holes are not in the same location as the Uno, so you won't have compatibility with Uno specific project boxes (that and the board is a little wider, with the ethernet/USB ports on the side, instead of the back).

It uses the Arduino IDE 1.5.3, while most users are still using 1.0.x. That may or may not have compatibility issues.

It is interesting that it can only run as an I2C or SPI master, and not as a slave. This means for some multiple board setups must be redone using other communications technologies. Also, it looks like it only supports the 100 kHz i2c, and it doesn't support faster speeds. Hmmm, I noticed that all of the GPIO pins are actually done via an i2c port expander. Each pin change takes approximately 2ms, and with the overhead of creating i2c, etc. the max throughput of gpio pins is about 230 Hz.

<edit>
Unlike the minnowboard, there are no ports for sound in/sound out or video. It does have a 2nd UART using a 3 pin jack that is not audio.
 
Last edited:
I wonder if you are running the Arduino stuff in bare metal, as a Linux thread, or possibly in a virtual machine.

It looks like native code running on top of Linux. The core library has lots of Linux API stuff like pthreads, file I/O, mmap, etc.

I would imagine compatibility would be similar to what you see on the Teensy 3.0, in that at the digitalWrite, analogRead, etc. level things probably work, but you start getting into more complex issues when you try to run code that accesses the direct port registers, interrupts, etc.

I wonder if they'll copy the AVR register emulation stuff I've done for Teensy3 ?
 
The 230 Hz throughput to the pins will mean that you cannot use the Galileo to power Neopixel strands (ws2812) which needs a fixed 800 Khz datastream, let alone something like the OctoWS2811,
 
As I see it, it is sort of a hail mary pass brought about by the release of the rasberry pi 2 years ago (and to a lessor extent pcDunio/beaglebone black more recently, but the Pi has more of the headspace in educational markets). They are giving away 50,000 units to University students in a hope that it will create the necessary infrastructure. That tells me that they know it isn't price competitive, and if they want to have any traction in this market, they need to give out samples in hopes that students down the road will pick it up, and use it. It worked in the 1990's, but I think it is a matter of too little, too late now.

Compared to the Arduino Uno it has much higher computation speed, and somewhat higher computation speed than a Teensy 3.0. So, unless you are running a beowolf cluster, what do you need higher speed calculations for? Video and sound. Unlike the Pi/Beaglebone/pcDunio, this chip does not support anything like HDMI directly for output. And there are no sound inputs and outputs other than the USB 2.0 slots. It does have more memory (512K of SRAM) than the Uno/Teensy, but still it is nowhere enough memory for doing serious video processing. It may be enough for sound.
 
I'm not sure where Arduino are coming from or heading too, except of course to get themselves into bed with most of the ARM based, industrial strength microcontroller producers. I'm wondering when they will officially announce jumping into bed with Microchip, ST and then NXP :)

From my perspective it appears Arduino are looking around at anyone making a good component, shield, controller etc and heading out and developing their own shields or adopting their own alternative products. Interestingly it seems to becoming more the case that the concept of open source is slipping away from the developers grasp. The form factor of the Arduino shield is based on the most obscure spacing, rendering the use of standard prototyping methods untidy e.g. breadboard, stripboard, matrix et-al.

Throw in the fact the confusion of shield voltages, many running at 5V while the processors are beginning more and more to heading to 3.3V. My understanding is that version 1.5 of the IDE is still not officially released, and the idea of getting involved with the DUE has no appeal, especially when the Teensy 3 is so stable and better integrated within the Arduino IDE.

There is a given 'maker' market, I feel that Arduino have the much larger world/volume in their sights, that of embedded microcontrollers, a market held securely by the main silicon producers. One core area they are missing out on if this is their intention and where PJRC have a considerable upside is integration of the microcontroller into a polished solution, you can solder a Teensy onto your main PCB, containing all your IO and with a robust (soldered) method to communicate the Teensy onto the board, of course utilising far less real estate, removing a lot of the power conditioning and delivering a professional looking solution within a commercial product.

With the decision to move to ARM processors there is one major, lacking issue within the Arduino IDE/bootloader/OS or whatever it gets named today and in the future, that being a multi-threaded environment, using ARM processors delivers a much wider range of hardware interrupts.

It would seem that 2014 could be an interesting year for Arduino, certainly with their current partnerships they are taking a lead from their ex-prime minister - getting into bed with anyone who will do so.

Indeed, while intended to be for the education market, the Raspberry Foundations Pi have shown the considerable hunger for us to head back to the 1980's era of personal computing, again, as a core small team they have achieved stunning results and know that they have a stable, robust solution to enter into their target market, as was referred to earlier, it's Google that have agreed to finance 50,000 Pi's into education. The difference between personal computing of the 80's and today is the availability of open standards, OS's, languages etc The only 'standard' OS in the 80's personal computers was CP/M but only if you were running Z80 CPUs then you needed to do a lot of work to move between different hardware, not least soft sectored and hard sectored 5.25" floppy drives and the controllers for both types.

Did the Raspberry foundation miss a trick with not making more IO available on the Pi? Personally I don't think it was an oversight, and if it was, there was a major conflict of adding IO to the Pi, namely the board is designed intentionally to be compact, easy to handle [by children] and with IO that meets educational needs and those of us whose eyesight isn't a sharp as it was in the 80's!

One last observation about Paul, it's spectacular what you (and your small team) have delivered in the line of Teensy products, especially when you look at the Teensy 3, you bucked the trend big time on Kickstarter, you delivered on time and a product that did what you said it would. Compared to the resource available to Arduino to develop their ARM based solution and the compatibility of libraries as you moved on from AVR, the rapid and seemingly positive way you worked with other parties to fix holes in libraries has to be said makes Arduino look rather silly for what they have delivered in a similar time since both PJRC and Arduino announced your ARM based products.

Time will tell. I'm not holding my breath though!
 
Technically, I too was late with Kickstarter....

We had promised 3 reward levels for September and 4 reward levels for October, where the early ones had a few extra dollars added. The intention to let people choose between getting it shipped early or getting a better deal. The difference was small, but it did really help prioritize the people who wanted it sooner! There was a problem with the USB connectors soldering crooked, so we got only a slow trickle of boards for the first couple weeks. Production only ramped up in the last week of the month. We shipped most of the September rewards in that last week and at least a couple hundred September rewards actually went in the mail on October 1st. Not as late as most Kickstarters, but still technically late.

Except for cases missing payment or missing info, all the October rewards did ship by mid-October.

Truth is, Robin and Erin did a LOT of work. So much that I was able to post regular updates on Kickstarter while we were all crazy busy. They really deserve a lot of the credit.


Regarding where Arduino is coming from and going to, I'm afraid I don't really know either. Massimo and Federico (of Dog Hunter) wanted to meet for a talk at Maker Faire last May. I came by their booth several times, but they were always too busy and rescheduled for another time. Each time, the same thing, they weren't available to talk at the time they has asked me to come back to meet with them. Some days I feel like I spend all day just answering questions and running around without making any progress towards any long-term goals. I'd imagine it's 100X worse for the Massimo and the Arduino folks.

On the positive side, they do seem to have put quite a bit of work into the new 1.5.X software. It does seem strange they're staying with the Atmel 32u4 on these new boards like Yun and Tes, rather than using SAM3 from the Due. I can tell you I plan to keep supporting the old AVR parts for a long time, but pretty much all new developments I have planned are going to leverage the awesome capabilities of these newer ARM parts. OctoWS2811 was really the first major development, besides just Teensy3 itself. Then I put months into the low-power update (much harder than it looks). The upcoming audio board and library is the next one....
 
Last edited:
Galileo sketch ...

void setup() {
// put your setup code here, to run once:

}

void loop() {
// put your main code here, to run repeatedly:

}

Compile message ...

Binary sketch size: 45,129 bytes (of a 262,144 byte maximum) - 17% used <--------<<<<:confused:
 
Then I put months into the low-power update (much harder than it looks)

Check to see if anyone can put the Galileo in a low power mode.:(

Intel will never learn why the ARM chips, that goes into most Apples products, are very power efficient.
 
Last edited:
For $60 this is perhaps a good solution for the folk who want to connect their projects to the internet, COSM, whatever.

FWIW, Massimo and Co. seem to have finally gotten the message and delivered a Arduino-compatible ARM solution that is actually Arduino compatible (i.e. the Tre). The Due is now either due for a redesign (no pun intended) or will likely orphan / be abandoned.

The Tre design finally acknowledges that true AVR shield compatibility is only possible with designs that are based on 5V AVR chips. Any 3.3V solution has to make compromises or use expensive work-arounds, whether it's in the ADC stages, digital pin compatibility, etc. In other words, don't bother making a shield-compatible design with a layout that fundamentally ignored the possibility of non-5V signal levels from the get go. That's perhaps asking too much of the Arduino team in terms of foresight, but they've had to live with that decision ever since.

The Tre also finally lets go of the Arduino 2009/Mega form factor and acknowledges that if a CPU has a bazillion inputs and outputs that it's likely time to adopt a new PCB form factor that can handle the plethora of connections. Shoe-horning a Due processor into a mega form factor only ensured one thing: Lost pins, leading to lost capabilities (i.e. massive RAM add-ons, for example) leading to the very folk on the bleeding edge who wanted / needed a Due processor writing the thing off. As a starter platforms it stinks, as a advanced platform it's been gelded by design.

So for those of us who want a AVR-compatible solution that can be connected to the internet of things, etc. the Tre is a lot more compelling, IMO. The only downside to the Tre is that it's targeting more advanced customers by design. Fewer people will want to deal with a Linux infrastructure on top of dealing with the Arduino IDE.

That, and any AVR chips that are inadvertently fried have to be replaced by someone familiar with SMD rework. Not mission-impossible stuff but something that people who run labs in schools will certainly have to take into account before allowing their students to use a Tre vs. a non-SMD 2009 or Uno board.

Designs like the Teensy 3 still rule the roost. Not because it uses the most powerful processor, etc. but because the design incorporates excellent capabilities into a small form factor that allows standard bread-boarding with the convenience of a USB connection. For the cost of one Due, I can have three teensy 3's offer almost as many IO pins, more ADC channels, etc. with the small software cost of coordinating the three via I2C, SPI, etc.

While all this hardware development is nice, BTW, I think the Arduino team ought to be focusing a lot more on modernizing the IDE to keep pace with the hardware. But that's a tough nut to crack without breaking a lot of china in the process.
 
I was pretty surprised to see the 32u4 AVR on Arduino's Tre board. This might be jumping to conclusions too quickly, but it certainly does seem like they're backing away from the SAM3X chip used on Due.

I'm not very good at predicting the future, or even what strategy any particular company ought to follow (maybe not even for PJRC's), but I do have to wonder if Arduino Yun and Tre are moving Arduino in a direction where the microcontroller ultimately becomes an I/O chip with a Linux-based brain?
 
I think Python on a $35 Linux device like RPi, with VNC or HDMI/monitor for the GUI, is very attractive to upper grades of primary education on to undergrads who are not computer science majors. I do think expectation management got out of hand for many younger students; they wanted it to be a PC. And since schools and students all have PCs, they would have been better to first teach software design and coding on a big PC, then move those skills to an embedded world. But that's not how things unroll.

The pioneering mbed just missed the mark, perhaps because they never invested in getting a proper TCP/IP stack.

Seems to me that a proper device driver AND properly documented/exampled code for GPIO/serial/SPI in Linux would eliminate the need for the co-processor. Odd that it hasn't happened.
 
Last edited:
While all this hardware development is nice, BTW, I think the Arduino team ought to be focusing a lot more on modernizing the IDE to keep pace with the hardware. But that's a tough nut to crack without breaking a lot of china in the process.

I am not sure I agree. Or maybe I am in a way ;-)

There are already very good alternatives out there that use the Arduino code base (Libraries, etc.) embeXcode and Eclipse with the Arduino Eclipse Plugin are two examples.
Another user, already has, or is going to get it working with Code::Blocks.
Maybe a little overhaul of the Arduino IDE is on order but the simplicity of it, particularly for new users is it's main appeal. I started 2 years ago with Arduino after 20 years of abcense from Programming and Electroniucs, using a any of the above mentioned IDEs would simply have been overwhelming. Due to my engineering backgound and experience in programming i was able to quickly move past the Arduino IDE and use Eclipse and the Arduino Eclipse Plugin now.

However, that does not mean that the Arduino IDE was not a necessary and important stepping stone. I'd much rather have them focus on providing efficient libraries and managing contributions to better consolidate the efforts as the wheel seems to be so ofter reinvented in the Arduino world.
 
...I do have to wonder if Arduino Yun and Tre are moving Arduino in a direction where the microcontroller ultimately becomes an I/O chip with a Linux-based brain?

Precisely. Use the tough proven, hard-to-kill hardware of yesteryear and combine it with more modern CPUs to leverage advances, such as 32-bit MCUs. Folk with shield investments don't lose them, vendors ditto. Going forward, come up with a new 3.3V-based shield factor. As abrasive as OSgled was with Massimo over at the arduino forums, he nailed that issue. Sticking to an existing shield factor for shields designed with 5V power on a 3.3V board was simply asking for trouble, confusion, etc.

Similarly, others have shown the way to the Arduino team by using the Uno, et. al. as a simple to use ADC/ GPIO module for the Rasberry Pi. Someone at Arduino central then woke up and screamed Eureka!, followed by "I want that", followed by months of work, rework, and more rework before the Tre could be announced. But the Tre is not spectacular, revolutionary, etc. - it's the product of a long effort to codify something under Arduino that was led, as usual, not by the Arduino team but rather by its user base.

FWIW, I attribute your Teensy 3 project to the haste with which the Due appeared to be released, i.e. the Arduino team couldn't handle being months behind the very visible and successful Teensy 3 kickstarter campaign. Hence they didn't have the time to fully hatch a plan, pushed for a release well before the Due product was really ready, and delivered a platform with significant flaws. In today's market, that is a death wish, there are simply too many good alternatives out there, starting with the vast universe of PIC microprocessors. BTW, I have no knowledge of what is going on in the Arduino team but the defensiveness of Massimo re: the Due in comparison to the Teensy 3 was telling.
 
The pioneering mbed just missed the mark, perhaps because they never invested in getting a proper TCP/IP stack.
Among many other sins. Just goes to show how first mover advantage is fleeting at best. We could also be using PICs instead of Atmels... but from what I heard, Microchip borked that opportunity.

Seems to me that a proper device driver AND properly documented/exampled code for GPIO/serial/SPI in Linux would eliminate the need for the co-processor. Odd that it hasn't happened.
Not sure how that would work. One of the beauties of the AVR chips is being able to do ADC as well as digital work on the same pins. But the 2009/Uno/Mega shields expect 5V-compatibility, something that is (AFAIK) hard to implement while preserving ADC and GPIO compatibility at a reasonable cost. Using a dedicated microprocessor and communicating via USB seems like a better idea, sort of like the Parallax approaches with the dedicated CPU cores, except you're essentially using a dedicated general-purpose chip for GPIO and ADC work, with all the usual downsides.
 
However, that does not mean that the Arduino IDE was not a necessary and important stepping stone. I'd much rather have them focus on providing efficient libraries and managing contributions to better consolidate the efforts as the wheel seems to be so ofter reinvented in the Arduino world.

Hear hear.

It would be great if someone could consolidate / organize the many efforts out there of working code for specific issues. The current library is a good start but between Google and the forums one can usually find better implementations than offered on the official Arduino site. IMO, it may be fun to reinvent the wheel for some (i.e. the challenge of learning to write good code) but for the vast majority of us, the focus is on getting projects working quickly. Finding more code examples by better organizing the reference section would go a long way. But given how the Arduino team has treated Mr. Stoffregen, I am not too surprised that such efforts are not undertaken on a more regular basis.

Just consider how much time Paul spends on this site on a day to day basis and then compare that to the frequency with which a core Arduino team member checks into the Arduino forums. I'm not saying they're oblivious or uncaring (they have jobs too) but the Arduino cast-mates certainly do not seem nearly as close to their customers as Paul, and that is squarely to their detriment. Not leveraging the many user-submitted sketches, hardware-builds, etc. simply makes it easier for someone brilliant like Paul to come along and obliterate the work of a team, single-handedly. If Paul had a couple more clones and could document more of the Teensy 3 the way he has documented the Teensy 2, the Teensy 3 would be even more compelling to use.
 
On PIC vs. AVR... Way, way back I used PICs. The architecture was beyond stupid. I quickly went with AVRs. But now-a-days, the low end Cortex are so appealing, with the single Flash/RAM address space. The two address spaces of AVR was my main objection, for programs that fit into 128KB or less. I never used 8051's, though they sure are still popular.
It would be interesting to know which 8 bitter has more current design-ins... I'll bet it's Holtek or an 8051 variant. Automotive must be another big driver - they say that modern cars have dozens - window control per door, and so on.

The hobby/student world is in the noise level, but with some fuzzy benefit of imprinting students that become design decision makers in their jobs.
 
This is truly an amazing board ...

You have to connect the 5 VDC power supply first before the client USB connector
or you will damage the board. The board takes more power than the USB provides
and by having no 5 VDC source power to the board will try to use the USB power and
might destroy itself. What happens if you lose your +5 VDC while connected to the USB
board - again the board is destroyed--> another $60 gone. Intel could have put an electronic
on-board switch to prevent this from ever happening. Even the 10 year old AVR Arduino has better supply
protections than the Galileo.
 
Status
Not open for further replies.
Back
Top