erlusb

Contents

• What is erlusb?
• What is the plan?
• How do I build it?
• What is the license?
• Ideas
• Design arguments
  • USB interface library

What is erlusb?

erlusb might become an Erlang library with a general purpose interface to USB devices some time.

As of 2009-01-21, erlusb is just a personal research project to see how to interface an USB device to an Erlang program, and how to do an Erlang/OTP application design implementing such an interface.

The hope is that Erlang's binary pattern matching, message passing, and finite state machine support make writing device interfaces (communicating FSMs) easy, clean, and fun - as opposed to writing such interfaces in other languages.

What is the plan?

Reached Milestones:

0.5 Basic working OTP architecture

Planned Milestones:

0.6 USB device list querying and tracking of device hotplugging

0.7 Communication with USB device (example: Garmin GPS 60)

0.8 Code generalized from Garmin access to general device access

0.9 Polishing

1.0 one dot zero!

How do I build it?

Run:

$ autoreconf -ivs
$ mkdir _b && cd _b
$ ../configure --prefix=$PWD/../_i
$ make all check install installcheck

This requires that a number of software packages are installed, such as autoconf, automake, erlang, gcc, libtool, GNU make, and more.

It might also be possible to build in the source directory ("./configure && make && make install"), but this is not tested regularly.

What is the license?

No idea (yet). The complex2.erl and stuff are from the Erlang docs, anyway. Strong contenders for the license are LGPL and MIT/Erlang.

As of 2009-01-21, the code is marked as LGPL, but that might change later, depending on many factors internal and external.

Ideas

• gen_server for USB device access

  • One gen_server for each Erlang port / USB device, init/2 will open port.
  • handle_info/N being called by behaviour when non-OTP message is received (data from port)

• USB devices being local, the usb server process only makes sense as {local, Foo}
• A gen_fsm for devices might make more sense than a gen_server. Communicating with another device by messages is a classical example for communicating FSMs, after all.
• Make a decision: One Erlang port (one libusb instance per USB host) for all devices, or one Erlang port (one libusb instance per USB device) for each device?

Design arguments

USB interface library

First off, we needed to find out which underlying C API to use. Candidates included libusb-0.1, libusb-1.0, and openusb.

• libusb-0.1 (or libusb-compat-0.1)

  • compatible implementation for Win32 exists (libusb-win32)
  • no isochronous transfer mode support
  • very commonly used

• libusb-1.0

  • implementation for Win32 is in the works
  • isochronous transfer mode support
  • very commonly used

• openusb

  • does anyone use this at all?

The safest bet appeared to be libusb-1.0. It is widely used, and supports all transfer modes. So erlusb builds on libusb-1.0.