Copyright © 2008, 2009, 2010 Marc Balmer. All rights reserved.
About one year ago, I wrote about how we used OpenBSD at the point of sale at the Basel Zoo. Well, the good news first: We replaced OpenBSD by NetBSD for our POS applications, both in development, but also for deployment.
I reworked the GPIO framework in OpenBSD last fall. Now I have taken my work to NetBSD and updated their GPIO implementation. While there, I corrected some mistakes made in the OpenBSD implementation and took it a step further. More development will take place in NetBSD, and there is quite a few interesting upcoming things to watch out for...
If you are interested in the latest userland accessible GPIO stuff, and the most up-to-date GPIO implementation, then keep an eye on NetBSD -current. This is where I am working on new stuff.
See http://blog.netbsd.org/tnf/entry/gpio_revisited for details. And stay tuned.
Every now and then someone asks on the OpenBSD public mailing list if it is possible to have a graphical application start at system boot time, circumventing the usual xdm login screen.
I had to do exactly this for info kiosks in public libraries, where a web browser is to be started for visitors to browse the online catalogue. Another application are point of sale systems where the POS application handles the login.
Basel has one of Europe's most beautiful zoological gardens, called the Zolli by the locals. It has a breathtaking aquarium with an enormous variety of rare fish, corals and lower animals. Pufferfish and Xenocara can be watched in their natural habitat. Starting january 1st, 2009, those two fish no longer only swim around in their aquariums but every visitor to the zoo must pass them...
OpenBSD has had support for General Purpose Input/Output devices since the 3.6 release. GPIO devices, or gpios for short, provide an easy way to interface electronic circuits which can be as simple as a LED or that provide more complex functionality like a OneWire or I2C bus.
The GPIO implementation in OpenBSD 3.6 up to and including 4.4, however, has some problems and drawbacks which made me rework larger parts of this subsystem during the h2k8 hardware hackathon in Coimbra, Portugal.
The other day, I got an email from Edd, an OpenBSD user, claiming that Samba would crash when serving files off an MS-DOS filesystem. This was Samba built from sources and not the one from ports. Since I use myself Samba a lot and for a quite large user base, I got interested in the issue and started investigating it.
What I found out in the end is a surprise and was not expected: A bug that has been there in all BSDs for almost all the time, since the 4.2BSD times or for roughly 25 years...
embed-it/bsd is a stripped down and slightly modified version of OpenBSD targeted at use in i386-based embedded devices like the PC-Engines ALIX boards. The most important design goals were
Ideally there are not much user visible differences to a standard OpenBSD installation, but since the whole system can be installed on CF cards as small as 16 MB, some tradeoffs have been made in the selection of binaries available.
Line disciplines have been in Unix since a long time. While they are not device drivers, they interact with tty devices in a very peculiar manner: They attach to a tty device and can then look at, or manipulate, the data as it flows through the tty device. Line disciplines are thus the natural choice when serial data is used in the kernel, e.g. to exchange TCP/IP packets over a serial link using the SLIP protocol or decoding date and time information and provide a timedelta sensor.
A while ago, Maurice Janssen (maurice@z74.net) sent me a modification of the nmea(4) line discipline to support the Meinberg Standard Time String format. With only a few changes, nmea(4) was turned into the msts(4) line discipline to support Meinberg's serial data format that can be emitted by all their radio clocks. I modified the code a bit, added a manual page, and added the bits needed to attach msts(4) to a tty to the ldattach(8) command. The result is that OpenBSD now has support for virtually any Meinberg radio-clock ever built.
I am currently writing a control and monitoring software system that makes use of GPIO pins. Since I was at the CCC congress in Berlin I did only have my laptop and no real GPIO hardware...
With only a laptop it's a bit hard to write GPIO software, since laptops usually don't have any GPIO pins. So what I needed to test my new software was either a real device (out of reach) or... writing a simulator.