Weekly Edition
Return to the Kernel page
| |||||||||||||
APIs for sensors
Environmental sensors were, once upon a time, equipment which were only
found in specialized settings like industrial process control or scientific
research. They were expensive and tuned to a specific task.
Increasingly, though, sensors are being attached to all kinds of devices.
Mobile handsets have compasses, accelerometers, and more. Sensors for
temperature, pressure, etc. are becoming increasingly common as well. The
implications are fun; any Linux machine can be a versatile data collection
device.
The only problem with all of this is that the Linux kernel does not yet have an established API - either internal or to user space - for sensors. There are interfaces for specific types of sensors; Video4Linux2 handles cameras, for example, and the hwmon subsystem deals with the specific class of sensors aimed at monitoring the health of the computer itself. In these areas, the interfaces are well established and interoperation is possible. For sensors which fall outside of these classes, though, there are no real rules. The outcome of this kind of situation is always the same: new devices are added with inconsistent interfaces, making life hard for application developers. This situation came to light (again) with the recent submission of a pressure sensor driver which was implemented as a misc device. It used the input subsystem to present its interface; Jonathan Cameron, who has been working on sensor interfaces, pointed out that the patch would not be accepted in that form. Input devices are meant for human input; since most humans do not communicate with their systems via large ambient pressure changes, this device did not fit. So the driver needs another home. The hwmon subsystem was suggested, but the pressure sensor is not really a hardware monitor, so the driver is not welcome there either. Arnd Bergmann also does not like the use of the misc interface:
I generally try to prevent people from adding more ad-hoc
interfaces to drivers/misc. Anything that is called a drivers/misc
driver to me must qualify as "there can't possibly be a second
driver with the same semantics", otherwise it should be part of
another subsystem with clear rules, or be put into its own file
system.
That leaves the industrial I/O (IIO) subsystem, which is meant "for devices that in some sense are analog to digital converters." IIO tries to handle a wide variety of sensors in some sort of standard way with support for events, higher bandwidth I/O, and more. There are quite a few drivers in the IIO subsystem now; the only problem is that the whole thing lives in the staging tree and the associated "TODO" list is reasonably long. The devices which are represented there now are not all consistent in their interface use - and the form of the desired interface is not at all clear. Still, putting together such an interface is Jonathan's goal:
To my mind, there will one day be a suitable 'sensors' subsystem so
an important side point is to try and minimise interface changes
needed to move to that (IIO or something better). Sysfs is easy to
fix, so lets at least work on shared interfaces in there. Hwmon is
a mature and reasonable starting point; it's where we got a lot of
IIO's similar interfaces from. The trick is convincing people to
consider generality and it's a hard trick to pull off.
He adds that the interface and support for simple devices (those with slow data rates and hwmon-style sysfs interfaces) is in reasonably good shape. The question is how to get the rest of the job done. One alternative would be to define an essentially new IIO core which would be merged into the mainline. Individual drivers could then be worked into shape and moved over once they are ready. The problem is that this could be a long process, and that the mainline versions of the drivers might not initially have all of the functionality of their black-sheep staging cousins. That would mean more maintenance work keeping both versions of the driver working for some time. Still, that's the approach that Arnd recommends. The move to the mainline is the last good chance to define an interface which will then need to be supported for many years. So some pain now, if used properly, may be warranted in order to make life easier in the future. Getting driver developers to buy into this idea may not be entirely easy; most of them spend the bulk of their time doing something other than writing Linux driver code and may lack the desire to move to a new interface when what they have now works. But that's almost certainly the best way forward. Now is almost certainly a good time for people with an interest in this area to help in the development of the mainline version of the IIO interface. (Log in to post comments)
APIs for sensors Posted Mar 17, 2011 13:52 UTC (Thu) by ebirdie (subscriber, #512) [Link]
Why industrial I/O (IIO)? Why not enviroment I/O (EIO)? That name would fit in hwmon semantically as hardware is the environment for software to live in, isn't it.
"Industrial I/O" could put off someone's thoughts, when thinking about where to write a driver for a weather station or radiation gauge.
Just a thought.
APIs for sensors Posted Mar 17, 2011 18:04 UTC (Thu) by jic23 (subscriber, #56049) [Link]
I'm certainly open to a better name.
Environmental to my mind covers your cases of a weather station and radio monitor well, but what about a resolver (rotation ADC) on a motor, or a 3 phase power meter? The issue is that environment carries a lot of baggage as a term.
The industrial bit came from an early LKML discussion and has really just been a working name ever since.
APIs for sensors Posted Mar 24, 2011 15:34 UTC (Thu) by ebirdie (subscriber, #512) [Link]
What about word "instrumentation"? It should cover input and output from outside world not taking into account the qualities or environment where the I/O comes from.
APIs for sensors Posted Mar 26, 2011 10:23 UTC (Sat) by efexis (guest, #26355) [Link]
Encompassing Industrial/environmental instrumentation IO, or E-I-E-I-O?! :-)
APIs for sensors Posted Mar 17, 2011 22:11 UTC (Thu) by knan (subscriber, #3940) [Link]
Comedi is the traditional linux API for data acquisition, but has been out-of-tree and niche forever, and seems moderately dead in staging. As in pining for the fjords.
APIs for sensors Posted Mar 17, 2011 23:59 UTC (Thu) by giraffedata (subscriber, #1954) [Link] Just what do all sensors have in common (that they don't also have in common with every other I/O device)?I've worked with many sensors, and I haven't seen any opportunity for sharing code or interface protocols. They're just too diverse -- both in implementation and basic concept.
APIs for sensors Posted Mar 18, 2011 15:42 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
They provide samples at specific times, from various different sources.
Hmm, maybe they should be exposed as multi-channel audio devices in ALSA...
APIs for sensors Posted Mar 18, 2011 17:10 UTC (Fri) by giraffedata (subscriber, #1954) [Link] They provide samples at specific times, That definition should be made clear in any discussion of a sensor subsystem or API, because there are lots of other ways to understand sensors. The things I use that I call sensors provide samples only when I ask for them, and if there is any periodic sampling, the periodicity is provided way above any device driver.
from various different sources. That's the opposite of an answer to the question, "what do sensors have in common." Unless you mean what they have in common is that every one is unique. :-)
APIs for sensors Posted Mar 20, 2011 18:36 UTC (Sun) by knan (subscriber, #3940) [Link]
>>They provide samples at specific times,
>That definition should be made clear in any discussion of a sensor >subsystem or API, because there are lots of other ways to understand >sensors. The things I use that I call sensors provide samples only when I >ask for them, and if there is any periodic sampling, the periodicity is >provided way above any device driver.
A sensor may sample something a million times/second in a high energy physics experiment, for example. Polling one value at a time doesn't scale well in that case. So those bits are PCI cards that do the sampling at x megasamples/second, batch them and do DMA to the computer proper.
A sensor measures something. I think that's the only thing they have in common ;)
APIs for sensors Posted Mar 20, 2011 20:45 UTC (Sun) by giraffedata (subscriber, #1954) [Link] A sensor measures something. I think that's the only thing they have in common ;) You may have missed my point. If this is all sensors have in common, then it doesn't make any sense to have a sensor subsystem or a sensor API. On the other hand, if "sensor" means something that produces samples at a high speed stream like your physics experiment example, a subsystem or API might make sense. In that case, though, one has to make it clear that is what "sensor" means (and really, one should use a different name, like maybe "streaming sensor").
APIs for sensors Posted Mar 21, 2011 5:14 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
sensors gather data, but from there things branch out
some sensors generate data on a periodic basis and send it in, the kernel need to do _something_ with the data.
that something can be to add it to a circular buffer (note the possibility of a size 1 buffer that only keeps the last report) so that if some application cares about the data it can ask for it (including asking for historical data in some cases)
that something can be to invoke some processing with the data
some sensors generate data only when asked
many sensors have initialization that's required, and sometimes that initialization can determine if the sensor is gathering data all the time, or only when requested (along with tweaking many other things about the data gathered)
a great sensor framework would encapsulate the sensor configuration and initialization so that even if the sensor only generates data when asked, the application could tell the framework that it wants that data gathered every X ms, and what it wants done with that data when it is gathered.
by hiding the capabilities of the sensor from the application, it would make it more likely that a new sensor could be used with an existing application
APIs for sensors Posted Mar 18, 2011 0:02 UTC (Fri) by giraffedata (subscriber, #1954) [Link] The pressure sensor in question appears to hook up to the memory bus (something like PCI?). Given how expensive that is, I'm curious as to why. All the sensors I've worked with connect through some intermediary such as RS-232, USB, or ethernet controller -- which of course obviates device drivers.
APIs for sensors Posted Mar 19, 2011 0:25 UTC (Sat) by eli (guest, #11265) [Link]
... and all-too-often doesn't change the ID from the RS-232-to-USB converter's ID, leaving you to guess what's on the far side. :/
APIs for sensors Posted Mar 18, 2011 19:50 UTC (Fri) by Silverback (guest, #62273) [Link]
Hmm, I'd think the National Instruments folks (and others in their industry) would weigh in on this. It's been their focus for an awfully long time. At the very least, it seems they may have some notions to emulate.
|
|||||||||||||