Let's Get Physical

Why should free software be chained to keyboard, mouse and screen? In the first of a compelling and practical two-parter Martin Howse examines open tools which allow for embedding computation deep within the environment.


Physical computing is all about freedom from a highly restrictive desktop bound modus operandi in favour of new ways of approaching code and computation. Whether it's about examining imaginative modes of input and output, conditioning fresh responses in the user, investigating wearable processing or, at an other extreme, embedding sensor rich machines in extreme environments, getting physical is tightly bound with a free software model. Within a domain which stresses black boxing of software by the device in question, using free software in this environment is essentially all about visibility; devices which are otherwise totally opaque in relation to underlying tech become open and hackable, schematics are exposed to further development, interfaces are laid wide open and even processor designs can be readily implemented without encumbrances under extreme FPGA (Field Programmable Gate Array) led designs. And though embedding is commonly used to refer to any specialised system which is embedded within an often hidden purpose built device, for example an internal missile guidance system, it's possible to extend the definition to talk about embedding in a wider sense and to use such systems, perhaps within an artistic context, to refer to notions of environmental computing under which factors other than tightly bound I/O enter the computational equation. Embedded systems are all about embedding; laying down within a wider context which involves the physical. And within these terms, the notion of an interface is well untied from casual modes of thought. Indeed, standing both between hardware and software and between software and user or coder, interface is a ripe area for further investigation especially under the exposure of the overlap of both hard and soft enacted by reconfigurable computing. And although, as we'll see, we can readily interface microcontrollers and the like to a range of sensors, ranging from basic ADCs and DACs for audio capture and response, through to less apparent analogue data collectors such as accelerometers and magnetic field sensors, physical computing is more about running wild with a close knit of code and interface.

Chew on this

Though coaxing GNU/Linux through tweaking hardware and porting code to run on a very much growing range of small devices is definitely a possibility for physical computing which poses its own rewards, what we're more concerned with here is freeing ourselves from the further tethers of an OS which can penetrate tentacle-like downwards into hardware. Indeed, with OS defined primarily as both reliable and standard interface, and manager of resources, in our world of open, environmentally embedded hardware it's a tough call to see exactly what needs managing and how we could go about this awesome task. That said, it's perfectly feasible, given some awareness of how a full-blown OS may condition our device, to run with uClinux, a port to small and MMU (Memory Management Unit) deficient systems. The advantages here include ease of porting for already coded apps or those that lend themselves to a high level language, and hassle-free hardware support if you're looking to interface to a full-blown Von Neumann style architecture, or to other machines by way of high level protocols or, say, a wireless interface. It's an approach with a good deal of overhead both power-wise and conceptually but it works for a good many more conventional projects. On the hardware side, and of course well supported by the GNU/Linux toolchain, comprising GNU binutils, compiler set (GCC) and debugger, and pushing forward the uCsimm approach of a good few years back, the Gumstix Basix platform is very much de rigueur in such embedding circles. As the name would suggest they're the size of a stick of gum, lightweight and offer comparatively low power consumption stats. Performance under the Intel XScale is good, and a 2.6.10 kernel boots from flash to interface to optional Bluetooth, CF or RS232. Gumstix are perfect for a wearables project which needs to interface to a PDA or wireless enabled desktop. Indeed, the author first encountered them in use within this context at the Piet Zwart Institute in Rotterdam, where media students were constructing an audio narrative weaving jacket based on the platform.

SoC it to me

Development under a familiar OS and GNU toolchain is one way to go for projects which adhere to more conventional conceptual architectures, or which can leverage additional memory and code to add virtual machine layers, but physical computing aficionados have a good many more radical choices in reserve, which play well to varying degrees with a GNU development platform. Next down the hierarchy in terms of complexity and overhead we find the SoC, or System-on-Chip, processors which are very much in favour currently at the industrial end of the spectrum. As the name implies, it's all on board; CPU, RAM controllers, various buses, Ethernet and USB. Development boards with stuff like flash and 2.6.10 on board are readily available, with core CPUs such as PowerPC abounding, but most GNU/Linux DIY SoC work takes place within the burgeoning FPGA scene under the hardcore LGPLed LEON2 design of European Space Agency fame. FPGAs, with the conceptual emphasis on programming in the field very much to the fore, are a tough call to explain satisfactorily without some degree of low level knowledge of logic, processors and the like. FPGAs represent reconfigurable computing at the hardware level with vast arrays of gates reprogrammable through well defined interface with a conventional PC by way of a high level language such as VHDL or Verilog. VHDL, which stands for VHSIC Hardware Description Language, where VHSIC is yet another acronym for Very High Speed Integrated Circuit, is favoured in Europe, and such described code is then synthesised and uploaded to the FPGA rather than being used to fabricate costly silicon. With the correct software in place, a decent sized FPGA could function as well defined DSP one moment, offering up a bank of filters, or SoC after another upload. It's most definitely soft hardware and several scientists have thrown genetic algorithms (GA) into the mix to grow circuits which exhibit extraordinary properties. To demonstrate the sheer versatility of FPGAs, hobbyists have even succeeded in fitting the innards of a range of old-school arcade games, including Pacman, into a single and CPU-sized Xilinx Virtex chip. In the case of our friend LEON2, which is commonly implemented on the popular, but now discontinued Xess XSV-800 development board based around a Virtex FPGA, GNU/Linux has been ported to run on the SPARC-based core, with further SoC components thrown in by an active community of hackers. FPGAs are a tricky matter, with key documentation, particularly with reference to low cost development on a GNU/Linux platform, hard to find. Issues ensnared with physical computing are well exposed by these complex devices which will receive full illumination in the next instalment.

SoC processors, whilst usually employed in embedded devices which need to interface to regular I/O including large banks of RAM, run close in complexity terms to good old microcontrollers which make up the mainstay of free range physical computing. They're tough little fellows which can take a lot of maltreatment and suffer well under extreme environments, making them an ideal resource for rough and ready DIY work. It's important to differentiate microprocessors, or CPUs, from their larger microcontroller brothers which pack in processor (simply without the micro), memory, and often some degree of I/O within a small enough IC (Integrated Circuit). Such I/O can include serial communications support by way of a UART, multiple ADCs to play well with the analogue world, PWM which can enable motor and minimal audio, protocols such as I2C and the like and even USB support. The amount of additional circuitry required varies according to chip and required functionality, but it is possible to run with a microcontroller-based system simply with the addition of a suitable power supply.

Take your PIC

There are plenty of options out there on the micro front, with the two major players boiling down to Microchip, pushing the funky PIC range, and Atmel, with the rather more sober but equally Harvard architecture based AVRs. Other manufacturers in the field include Texas Instruments and Dallas Semiconductor, who do seem to be drawing some applause for their low-powered MAXQ line. Though it's equally possible to develop for a range of micros on a free software platform, we've chosen to concentrate development on a few PICs, which offer well documented resources and are upheld by a strong DIY subculture which shares a vast range of application documentation. PICs as concept and as acronym date back to the late 70s, when the phrase Peripheral Interface Controller was bandied around to refer to an intelligent I/O controller. Of course they can do a lot more now, but in a good many peripheral design instances it's well worth breaking out a low cost PIC at the beck and call of a PC app for, say, sophisticated motor control, analogue data acquisition or multiplexing. One example here would be the author's own use of such a design to control the motors of six record decks and interface with both a video switcher and laser driven display, all in real-time and all at the behest of high level software communicating with PIC by way of parallel port and code words. Another less complex example from a different project involved simple use of a PIC within a slider and knob based controller for audio work. Again the parallel port was the interface of choice and the PIC collapsed data to suit a 4 bit wide input regimen. Within a similar domain, the MIDIbox hardware platform is an open sourced project which offers a range of PIC-based MIDI hardware projects for implementing knob boxes and synthesisers galore. Such a project is a good start for those new to both PICs and interfacing to the humble PC. Moreover, key developer Thorsten Klose's MIDIbox Operating System (MIOS) seriously lowers the entry level for coders new to the PIC and can be used for control-led real-time MIDI and non-MIDI based applications. With schematics for sample projects online, and rich API documentation, MIOS makes for a complete and free development environment which can well be compared to other initiatives of note such as the Smart-Its project, which is all about embedding computation within the big bad world, or the Art Interface Device (AID) platform.

Aside from a perhaps secondary role as interface, tough old PICs make great embedders, and Microchip offer a vast range of processors to suit most needs, from tiny surface mount eight pin affairs, as used by folk at the University of Massachusetts to implement a match head sized Web server, through to 40 pin DIP mounting monsters such as the trusty old 16F877 which packs in a fair amount of ADC functionality. New on the block is the dsPIC line of chips which, as the name implies, throws DSP functionality into an already rich mix. Architecture-wise nearly all PICs usable for DIY embedding pack in varying amounts of flash-based program memory, which allows for in-circuit re-programming, plain old RAM, EEPROM for non-volatile storage of state and the like, and a variety of I/O subsystems. UARTs are both handy to have on board and thankfully commonplace, enabling easy serial communications between devices such as a PC and the micro itself. For truly standard RS-232C interfacing PICs must be beefed up with the a simple chip which takes care of ugly voltage level issues. Coders used to the world of the digital do well to shy away from the analogue realm and thankfully ubiquitous chips such as the MAX3221 or MAX3222 take care of all issues with few additional components. When coupled with the use of a reasonably high level language such as C, by way of a decent compiler, serial abilities make for easy debugging of devices in the field.

What's GNU got to do with it?

Running wild in the embedded field with a manufacturer or interpreter defined instruction set is one thing, but, aside from a suitable development model for PIC code, what's GNU got to do with anything? And how can we quickly and efficiently develop for such a platform whilst shying away from commercial development kits and softwares? Until recently, GNU PIC tools have suffered from a lack of exposure, or at least some degree of denigration in comparison to closed source counterparts which, under the gloss of the commercial, can well appear as of more industry strength. And though a central repository for a range of GNU tools does exist, it's somewhat less than complete and lacks the total breadth of other PIC sites which embrace know how, code and tools under all platforms. In the face of tackling a trinity of hefty learning curves which involves tackling hardware data sheets, learning instruction sets and GNU tools, it's little wonder that newbies turn to limited solutions such as the Parallax BASIC Stamp or to well specified IDEs. It has to be said that proprietary solutions imply containing and in the field of knowledge such an approach can win out over the heavily decentralised. Peer reviewed and daily updated community resources are the only answer; open sourced Pd has won out over centralised Max/MSP on these very terms.

In the first instance, reducing choice is a good thing. After newbies have the hang of basic tools which get the job done, other avenues can be sniffed out and new methodologies explored. Thus, the necessary and established GNU toolkit will be outlined here with reference to a few DIY programmers and a limited range of PIC micros. After all, if you're interested in building your own machines, why go all IKEA with the programmer hardware? A vast array of DIY programmers exist within a rich family tree of freely documented modifications well worthy of study by any genealogist. At the head of the tree we find David Tait's programmer, and, a particularly minimal favourite, the NOPPP, or no parts PIC programmer, which nevertheless does fall foul of any trade descriptions act. Both of these originally, and under most variants, hang off the parallel port and can be coaxed into attacking a range of devices, with small 16F628 (pin compatible with the now obsoleted 16F84) and 40 pin 16F877 workhorse as the hot favourites. Indeed, the choice of a suitable PIC will well condition which DIY programmer variant to kick off with. The 16F877, which packs eight 10-bit ADCs, decent-sized memory, a reasonable 20 MHz clock-speed and a sufficient number of timers and interrupts into a low-power, medium sized package, has long been the DIY embedder's chip of choice. Both Tait and NOPPP exhibit variants which can burn code into the 877 under GNU programming tools such as PICprg and specific NOPPP Linux software. Over the last year a brand new PIC, the PIC18F452, which is pin compatible with the 877, has pipped the older model to the post with more flash, more RAM, new instructions and a faster clock speed at more or less the same low price point. Both PICprg and NOPPP related hardware and software may need to be modified to work with this chip, but two projects, Brocolli18 and Odyssey, exist which can make light work of such modifications. For those who value sheer flexibility over a DIY approach, Microchip's very own Picstart Plus pre-built programmer, compatible with a vast array of microcontrollers is readily accessible by way of the free software Picp or GUI Gpicp interface.

Speaking the right language

Free software which actually gets your code onto the PIC is one thing, but it's very unlikely, though of course possible, that you'll be programming the chip in raw hexadecimal, the internal base 16 code of the PIC. How we talk to the PIC is an important choice which raises all sorts of issues relating to programming language and practise. Indeed, many artists and novice embedders choose to work with a costly pre-programmed PIC, the Parallax BASIC Stamp 2, simply because it can readily be programmed in simple PBASIC language by way of an on board interpreter. Another approach would be to simply compile code written in C or a custom language such as JAL into assembly language according to the specific instruction set of the chip and then burn this to flash using the GNU tools above. A free software toolkit could thus be specified comprising compiler, assembler, if we choose that route, and choice of programmer. Within any workflow it's worth working mentally through the steps which lead to hex hitting the PIC; a series of steps which includes all important acquaintance with PIC instruction set by way of Microchip's excellent data sheets. The choice of whether to work within high level language or assembly, or to mix and match both (see Desert Devices) can only really be attempted after such an exercise, and it must be said that the register and data juggling which raw PIC coding is prone to does offer its own rewards and insights into computational process. Larger projects, which the increased code size of newer PICs encourage, may well cry out for structured C programming, perhaps mixed with assembly routines which can attack bit-bound I/O. Yet, until relatively recently PIC programmers on a GNU/Linux platform had little choice but to put up with assembly or bed down with a commercial compiler such as c2c or CCS PCHL compiler. Thankfully SDCC, the Small Device C Compiler, which now targets a good range of microcontrollers, including our favourite PIC models, as well as other tiny devices, has snowballed since the early days. SDCC, which offers full ANSI C and a range of optimisations and also includes a simulator and debugger, is well documented online as to its use, and will readily generate PIC friendly Hex code. Example code is available for study, but it's worth stressing that commercial compilers, attacking a specific range of microcontrollers, are able to provide simpler library routines for I/O.

To do anything useful under SDCC, the full GPUTILS suite of GNU PIC tools will have to be installed, and it's also very useful to have these on hand for testing purposes. Having built a programmer, the next step would be to upload hex assembled from simple code, for example flashing an LED hanging from one of the PIC's digital ports. GPUTILS includes gpasm, the GNU PIC assembler, and the linking and combining functionalities of gplink, gplib together with a range of disassemblers and other useful command line tools. At its most basic, before getting bogged down in directives and relocatable code, gpasm quite simply converts our assembly source file of human readable instructions into hex. The resulting file can then be written to the PIC by way of PICprg and friends. Alternatively, those used to a more integrated approach will relish the recently developed PIKdev IDE which backs up editing and project management functionalities with the good old GPUTILS, cpik PIC18 C compiler and a programming engine to deliver the goods to the hardware. With correct hardware attached it's as simple as that. Or at least it should be. The embedded embrace of hardware and software is tough to prise open for the purposes of debugging and what can go wrong will go wrong. Although it's far more satisfying to make use of serial debug facilities a la printf, or LED-led morse code style message exchanges, simulation by way of Gpsim, the GPUTILS compatible simulator which throws in advanced components such as LCD screens and LEDs, can prove very useful if something is seriously wrong and it can certainly help narrow down problems to software or often flaky hardware. Of course, certain laws dictate that the last place we look will prove most revealing but it's tough to second guess that magic spot.

Desert devices

Fusing extreme computing with esoteric land art, and at the same time providing a good example of the multiple meanings attached to the term embedding and making a concrete case for environmental code, the ap0201 project refers to solar powered computational devices designed and manufactured by radical artistic group ap (Martin Howse and Jonathan Kemp). Three such devices, which each embed a virtual machine running code generated directly from environmental data, in this instance noise, within both the wider environment and a local Radio Frequency (RF) network, were installed in the Mojave desert in April 2004 with the assistance of CLUI (Center For Land Use Interpretation). Located within an extreme and remote environment, with only GPS co-ordinates to identify location for any intrigued visitor, the PIC16F877-based devices were built to last, with an envisaged minimum lifespan of three years. And within such an extended time frame, each device was designed to squeeze as much processing into 24 hours and, if sleep was necessary, to maintain state. In this instance voltage regulated solar panels were employed to charge four NiMH batteries which could thus power the PIC and peripherals during low light or at night. Charging circuitry, based around the excellent TEA1102 from Philips, interfaced with the microcontroller so that if voltage dropped, state would be saved to the 32 KB NVRAM which itself has a built-in battery to retain data for up to ten years, irrespective of external power. All collected code, which runs on top of the VM, is also stored in the NVRAM.

Ap0201 provides a good example of a real world PIC-based project both in terms of interfacing and coding requirements and a development cycle encompassing hardware design, prototyping, and a lengthy code and debug cycle sifting out hardware faults from software errors. A modular approach was adopted for both design and prototype implementation which made for easier debugging of hardware and software. Code and hardware modules could thus be tested independently to isolate faults. For example the RF transmit/receive modules were tested with very simple LED flashing PIC code. Later true Manchester encoding was implemented and again tested in isolation. In similar fashion, reading and writing to NVRAM, by way of logic which equally well allowed for writing data to the 16 digit LCD screen, was implemented as modular code. Other modules hanging off the computational mainboard include microphone pre-amp, and charging module. A serial interface, implemented by way of Maxim's MAX3221 chip, proved absolutely essential during development, allowing for both easy uploading of code thanks to the LINWLOAD package and Wloader bootloader, and for hassle-free debugging. VM stats were logged constantly to the serial port of an attached laptop in the field. Programming-wise, sections of code such as memory and LCD access which were seriously hardware intensive, involving plenty of toggling of logic lines, were coded in assembly but it proved far easier to port ap02 C code to compile under the CCS compiler. SDCC would currently provide a more satisfying free software solution. With serial comms and VM available, ap0201 points towards a vast range of intriguing applications deploying an interpreted control language within the PIC itself.

key links

Gumstix: http://www.gumstix.org

Microchip PIC: http://www.microchip.com

MIDIbox: http://www.ucapps.de

Smart-Its: http://www.smart-its.org

AID: http://aid.interaccess.org/drupal

Match head sized web server: http://http://www-ccs.cs.umass.edu/~shri/iPic.html

NOPPP: http://www.covingtoninnovations.com/noppp

NOPPP Linux software: http://patearl.net/projects/pic

PICprg: http://www.brianlane.com/software/picprg

Broccoli18: http://home.earthlink.net/~davesullins/software/pic18f.html

Oddysey: http://http://www.desert.cx/odyssey

Picp: http://home.pacbell.net/theposts/picmicro

SDCC: http://sdcc.sourceforge.net

GPUTILS: http://gputils.sourceforge.net

Gpsim: http://sourceforge.net/projects/gpsim

PIKdev: http://pikdev.free.fr

Desert devices: http://www.1010.co.uk/devices.html

Wloader: http://www.voti.nl/wloader/index_1.html

LINWLOAD: http://www.ise.pw.edu.pl/~wzab/linwload/linwload.html