Using a USB X10 Controller from an Intel Galileo

posted Mar 31, 2014, 11:26 PM by Michael LeMay

I recently purchased an Intel Galileo, and I’d like to use it in the future to control devices using X10.  This post describes my experiences setting it up and sending some initial test signals to an X10 device.

List of some of the parts I used:

1)      Intel Galileo

2)      Intel Centrino Advanced-N 6235 mini-PCIe Wi-Fi adapter

3)      X10 CM19A USB transceiver

4)      Micro USB (M) to USB (F) OTG host adapter

5)      Half-height to full-height mini-PCIe adapter

6)      Dual Wi-Fi antennas with U.fl connectors

7)      USB to RS-232 serial adapter

8)      16 GB UHS-1 microSDHC memory card

9)      3.5mm stereo to DB9 (F) RS-232 cable

Pictures of the top and bottom of the partially-assembled system:

Front of system

Back of system

I roughly followed the instructions in this post to install Debian on the system:

Firmware for the Wi-Fi adapter is in Debian’s non-free repository, which can be enabled as follows:

1)      Edit /etc/apt/sources.list.

a)      Duplicate the only line in the file and change main to non-free in the copied line.

2)      Run apt-get update.

To install the firmware, run apt-get install firmware-iwlwifi.

To setup a connection to a Wi-Fi network automatically when the system boots:

1)      Run apt-get install wpasupplicant.

2)      Edit /etc/network/interfaces and add a block like this to connect to a Wi-Fi network using WPA2 PSK security:

auto wlan0
iface wlan0 inet dhcp
      wpa-ssid <SSID>
      wpa-psk "<password>"

To connect to an X10 CM19A controller:

1)      Run apt-get install python-usb.

2)      Follow the instructions at this link to install and use the X10 CM19A Python driver, skipping steps 1 and 2 in the Linux tutorial:

I am employed by Intel, but the postings on this site are my own and don’t necessarily represent Intel’s positions, strategies, or opinions.

Brands and names belong to their respective owners.

Linux for Xilinx MicroBlaze on ML605

posted Sep 13, 2011, 1:47 PM by Michael LeMay   [ updated Nov 17, 2011, 11:50 AM ]


There are a variety of tutorials explaining how to run Linux on a Xilinx MicroBlaze soft-core processor, but none of them fully satisfied my needs.  My objective was to configure the Xilinx ML605 evaluation kit with a MicroBlaze processor on an AXI4 little-endian interconnect and boot Linux on it as quickly and simply as possible.  However, I am grateful for all of the guidance that those other tutorials provided to me along the way, and I have listed some of my favorites here:
This post is simply an account of what I remember doing to accomplish my objective and may be incomplete and/or incorrect.  Please feel free to contact me if you discover errors.  Thanks!


Setup the Hardware

  1. Connect your development system to the UART and JTAG ports on the ML605 using the USB cables in the kit.
  2. Power up the ML605.

Setup the JTAG Cable Driver

For some reason, the Xilinx tools crash when they attempt to access the JTAG cable.  To fix that, I renamed /usr/lib64/digilent/adept to /usr/lib64/digilent/adept.dis.  I discovered this fix here:  The tools still crash on exit, but the crashes don't seem to adversely affect their functionality.

Create the Hardware Design

  1. Open a new terminal (terminal #1).
  2. Source the Xilinx settings script (e.g. . /opt/Xilinx/13.2/ISE_DS/
  3. Create some project base directory and assign its location to the environment variable PROJ_BASE.
  4. mkdir $PROJ_BASE/xps
  5. Start Xilinx Platform Studio: xps
  6. Start the Base System Builder wizard.
    1. Save the project file in the newly-created xps directory.
    2. Click "OK."
    3. Click "Next."
    4. Add an axi_timer from the menu on the left.
    5. Click each peripheral in turn and check the "Use Interrupt" box if it exists.
    6. Click "Finish."
    7. Double-click on microblaze_0.
    8. Select "Linux with MMU."
    9. Click "Next" until you reach page 5 of 7, concerning caches.
    10. Change "Instruction Cache Base Address" and "Data Cache Base Address" to 0xc0000000.
    11. Change "Instruction Cache High Address" and "Data Cache High Address" to 0xdfffffff.
    12. Click "OK."
  7. Re-create DDR3 controller, DDR3_SDRAM:
    1. The default DDR3 controller created by XPS doesn't seem to be able to address all of the DDR3 memory.  So, double-click on it in XPS and use the instructions and files provided with this application note to update its settings:
  8. Download the device tree generator:
    1. Open a new terminal (terminal #2) and set PROJ_BASE.
    2. cd $PROJ_BASE
    3. git clone git://
      1. I used revision 5253637de2b1c4c45a9183b0ab7abe69fe37de6e.
    4. mkdir xps/bsptop
    5. cp -R device-tree/bsp xps/bsptop
  9. Click the SDK button (the red and silver diamond button in the toolbar) and tell EDK to export the project and launch the SDK.
  10. Select $PROJ_BASE/sdk-ws (expand manually) as the workspace.

Build the Device Tree Board Support Package

  1. In the SDK, open menu item "Windows -> Preferences."
  2. Navigate to "Xilinx SDK -> Repositories."
  3. Click "New..." next to "Local Repositories."
  4. Select bsptop in xps and click "OK."
  5. Click "Rescan Repositories" and then click "OK."
  6. Right-click in the "Project Explorer" pane on the left and select menu item "New -> Project..."
  7. Select "Xilinx Board Support Package" and click "Next."
  8. Select board support package "device-tree"
  9. Click "Finish."
  10. In the "Board Support Package Settings" dialog that appears, set "console device" to RS232_Uart_1.
  11. Click "OK."
  12. Select menu item "Project -> Build All."
  13. Close the SDK.

Download the Bitstream onto the FPGA

  1. Back in the EDK, select menu item "Device Configuration -> Download Bitstream."
    1. The console should say that "Programming completed successfully" after 30 seconds or so.  It may then crash, but that has not caused any noticeable problems for me.
  2. Close XPS.

Compile the Kernel

  1. Download the GNU toolchain:
    1. In terminal #2:
    2. cd $PROJ_BASE
    3. git clone git://
      1. I used revision 00163583b771bb4e937632765dd0c5516b3e31c4.
    4. cd microblaze_v2.0_le
    5. tar xzf microblazeel-unknown-linux-gnu.tgz
  2. Download the kernel source code:
    1. cd $PROJ_BASE
    2. git clone git://
      1. I used kernel version 3.1.0 from git revision 93ee7a9340d64f20295aacc3fb6a22b759323280
  3. Prepare the kernel source tree:
    1. cp microblaze_v2.0_le/initramfs_minimal_le.cpio.gz linux-2.6-microblaze
    2. cp sdk-ws/device-tree_bsp_0/microblaze_0/libsrc/device-tree_v0_00_x/xilinx.dts linux-2.6-microblaze/arch/microblaze/boot/dts/
    3. Download the config file that is attached to this page, place it into linux-2.6-microblaze, and name it .config
    4. cd linux-2.6-microblaze
    5. make ARCH=microblaze -j8 simpleImage.xilinx

Run Linux on the FPGA

  1. Start CuteCom and connect it to the proper serial port (probably /dev/ttyUSB0) at 9600 bps.
  2. In terminal #1:
  3. cd $PROJ_BASE/linux-2.6-microblaze
  4. xmd
    1. connect mb mdm
    2. dow arch/microblaze/boot/simpleImage.xilinx (this takes awhile)
    3. run
  5. Look for the output in CuteCom.
  6. If you see a root prompt, congratulations!

Health IT blog bundle

posted Jun 14, 2011, 2:53 PM by Michael LeMay   [ updated Jun 14, 2011, 2:56 PM ]

I recently joined the SHARPS project and have been reading blogs related to Health Information Technology (HIT).  There is a surprisingly large number of blogs on this topic across the web, so I have published a "bundle" of them to make it easier for others who are interested in this area to find them and add them to their RSS reader.  Note that there is also a large selection of groups related to this topic on LinkedIn.

Using inverse and forward search in Kile LaTeX editor

posted May 10, 2010, 7:07 PM by Unknown user   [ updated Apr 2, 2011, 9:13 AM by Michael LeMay ]

This feature is a huge time-saver!  Basically, click on a spot in the source file or in the DVI output, and Kile will take you to the corresponding spot in the other file. Kile is a KDE-based LaTeX editor.

  1. Open some LaTeX file in Kile
  2. Open "Settings -> Configure Kile..."
  3. Click "Tools -> Build -> LaTeX"
  4. Select the "Modern" configuration
  5. Set the options to -interaction=nonstopmode -src %source
  6. Click "ForwardDVI" in the list
  7. Select the "Embedded Viewer" configuration
  8. Click OK
  9. Click "LaTeX" in the build toolbar menu
  10. Click "ForwardDVI" in the view toolbar menu
  11. Open "Settings -> Configure Viewer..."
  12. Click "Editor"
  13. Select Kile as the editor
  14. Click OK
  15. Scroll to some interesting location in the document and hold down Shift while left-clicking on that location. It should jump to that spot in the LaTeX source.
  16. Scroll to some other location in the LaTeX source and click "ForwardDVI". It should jump to that location in the DVI.
  17. etc.

How I avoid lugging a laptop

posted May 10, 2010, 7:06 PM by Unknown user   [ updated Apr 2, 2011, 9:13 AM by Michael LeMay ]

Being a grad student, I end up working in a variety of places: office, home, hotels, etc.  Since I work on a variety of scientific projects, I require much more than the typical word processor, email client, etc. on my computers.  One of my biggest frustrations was synchronizing my work environments.  I was finding myself repeating configuration changes across my machines and having trouble remembering how each system was configured.  Keeping files in sync across machines was a particular challenge.  Subversion repositories work pretty well for most purposes, but it can be a challenge ensuring that all files are checked in and are even included in the repository in the first place.

A couple of different solutions usually spring to mind for addressing these sorts of issues.  First, I could carry a laptop around.  I dismissed that solution, because it's inconvenient and risky to transport laptops, and because laptop hardware is often less capable than desktop hardware.  A second possibility is using a remote desktop system to connect to a central machine over a network.  Unfortunately, I often don't have access to broadband.

So, I decided on a third option: perform much of my work within a virtual machine that is stored on a compact external hard disk.  To achieve this, I had to overcome several challenges:

  • Selecting a suitable virtualization platform that provides good performance, desktop integration, and portability
  • Selecting an external storage device that is compact, fast, large, and cheap
  • Configuring the guest operating system to have good performance on a variety of host platforms

The first one actually wasn't much of a challenge, because I already had a lot of experience with Sun VirtualBox and knew it would be a good choice for this project.  It's easy to configure, fast, and has lots of features.

I was initially planning to purchase a flash-based Solid-State-Disk (SSD) for this purpose, but changed my mind and decided on a 1.8" electro-mechanical hard disk instead.  SSDs have better performance than hard disks and are more rugged, but they cost much more per unit of storage.  I was going for the ultimate in portability, so I ended up selecting the Samsung S1 1.8" USB 2.0 120GB hard disk.  Tech moves fast, so that one isn't even a good option any more!  Its big brother, the 160GB edition, now sells for around $70.

An unanticipated problem with the disk is that it uses the new 4096-byte sector format, which is poorly supported by Linux 2.6.31.  Basically, the tools shipped with Ubuntu 9.10 choked on the disk, although it somehow was still recognized and automounted by the system.  I eventually attempted to re-label the disk using parted (since the kernel was complaining that it had an unrecognized label), but that segfaulted parted after corrupting the partition table.  I got around that issue by converting the disk to a GPT (GUID Partition Table, an EFI concept) disk in Windows 7 computer management disk manager.  I formatted it with NTFS using the maximum cluster size (64KB) since it will only contain a few, very large files.  This will maximize the available space and minimize disk management overhead.  I then recompiled the Ubuntu kernel to recognize GUID partition tables (I actually used Zen Kernel).

Using VirtualBox, I statically allocated a 54GB partition on the disk for an Ubuntu virtual machine.  Static allocation maximizes performance.  Actually, an even faster option is to provide the guest with direct physical access to a partition, but that is apparently no longer supported with recent versions of Windows, so it is only suitable if the VM is only run on Linux hosts.  I then installed 64-bit Ubuntu 9.10 in a straightforward fashion.

One customization that was helpful to me was permitting SSH access to the VM, so that I could forward X connections on my office desktop and thus utilize its dual screens.  Here are some instructions for that:

This whole effort had some unanticipated benefits.  First, I am now able to put my office desktop to sleep when I'm not using it, because I no longer need to access its files remotely.  This saves power.  Second, I was able to disable remote SSH access to my office desktop, which improves the security of the system (I used to observe many attack attempts against SSH on that system).

Overall, I'm quite happy with how this approach is working!

1-5 of 5