User: Password:
|
|
Subscribe / Log in / New account

APIs for sensors

APIs for sensors

Posted Mar 18, 2011 15:42 UTC (Fri) by BenHutchings (subscriber, #37955)
In reply to: APIs for sensors by giraffedata
Parent article: APIs for sensors

They provide samples at specific times, from various different sources.

Hmm, maybe they should be exposed as multi-channel audio devices in ALSA...


(Log in to post comments)

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 (subscriber, #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


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds