...a look at the gluion's hardware is necessary, as its design differs fundamentally from most other sensor interfaces. While the latter are usually based on Microcontrollers (MCU), the gluion is built around a Field Programmable Gate Array (FPGA).
Now, when you design a system around an MCU you typically write a program (usually C or Assembler) that determines the program flow of the internal CPU, much like on a PC. However, in addition, an MCU provides a number of modules that perform tasks like communication (e.g. RS232 to a host), counting (e.g. pulses from a rotary encoder), or timing (e.g. the lag of an ultrasound pulse). Integrating those into the system usually requires proper interrupt handling, a task that can become tricky as the number of modules increases. Yet, for many projects that number is actually too low, so modules have to be shared among different functions which increases the overall complexity and can impact the accuracy of the measurements. Finally, each MCU offers a different set of modules so you can never be sure that your design will survive the migration to a new chip.
In contrast, an FPGA lets you define your own modules and how many you want of each. This is because an FPGA is essentially reconfigurable hardware where you don't program a given architecture but design one to your own liking. While this low-level approach may seem rather complicated where many wheels might have to be reinvented, it actually fits the requirements of a sensor interface well, where results from the measurement modules simply have to be forwarded to the host - no calculations are done, no CPU is needed.
For more details have a look at this paper: "the gluion - advantages of an FPGA-based sensor interface" (NIME 2006)
Now, coming back to the question, a configuration defines how the FPGA's elementary building blocks, logic gates, are wired to each other, thereby forming higher level modules which in turn can be connected to implement a complete system. On the gluion there is a combination of fixed and flexible modules. Fixed ones are present in every configuration as they handle common tasks, like the OSC/Ethernet connection towards the host computer. The flexible modules in turn implement various schemes for handling digital sensors. They can be mixed and matched depending on the current requirements - control for 60 motors in one project, a huge switch matrix in the next.
First, you decide which type of modules you need and how many. If you want you can also specify bit depths (i.e. resolution) and other details as well as the precise pin assignments. Next, you send me that information via email so that I can feed it into the main build process to generate the configuration file. This is then sent back to you along with an upload tool to store it into your gluion's EEPROM.
It might come somewhat as a disappointment that you cannot generate the configuration files yourself. The main problem here is that the tool chain is a bit complex and can't be easily shrunk into a nice, intuitive tool. For one thing it includes the Altera Quartus software which is Windows-only while most gluion owners use Macs.
That aside, past experience has shown that most users are happy with their default configuration, so investing my development energy into a cross-platform configuration builder can't be justified at the current state of things. Even developing an API against the core modules would be quite an effort. Likewise I am not quite ready to open-source the complete design (being written in Verilog this wouldn't help most users anyway).
Nonetheless this issue is still on my to-do list, albeit with a low priority. In any case I am open to suggestions. And one thing I do plan to provide in the near future is a collection of commonly used configurations.
One approach to solve the problem might be to introduce a meta-level that would allow for dynamic partial reconfiguration of the FPGA. This, however, would require a bigger chip which is being considered for the next gluion revision some time in 2008.
These usually provide two output signals where signal edges indicate a turn increment while their phase relationship depends on the direction.
The frequency is not all too high (a few dozen to a few hundred Hertz), however high enough that if they are sampled by a POSI the phase relationship (if not the pulses themselves) might be lost.
This is usually accomplished by transmitting an ultrasound pulse, then waiting for it to arrive at the receiver (possibly after some reflections). The time difference is then proportional to the distance between transmitter and receiver. In the gluiph/gluion time is easily measured with a counter at a resolution of 50ns, equivalent to a distance of 0.017mm.
In contrast a POSI has to play tricks with extra circuitry to convert time into voltage - like charging capacitors, resulting in a non-linear response, or using an extra microcontroller that transfers the counter value into a voltage which is then forwarded to an analog input - hardly elegant. And if you thought that your host PC could measure the time lag, remember that you are limited by the sampling rate of the POSI and that a 1ms resolution translates to 30cm! (and most of them or quite a bit slower)
This increases the number of buttons for a given number of I/O channels. E.g. in the example below only 6 I/O channels are needed to scan the state of 9 buttons (note that each key requires a diode in series to avoid phantom key closures).
A POSI wastes an input channel for each single button, 9 in this case. While this may not seem much of a difference, wait until you need to connect 100 buttons...
This is sometimes called "the poor man's DAC", but actually the best way to drive lamps and linear motors. Being a digital signal it's easy to transmit over long distances and can be isolated from the power circuit thru opto-couplers. What's more - the gluion also lets you measure PWM signals at its inputs as some modern sensors use it to transmit their sensor data (e.g. Analog Devices' ADXL202E accelerometer or Devantech's CMPS03 compass module)
Doing this with a POSI the limited timing resolution prevents you from gaining fine control over your devices - e.g. with a lamp you need a frequency around 50Hz (= 20ms) to avoid flicker. So even if your POSI has digital outputs and an update rate of 1ms you would only have 20 different intensities. In contrast the gluion with its 50ns interval gives you 16bit resolution at a PWM frequency of 305Hz.
These are used in the SKRUB and the Augmented Tuba to measure key position, where the metal plate detunes an LC oscillator.
To measure a frequency with a POSI you have to convert it to a voltage first and deal with extra circuitry again including linearity and precision problems.
Complementary to the frequency counter this module is preferable for measuring low frequency signals.
Currently a sub-class of the PWM module. Will soon get its own definition with proper half-stepping and internal acceleration.
A new derivative of the ultrasound module to use timing differences to locate a sound source
Currently includes RS232 for standard serial communication, MIDI to integrate vintage gear, SPI for talking to certain sensor chips, DMX to control lighting gear, PS/2 to acquire mouse and trackpad data.