Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Dec 2015 14:54:10 +0000
From:      "Brian McGovern (bmcgover)" <>
To:        "Michael B. Eichorn" <>, "" <>
Subject:   RE: Standardizing digital, analog control points in the kernel?
Message-ID:  <>
In-Reply-To: <>
References:  <>, <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
>From: Michael B. Eichorn []
>Sent: Wednesday, December 16, 2015 5:48 PM
>To: Brian McGovern (bmcgover);
>Subject: Re: Standardizing digital, analog control points in the kernel?
>On Wed, 2015-12-16 at 20:58 +0000, Brian McGovern (bmcgover) wrote:
>> All,
>>   This is a question that I'm sure could span multiple lists and
>> multiple perspectives; for example, there is probably significant
>> input to be had from -arm. However, I'm going to ask here to try to
>> get the biggest collection of feedback.
>>   I've been working with a number of I/O capable devices for awhile -
>> Pis, Beaglebones, for example, but also a lot of the USB Velleman
>> boards, X-10, Insteon, etc.
>>   I've been contemplating a project to consolidate the various
>> control points, with a certain amount of metadata, at the userland
>> level and provide a standardized interface - most likely through a
>> network socket via XML, some form of HTTP, a combination, or
>> something else entirely. The reason would be to sufficiently abstract
>> the various layers so that domain experts could focus on specific
>> areas - for example, device driver writers could focus on adding more
>> devices which provide control points without needing to provide
>> server or applications bits, UI writers and control applications can
>> worry about looking pretty and communicating through a language-
>> independent interface, and so forth.
>>   The question I have is whether a.) Anyone is looking at doing
>> something similar, and b.) if anyone is looking at doing something
>> similar inside the kernel as a device driver, filesystem, or other
>> variation (e.g. I'm thinking of something like ucom, where the low-
>> level hardware drivers plug in to it to provide a generic user
>> interface on top)?
>>      -B
>This is an interesting idea and I think that a unified method for
>handling I/O would be very useful. It sounds like you are mostly
>talking about maker, home automation, and internet-of-things type devices,=
 but it might have applications for scientific data acquisition and industr=
ial control as well.

>Also such a stack should support realtime computing. Interestingly it
>appears that RTLinux died in 2011 so this could be an advantage for
>FreeBSD in IoT and Maker devices. Realtime is, in my opinion as a
>mechanical engineer, essential for any system that might control an
>appliance/drone/robot, or for that matter data acquisition in general.
>That said, I do like the idea of separating the application logic and
>the gui out from the details of the individual devices being used.

My commercial work experience in the space was commercial building automati=
on via Andover Controls devices back in the late 80s/early 90s (Andover has=
 since been acquired by Schnider electric) which ran over BACnet.

What I'm hoping to do as the primary goal of my work is to define a network=
 layer protocol for the data exchage. That way, if drivers and userland var=
y on FreeBSD vs. Linux vs. fill-in-another-OS, it theoretically doesn't mat=
ter - a Linux based UI should be able to control a protocol compliant Raspb=
ian system, or a FreeBSD box. Similarly, if you want to use C, or C++, or P=
ython, or Java, or fill-in-another-language to connect to the network and c=
hat with a device, it doesn't matter. At the end of the day, users should b=
e able to select best-in-class for the various layers, and plug it together=

In designing, I'm stuck at the point of having a fairly common layer pointi=
ng at the network, and bolt-on "device drivers" for the various flavors of =
I/O. For example, the Beaglebone ADC has a driver which operates via sysctl=
(); the digital pins use GPIO. Vellemen USB boards, X-10, and Insteon inter=
faces are basically USB serial streams, each with their own proprietary com=
mand/response protocols.

Hence, as a secondary goal, I'm curious to explore setting up a common fram=
e work for the typical types of I/O one typically sees in this space - Digi=
tal I/O, Analog I/O, potentially things like driver enforced tri-state.

In terms of "Real Time", I dislike the term mostly because it becomes terri=
bly abused to mean what the engineer wants it to mean. Using the definition=
 of "of or relating to a system in which input data is processed within mil=
liseconds so that it is available virtually immediately as feedback, e.g., =
in a missile guidance or airline booking system." (Google definition, shoul=
d you want to trace my steps), its not impossible, but its well outside the=
 scope. Most operating systems have large, asynchronous components, and the=
 network will have all kinds of random variations on timing. Unless you man=
aged everything on and off the wire, you may get that kind of response most=
 of the time, maybe even every time, but I doubt it'll be warrantied.

Further, "correct" systems have to have other considerations - power on sta=
tes, loss-of-control failsafes, and so on, most of which are either above o=
r below the layer interfaces.


Want to link to this message? Use this URL: <>