Sunday, August 3, 2014

Galileo and Arduino first impressions

The Galileo board is a lot smaller than I had imagined, and there's a lot more parts on it than I had expected.  Schematics helpfully provided shows them to be various I/O expanders, drivers, PWM generators, buffers, and muxes.  These are type of features that are integrated in a typical microcontroller, and it's interesting to see external parts being used to make up for the missing features in the Quark SoC.  On the flip side, the board has things like Mini PCI Express port so the PC heritage does help in other ways.

The other thing that I noticed - and it actually bothers me quite a bit for some reason - is that the Galileo PCB comes sans standoffs.  The board sits awkwardly on the Mini PCI Express connector and it teeters unnervingly whenever I need to hit the reset button.

You can't tell, but the LED's blinking, I swear!
Galileo runs full fledged Linux distribution under the hood, and the schematic makes it seem like the Linux boot console is likely to be UART1, which comes out of a header.  A bit of sleuthing shows that the original Galileo had the UART wired in to a microphone connector, so I'm glad that I can just get something like this instead of having to cut open a headset cable.  Mouser has the actual FTDI part with breakout board that I prefer, but having to track down some headers to solder on and additional female to female jumper cables makes it much more expensive to go that way.  Driver support for CP210x part seems decent from quick searching, but that's one of those things that you never know until you plug it in the USB port.

Galileo running with a full, modern operating system does present some interesting challenges on the Arduino side.  Looking at the Arduino tools and the example 'sketches', it really shows its microcontroller roots.  Arduino presents a very simple interface to the end users, providing them with a way to write C code divided into 'setup' and 'loop' routines.  Setup sets all the one-time options at the start of operation, and once the system is up and running, loop will run basically forever.  In the sample 'blink' sketch, functions like pinMode and digitalWrite in microcontroller world can probably map directly to a macro that does a simple memory write operation.

The blink magic happens here
Linux (or pretty much any other operating system) can't willy nilly give raw hardware access to any program that comes its way - it's a surefire way to have unstable unusable system once you have more than one program running at the same time.  Things like GPIOs are typically exposed as sysfs in embedded Linux, and sure enough, you dig down just a bit and you can see in places like hardware/arduino/x86/cores/arduino/wiring_digital.c how the magic happens.  Simple functions like pinMode and digitalWrite ends up poking into sysfs, writing strings like "high" and "low" into the sysfs tree to toggle the bits on and off.  This code then gets compiled into Linux ELF binary, and gets sent to the Galileo board using 80s technology over the serial link.

Intel provides Galileo Linux Examples that shows how to expose some of the power of Linux underneath the device, partly by running a series of system() calls.  One of the examples is how to redirect the console to the port used by Arduino tool, but it seems to get stuck for me on Galileo Gen2 - we'll see if I can get the issue figured out before I either dig out an old switch to connect to the ethernet port, or Amazon delivers the USB to UART converter.

What is clear is that Arduino platform is barely scratching the surface of what Galileo is capable of.  To really understand Galileo, I'm going to have to dive down much, much deeper.

No comments:

Post a Comment