The dark side of porting Arduino sketches on Intel Galileo (part two)

Hi geek friends ( female & male)!

This is the post of the “real dark side” of porting external hardware control from Arduino to Intel Galileo. And, it’s just an example, a little sketch of the real work.

…Are you ready? Before starting this dangerous “trip” I want you send a first warning: unfortunately the x86 (the architecture of Intel Quark, the CPU inside the Intel Galileo) is very different from the architecture of the AVR (the Arduino MCU). So, registers, memory spaces etc. are completely different (Monty Python docet!).

My (insane, very insane 🙂 ) idea was to port some “lower level” code from Arduino Mega to Intel Galileo, in order to verify on my skin the real hardware differences between the two platforms and also in order to compare the “hardware level” performances.

I opened the “Arduino on Android kit” (a very appreciated gift from Monica! ;-)) and I found two very interesting hardware components: two ht1632c bicolor (red/green) led displays.

What a cool find! 😉 I love the shifting dysplays in the chinese stuff stores! 😀

So… I googled for already working driver on Arduino for these devices. I found some very interesting solution. The first one library is here, and it is very powerful and fast in my little opinion.

I tried on the Arduino Mega all the library demo sketches and I verified the correct work for my two displays. Looking inside the code I saw that all the library is based on AVR registers programming (using in every instruction all the possible bit-field functions, bit masks, bitwise operators and so on…).

Weahhhh…ok, I know this is the correct mode to write a driver, and it’s true that I wanted to go to a “lower level”…. but not so low! 😀

Indeed, once ported the code inside the Intel Galileo IDE, a so high number of “undefined references”  gave me the real proof that NOT ALL the AVR architecture has been ported by the Intel team in the Galileo development environment…. so we have two natural choices: the first one is to rewrite all the library using the Quark registers instead the AVR registers (but we are inside a Linux environment, it’s no so simple to manipulate the low level hardware without interact with the Linux kernel) or, the second choice is try to write a library at an higher level, using only the basic functionalities  (so using the native APIs) of Arduino.

I preferred the second oprion (…you suspected it, I know! :-)), so  I started looking for a little simpler (and without too many functionalities) library working directly on Arduino GPIOs, in order to simplify the porting phases (and possibly without losing my love in microelectronics 😉 )

I found the code  and the circuit reported on Arduino Playground (I love this site…because it’s a made in Italy product. You know, we don’t have only corruption, not-so-effordable persons & politicants… and soccer 😉 )….and -oh, oh- it was exactly what I was looking for. 😀

I took all the code and, after I removed the parts (code and hardware) related to the real time clock (because actually I don’t have a RTC!), I compiled the code in the Arduino IDE and I flashed it on my Arduino Mega. I obtained a “fixed hours and day” red and green clock on my two led displays. The draw of the displays is very fast (approx. immediate).

Ok, I ported the same code in the Galileo IDE and I obtained some compilation errors, tied to the hardware differences between Arduino and Galileo. This is the pinout for display I used:


Mainly Galileo IDE doesn’t have the <avr/pgmspace.h>… it’s natural since it’s a x86 CPU…but it is also a problem, because the great majority of third party lins use this file and its definitions (especially to declare some variable directly in the program flash, since Arduino doesn’t have so much RAM).

But since Galileo has a lot of RAM, it isn’t necessary to save data in the flash program space.

So, following the defines reported in avr/pgmspace.h , I changed in the file font1.h definitions:


in a simple

char* CHL[] = [...] .

After this, I removed the #include <avr/pgmspace.h> in the main .ino file,  and in the same file (function set_buffer()) I changed the line :

memcpy_P(buffer[j], (PGM_P)pgm_read_word(&(CHL[j+pos])), 8);


memcpy(buffer[j], (const char *)(&(CHL[j+pos])), 8);

Once resolved the errors, I compiled and flashed the code on Galileo.

I obtained a strange behavior: instead of the clock some strange character appeared on the two displays, with a very very (very! 😦 ) slow draw rate.

Ok, I think the strange characters are tied on a non perfect alignment on the memory in the x86 respect to the AVR  or to different sizes of some data type, especially due to the above memcpy porting  (but I didn’t investigated so much because I was worried by the displays slow draw rate). So, I changed the initial code in order to write a text on display pixel by pixel (note that this is the same approach of the original code), starting from drawing a single pixel in a certain (x,y) coordinate.

The differences between the initial code and my modified code can be easily found comparing the code in the page of Arduino Playground and the attached the zip file.

I attach the complete code as zip file since the code is too long for a blog post…and I think this post is already too long. But remember this is a “difficult” post. It MUST be long! 😉 Please excuse any commented code and some commentsin Italian…I know this is a lab “spaghetti code” . 😉

Ok, using this code the text is shown in the correct way on Intel Galileo (….to be investigated the strange drawing with the original code! 😉 ), but using Galileo the draw process took approx. 20 seconds (versus the Arduino result, which is minor than 1 second!!!) and with some different delay times between one pixel draw and the subsequent.

This is the final result (sorry for the up-down text, but I have very short wires between Galileo and the display…;-) ). In the background of the photo you can see two beautiful italian progressive rock cds by Maurizio di Tollo and by La Maschera di Cera (both my good friends), which have been the inspiration for my porting work. 🙂


Any ideas for this behavior (the slow drawing process)? I have one…but I don’t know if it is the correct idea.

As you know, Intel Galileo runs the Arduino sketches as Linux user processes (so, all kernel calls, interrupts, threads etc. have a higher priority  than a user process and so they can interrupt the execution of the Arduino skecth), whereas in Arduino no operating system is used (the sketch is a well-known “bare metal” code), so a real time behavior is a “true real time” behavior, and the sketch runs at the highest speed without interruptions.

So… what can I say? Intel Galileo is a really fast machine (compared to Arduino Mega or UNO) but in my little opinion it has some little “real time” problem when using the Arduino IOs (also I know my code is not optimized at all!!! 😉 ). And you? What do you think? 😉

Please, express your geek thinkings, and find al my errors! I will appreciate each contribution, especially  tied to my errors….the knowledge is always a mindstorm! 😉

Bye bye folks, now I go on my sofa to drink my brandy.

Another day is passed…another post is written. 🙂




10 thoughts on “The dark side of porting Arduino sketches on Intel Galileo (part two)

  1. Hi,
    As you may know, there’s a problem with avr/io.h -no Intel equivalent.
    For example using a PulseIn in an ultrasonic distance sensor.

    Is there a way to go around it ?


    • Hi dear ItMo.
      In my opinion the greater “defect” on Galileo is that the low level of x86 is different from AVR one.
      So, we can say that the boards Arduino and Galileo are NOT fully compatible. And the code is NOT completely portable.
      In other words, all third-party libraries which use under Arduino avr/*.* files cannot be used in Galileo “as they are”, but they must be modified/rewritten. This is the reason in my post I didn’t use the “official” library for led display, but I used high level functions. 😦
      Plus, I never used an ultrasonic sensor, so I don’t know how this library is written… I will study it and I will google around. I think I could find an higher level solution (as per my led display)…so, stay tuned! 😉

      • Dear Itmo,
        searching on the INtel community, I found this interesting thread:
        Well… the user BlackCode in the 5th answer to thread defines a new function “pulsein2”, which uses oly high level functionalisties (it emulates via polling on the pin the reception of a ping).

        unsigned long pulseIn2(uint8_t pin, uint8_t state) {
        unsigned long pulseWidth = 0;
        unsigned long loopCount = 0;
        unsigned long loopMax = 5000000;
        // While the pin is *not* in the target state we make sure the timeout hasn’t been reached.
        while ((digitalRead(pin)) != state) {
        if (loopCount++ == loopMax) {
        return 0;
        // When the pin *is* in the target state we bump the counter while still keeping track of the timeout.
        while ((digitalRead(pin)) == state) {
        if (loopCount++ == loopMax) {
        return 0;
        // Return the pulse time in microsecond!
        return pulseWidth * 4.72; // Calculated the pulseWidth

        I don’t know how how it is predictable/precise, but it could be (maybe) a good workaround… even if I think it should be tested on Galileo in order to adjust the constant values…
        Let me know if it is a good start for a solution in your application!

  2. Thanks,
    I used digital IO2 and IO3 that can work with OUTPUT_FAST and INPUT_FAST.
    still need some modifications, but I do receive reasonable input.

    If at some point you’ll be able to do some work on avr/io.h in Galileo – that would be greatly appreciated!


  3. Pingback: The dark side of porting Arduino sketches on Intel Galileo (part three: comparing Galileo and Arduino on realtime) | ML's Garret Labs

  4. Dear Garret Labs. I’m having some difficuly understanding how the display ” SURE ELECTRONICS P4 32X8 3208 RED LED DOT MATRIX UNIT BOARD SPI LIKE” Arduino ethernet works. – I would like to add some buttons and potentiometers to the system. For exampe: by pressing the 1 st button the name display with the memorised name could light up per minimum 30 seconds and so on for the entries on the other buttons. – I would like to know how to add two potentiometers: one to adjust the speed of sliding and one to adjust the time. Thank you in advance. Looking forward to your kind reply. Best regards

    • Hi dear Francesco,
      thank you for your comment.
      The display you have is very common.
      Have you tried to visualize something on your display using one of the libraries (very complete and powerful) on internet?
      For example : or
      They permit (if I well remember) to set also the speed of sliding (horizontal or vertical direction).
      Then, in order to use a potentiometer to set the speed of sliding, you can start modifying this basic sketch:
      Once you read the value of the potentiometer you can set the speed of display sliding (using the right function present in the display library)
      Same thing you can do with buttons, starting andf modifyinng this example:
      I hope I’ve gave you a good start/idea for your work! Good luck!
      If you need some more detailed hint, feel free to ask!
      Bye bye and…keep in touch with Garretlabs!

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