Intel Galileo - "What were they thinking?"

The Intel Galileo is one of the more frustrating embedded / small system boards I've worked with.  I'm really not sure what Intel was thinking.  It feels like one of those "we need to get into this market" types of projects that is an off target response to ARMs penetration in the home hobbyist / small systems market. Intel has some work to do if they are serious about this board.  I suspect they will abandon it and try again with some other product.

We've seen other projects from companies that have attempted to do the same thing.  The Microsoft .Net Micro Framework with the associated 2-3 board makers come to mind.  It was too small a market for Microsoft to commit any resources too. They open-sourced .NET MF and let it go fallow for at least two years.

Pros

  1. Intel did a great job hacking the Arduino IDE to make it easy to build and run Arduino style sketches without any real knowledge of how the board works.
  2. There is 8MB of flash memory.
  3. It uses a powerful X86 CPU.
  4. The board comes bundled with an all-country adapter.
  5. The board has an Arduino shield compatible header that works with some of the shields already on the market.
  6. There is a hardware console port that can be monitored in addition to the normal Arduino monitoring via the psuedo-tty USB connection.
  7. The board includes a hardwired Ethernet port.

Cons

Board and O/S

  1. You can fry the board if you plug in the USB connector before plugging in the power supply. I would expect this from a home brew board but not from a professionally created board targeted at the embedded marketplace.
  2. Sketches are lost across reboots when using the board as shipped.  This makes the board totally useless in any embedded application.  Imagine having to reprogram your Microwave every time you lost power.
  3. O/S configuration changes are lost across reboots when using the board as shipped.  This means you can't configure the network or start other processes without adding system calls to your sketches. 
  4. The on-board Linux is trimmed down to fit in the ROM.  It is hard modify the package so you are stuck with whatever Intel installed.  Systems like the Raspberry Pi and Chumby mandate that you use an SD card for the O/S and file space.  
    • Intel provides an SD card image that lets you add more features and save sketches across restarts. 
  5. The data sheet says that sketches can be saved in Flash memory. This does not appear to be true.  The operating system erases them on restart if it is true that they are put in flash.
  6. The documentation on the two versions of Linux feels different because they come from two different source tracks.  The in-ROM version is called a Board Support Package while the other is often referred to by the way it is built , "Yocto".
  7. The Galileo consumes a lot of electricity for its power.  It uses about 2X the power of a Raspberry Pi and several times the power of the ARM and TI based boards.
  8. The Quark CPU is X86 compatible but does not support certain features like some of the vector instructions.  Intel uses they Atom processor for phones and tablets which means low power and a wide understanding of software portability issues. They should have used the Intel Atom for this board also.

Communication

  1. Intel included a mini-card slot for a wireless network card.  The onboard Linux supports that card.  I'm not sure why they did that instead of just adding more USB ports. Other systems come pre-loaded with BroadCom or other wireless drivers that gives you access to a lot of inexpensive network cards. The Raspberry Pi works this way.
  2. Intel included a hard ware serial console port.  They used an audio jack similar to that used on a lot of router or homebrew hacking projects.  
    • Intel made theirs an actual RS-232 port that requires an RCA-to-DB9 cable.   Most laptops don't come with RS-232 ports any more so a lot of people need a second USB to DB9 cable. I can only guess the folks building the board were using desktop machines to work with the Galileo
    • Most other boards and hack products rely on FTDI style USB-to-5V or USB-to-3.3V adapter cables.  They can be purchased on line with RCA plugs already attached.
  3. Intel isn't capitalizing on the power of the quark processor to provide upgraded communications capabilities. USB supports multiple virtual endpoints. Some products use this to provide separate programming, console and other functionality across a single USB connector.  The Quark processor has plenty of CPU power to support this.
    1. The Arduino has a very simple model for the single serial port used for communications and programming. It simulates a serial port on the host system.  This makes it possible to use RF protocols in addition to hard-wire serial communication without any modification to the host programs.  They did this out of necessity because the early boards communicated to hosts using a simple UART through a serial-to-USB bridge chip.

Embedded Functionality

Most of the I/O pins are implemented in I/O expanders instead of being directly connected to the the CPU or system on chip.
  1. The Galileo is at least an order of magnitude slower for I/O operations because of the hardware and software architecture.  You just can't do some things with the Galileo that you can with cheaper, lower power boards.
  2. Two of the pins can be configured for high speed operation. This helps but requires custom register programming and is still not actually the same as an Arduino board.

Conclusion

The Intel Galileo feels like a "first try".  I personally would stay away from it and wait for their next attempt.

Popular posts from this blog

A full context breaks three local models, each in a different way - 7

Image
In freemansoft/Flutter-AdaptiveCards a demonstration Dart chat server hands a question to a local Ollama model. It asks for the answer as Adaptive Card JSON, a strict, closed-vocabulary schema that a Flutter client renders as interactive UI rather than as text. A set of probes in that repository puts identical questions to different local models. Probe context_fill_probe.dart  produced every figure in this article. It runs 25 test cases, one question each. A test case passes only if the reply used an element type that would answer the question. Every other probe in that set had been asking into a nearly empty window. That window holds a system prompt, one question, and at most a short canned exchange showing the model the shape of a card. The literature documents that a long context degrades model behavior. What it does to a model's adherence to an output format is measured less often. The test probe simulates a long conversation by filling three q...
Read more

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

Image
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with  gadget drivers  that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget  is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device.  All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget  in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update  or  Upd...
Read more

We tried 14 levers to get reliable SDUI card JSON from a local LLM model - 2

Image
In freemansoft/Flutter-AdaptiveCards a demonstration Dart chat server hands a question to a local Ollama model, asks for the answer as Adaptive Card JSON, and a Flutter client app renders the reply. Everything below is an attempt to make that card generation more reliable and more faithful to what was asked. The figures are transcribed from ModelBehavior.md , a lab notebook in that repository. Terms used in this article The first two describe the ledger, the rest name what the levers changed and how each was scored. Probe and flag names are the repository's own. Term What it means here Lever One change tried against the card failures, recorded in the notebook's tuning ledger with its outcome and evidence. Fourteen are counted here. Kind The layer of the system a lever touches: context assembly, meaning what precedes the question in the mes...
Read more