View Full Version : Intel Galileo

02-02-2014, 10:10 AM
Back in October there were two new Arduino boards that were announced. The one that I am most interested in is the Arduino Tre as it is based on the BeagleBone Black plus an Atmega32u(2 or 4). As I already have a BBBk and like it, especially as they are changing their default to Debian, I will grab one as they come out.

But the Other one introduced (Intel Galileo) also looked somewhat intriguing and they are actually starting to show up. So on a whim I ordered one from amazon.com, which arrived yesterday. I would hate to lose the label of changing directions every week :tongue:

So far I have not done much yet, other than to get it to work. Yesterday I could not talk to it on my main Dev machine (Windows 7 64bit), but later was able to get it to work on my Notebook. Finally figured out this morning that it does not like using a high com port number like COM65. I manually changed the device to COM6 and I can now talk to it and I have been able to program it with blink.

Things I noticed so far: little documentation, have to install a separate IDE based on 1.5.3.

I hope they are just being paranoid with how many places they write: You must connect it first to +5v, before you connect to USB, or you can damage the board...

It is like other Linux boards and takes a long time to boot up. I have not timed it yet but probably 30-45 seconds, maybe a bit shorter without linux installed on microsd. They have a really really small version of linux that is stored on the board itself. If I remember correctly the onboard linux is 8mb. This version does not support things like wifi. If you wish to use those features, you need to download an image to microsd card.

This card has a setup for debug terminal, that is already converted to RS232, which comes out at a speaker jack. They sell a cable that connects to this and comes out as a DB9. So then I have to use a USB adapter to it... Agree with Sparkfun review on this. I do have this and with it you can watch the system boot, where it goes into a grub menu and times out after 10 seconds...

Other reviews or posts that I have looked at:

That's all for now

02-02-2014, 10:59 AM

I wonder if you could get the boot time down to something reasonable like 2 or 3 seconds?

02-02-2014, 11:46 AM
Good question:

What I am not sure about yet, is how I would/will use this board. Things like maybe change the timeout for grub...

Example: It has the Arduino 1.0 shield connectors, which is nice and it does support some of the shields, but for me not sure about how well the IO would work.

For simple things like: looping setting an IO pin on and off, it is something like 500 times slower than an Arduino Leonardo (max of about 230hz). So I don't think any of these IO pins would work with PS2 inputs or SoftwareSerial...

As far as I can tell they only have one USART available. There is the 2nd one setup for debug through the other cable. Not sure in their Arduino setup how things plugged into the usb host port are enumerated and accessed... I doubt they come in as Serial1, Serial2...

I know that they have added a System command: Example in the Sparkfun link:

system("python /media/realroot/pyMail.py > /media/realroot/emails");
Where he has stored a Python program on the SD card and this allows the Arduino side to call it... Also in his example there is code showing how the Arduino side can read stuff off of the SD card which again is nice.

Up on their forum, it looks like several people are replacing the software on the board with Debian.

I will need to do lots of reading up there to learn more. I will probably take my time with it as I do have a few other projects I want to get back to.

02-02-2014, 08:38 PM
230 Hz for a single digital I/O is super bad!

Do we know how they communicate to the Atmega on the board? If it's something reasonable like SPI or I2C, it ought to be possible to run faster than that...

That chip should have ISA/LPC or PCI or PCI Express, though -- I wonder why they didn't design a "native" GPIO circuit instead, to get full speed.

02-02-2014, 09:51 PM
As far as I know the io pins are native. http://www.mouser.com/pdfdocs/GalileoSchematic.PDF
My guess is that all of the IO is going through from user level to kernel level, through File system. For example if you go to the debug terminal and type:

echo 3 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio3/direction
echo 1 > /sys/class/gpio/gpio3/value

It will turn the LED on.

02-03-2014, 12:46 AM
As far as I know the io pins are native. http://www.mouser.com/pdfdocs/GalileoSchematic.PDF
My guess is that all of the IO is going through from user level to kernel level, through File system. For example if you go to the debug terminal and type:

echo 3 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio3/direction
echo 1 > /sys/class/gpio/gpio3/value

It will turn the LED on.
The schematic shows the GPIO LED connected directly to the Intel SoC and the two Interrupt pins are connected to the header through a level-translator/multiplexer. Everything else non-I2C/SPI/UART interface at the headers is the multiplexed I/O of the I2C I/O expander or the SPI ADC.

02-03-2014, 08:52 AM
Thanks, Looks like I need to look more closely through the schematic.

I have taken a look through some of the Arduino code base, like wiring_digital.c and some of the other files like sysfs.c, back to variant.cpp. It looks like from the tables, that it is possible for some real fast IO pins that go direct to the SOC, but the others go through file handles. Looks like they have an open file handle for the Value files of each of the IO pins.


02-03-2014, 11:00 AM
My guess is that all of the IO is going through from user level to kernel level

Yes, but that shouldn't take 4 milliseconds each time :-) Not even if you open-configure-write-close the file each time.
Although any real program would just open the file descriptor and keep it open.
Their SoC is probably non-speculative, in-order, slow-as-Atom, but it STILL should be about as fast as an ARM of the same clock speed...

02-03-2014, 11:43 AM
I agree. I should probably try my own test on it and verify what the others wrote.

Looking through the code for digitalWrite
It looks more or less like I would expect. It converts the Arduino Pin number to the linux pin number, does a couple of checks (already output, not active pwm), then it checks can I do this real fast (don't see anywhere they enable this yet), and then it calls off to a helper function that does a

lseek(handle, 0, SEEK_SET);
write(handle, &set_value, 1);
On an open file handle that was opened at init time.

The only complication is if you write to pin 13, it detects that there is an alias pin for this and writes to this pin as well. The alias is the id of the LED.

Should just get out the LA and see.


02-03-2014, 12:00 PM
Did a quick Test:

void setup() {
// put your setup code here, to run once:
pinMode(2, OUTPUT);
pinMode(3, OUTPUT);
pinMode(13, OUTPUT);
pinMode(A0, OUTPUT);


void OutputPin(int pin) {
for(int i=0; i< 3; i++) {
digitalWrite(pin, LOW);
digitalWrite(pin, HIGH);

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

Each digital write is taking about 2.2MS


02-03-2014, 02:31 PM
Note: I ran the same test on a Teensy 3.1 and I show the average time on the digitalWrite of something like:

If that was not fast enough, I tried using the digitalWriteFast on the Teensy like:

for (int i=0; i<3; i++) {
digitalWriteFast(4, LOW);
digitalWriteFast(4, HIGH);
and the Saleae could not keep up. I tried configuring my 16 to sample rate of 50mhz and the USB did not keep up, but still did not
All I see is the pin go low and then high at the end of the loop and the width of the signal being low is 60ns.


Edit: Thought I would mention, that found more information and it looks like pins 2 and 3 of the Galileo can have fast access. More info in: https://communities.intel.com/message/207904

02-03-2014, 11:05 PM
Pins 2 and 3 (IO2 and ~IO3) are the two GPIO Interrupt pins (INT0/1) that connect direct to the Quark through a multiplexer/level-shifter and not the I2C I/O expander that controls every other GPIO pin.

02-06-2014, 03:36 PM
Yep - I still need to experiment some with those higher speed IO pins. Have not done much with it for a couple of days. Was waiting for a micro USB to host usb adapter so I can see what I can do with the USB. Example can I use the USB2AX adapter?

Was also wondering about can you connect RC servos to it. As the normal IO pins are too slow to be useful for this, thought about PWM. But not sure how well that works for this. From the posting: https://communities.intel.com/message/211417#211417

You have two choices, you can either set the frequency to 48hz or 188hz. The 48hz is a reasonable servo refresh rate, but it is only 8 bit PWM so step size is about 86us, or about 10 degree. At the higher speed, the step size is about 20.7us or about 2 degrees. But it sounds like a lot of servos don't like to be refreshed at that speed... I suppose if I really want to make this work, I should look at one of the Servo shields I have stashed would work (http://www.renbotics.com/servoshield.php), probably not. Their V2 probably would over I2C...

Again not sure how much I will do with this board.

02-11-2014, 10:02 AM
Quick note: for now, I think I will add this board to my graveyard list. Maybe it will be resurrected later, but still not quite sure what I would use it for...

Yes you can run it sort-of like an Arduino. There are a few shields that it supports (mainly ones who use I2C and maybe SPI). Yes I can get programs like blink to work, right out of the box. But: you reboot the board, and your sketch is not persistent. If you want it to be persistent, you can write it to your USB card and probably update the startup files...

Not sure if with their Arduino USB host plug, which devices you can plug into it and how you gain access to them. Example if I plug in a USB XBee (FTDI), does it create a new Serial object? (So far I don't think so). Also using debug terminal, did not create /dev/ttyUSBx device...

Then there are other minor things like, the release notes mentioning that the USARTS only support printable characters


I know that some of the people up on their forum are trying to use the card by building and running Debian. But they are so far having to go through hoops, like create a VM on their SD card, and use some Debstrap program to load it up... You have to use some older version of SSH or it faults the machine... Again I don't think it is ready for prime time.

And if I am going through hoops to boot up linux, why not simply use another Linux SBC like RPI, BBK, Odroid. Or use one of the other boards with Intel processor.

If I want an Arduino that runs faster with more memory with reasonable support, I would more likely pull one out like, the Arduino Due, or a Pic32 based one (Max32/Uno32)...

Again not sure!

02-11-2014, 10:22 AM
Sounds like you're making the right decision. Looks like a mess.

Get an LPC4088, its the future :)

02-11-2014, 08:10 PM
Get an LPC4088, its the future

If that's what you're after: Get an A10 or perhaps Exynos; it's cheap, quad-core, runs a variety of OS-es, supports lots of RAM, and even has a GPU should you wish to use it.

02-12-2014, 08:25 AM
But i don't want an OS :P. At least not right now. Someday (for me) those heavy hitting ARMs will be extremely compelling.

02-12-2014, 12:12 PM
The application that drives robot controllers into high-performance computing is computer vision. As long as you stay away from that, you'll probably do fine with the embedded CPUs :-)