The dark side of porting Arduino sketches on Intel Galileo (part three: comparing Galileo and Arduino on realtime performances)

Hi dear geeks and Intel Galileo lovers!

I’m sorry if I abandoned for a while your preferred board…but as you know Garretlabs (and I) have many other interests (Raspberry based projects, music and so on…).

Today I want to front one of “dearest” problems of my life: the realtime behavior and characteristics of  boards.

I know, it is one of my preffered psychiatric problems: I want ALWAYS to know the realtime performaces of a board (and of his operating system, if present)  😉

So, this time I want to compare the realtime performances of Arduino UNO and Intel Galileo.

In order to do it, I used the most simple circuit that I know (and that YOU know): one blinking led.

Well, the circuit in Fritzing is:

test_realtime_Galileo_vs_UNO_bbAnd the software is the same (obviously) for both boards:

void setup() 
    pinMode (2,OUTPUT);
void loop() 

So, the behavior of code should be very very (very) simple: 10 milliseconds the led is ON and 10 milliseconds it is OFF. So the GPIO2 output is a 5V square wave, with a period of 20 milliseconds  and a duty cycle of 50%.

I connected the channel 1 of my oscilloscope to TestPoint1 and the channel 2 to TestPoint2.

As you see the behavior of the two boards are very different: since the square wave of Arduino UNO (TestPoint 1) is fixed on the timeline with a period of 20 milliseconds, the square wave of Galileo is moving on the timeline and it has more long period than 20 milliseconds. It means that the period is not exactly 20 milliseconds, and it is variable.

This is the trace for Arduino UNO:


As you see, the square wave is perfect (…note that the horizontal scale is 10 milliseconds for division)!

This is the trace for Intel Galileo (stopped in a certain moment, since the trace is continously shifting right):

Oscill_galileo this case the square wave  has a period major than 20 milliseconds (because each half wave has a duration major than 10 milliseconds).

Plus, if we measure two random periods, they havent the same duration (the continuous shift of the trace is depending on this).

These are both waveforms:


So, for me the result is clear: since Arduino UNO commands GPIOs using a very strict realtime, Galileo does not command GPIOs with a realtime scheduling politics.

The motivation can be probably tied to the fact that Galileo launches Arduino scripts as Linux user processes (as I noticed in my prevoius post), so without realtime characteristics.

My conclusion is that, at the moment, we can’t use Galileo as hard realtime controller for particular hardware (ie. safety critical mechanisms and so on). 😦 …

And what are your thinkings about this behaviour of Galileo? Have you found my same results?

Obviously, possible solutions and workarounds are welcome (I thinked to modify the Intel Galileo native Linux in order to add some realtime extension, i.e. RT-PREEMPT or Xenomai).

So, the discussion is open! Let me know what you think! 🙂

…Bye bye electro-babes!


7 thoughts on “The dark side of porting Arduino sketches on Intel Galileo (part three: comparing Galileo and Arduino on realtime performances)

  1. Rather than compare Galileo vs Arduino Uno… Why not compare Galileo vs RazPi. Both have Linux OSes… both would “in theory” have similar realtime performance issues.
    I have no problem with your experiement; just question if this is really an apples vs apples comparison

    • Thank you for the suggestion dear Zittware. I compared Galileo with Arduino because this was a clear intention of mine and of SirsLab of University of Siena, in order to give a feedback to Intel about the realtime performance of Galileo.
      Bye, and keep in touch!

      • Thanks for doing this experiment. I was wondering the same thing. If you are doing motor control or anything else that is dependent on having equally spaced time samples, you really need to know the real time characteristics of the board. The Galileo has a much faster clock speed so I was looking into it as an alternative to Arduino. Now I know it likely will not work for my application.

      • Thank you for your comment dear Bob!
        I’m happy to hear that my experiment has been useful for you!!
        Keep in touch with Garretlabs!!

  2. Hi…
    Is that possible to display the time period of cycle in program. since it is continuously increasing I want to see those values.

  3. I was also doing same thing. I was trying to display the time accurately. I couldn’t able to do it. could you display the real time taken each cycle.

    • Hi dear Gopal.
      I think it is very difficult to have the accurate value of time in real time embedded systems…for this reason I often use oscilloscope. 🙂
      Neverthless, someone uses the function millis() but this function measures miliiseconds, and it can be not enough precise.
      A more accurate approach can be adopted using micros(), which measures microseconds, with a resolution of +/-4 microseconds. It could be sufficient for major needs. You can read here for examples:
      Thank you for your comments, and keep in touch with GL!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s