Date: Thu, 17 Dec 2015 14:54:10 +0000 From: "Brian McGovern (bmcgover)" <bmcgover@cisco.com> To: "Michael B. Eichorn" <ike@michaeleichorn.com>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: RE: Standardizing digital, analog control points in the kernel? Message-ID: <7a59c80486f6471a84f5e87ac3485aa4@XCH-RTP-005.cisco.com> In-Reply-To: <1450306085.1103.45.camel@michaeleichorn.com> References: <b45ed5b6d5d74a35b6e7af0fdae84110@XCH-RTP-005.cisco.com>, <1450306085.1103.45.camel@michaeleichorn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>________________________________________ >From: Michael B. Eichorn [ike@michaeleichorn.com] >Sent: Wednesday, December 16, 2015 5:48 PM >To: Brian McGovern (bmcgover); freebsd-questions@freebsd.org >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. -B=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7a59c80486f6471a84f5e87ac3485aa4>