On Thu, Jul 24, 2008 at 11:44:36AM +0200, Eric Piel wrote: > Henrique de Moraes Holschuh schreef: >> On Wed, 23 Jul 2008, Jonathan Cameron wrote: >>> The subsystem is now in a functional state with a small set of drivers: >>> >>> Max1363 (supports numerous Maxim i2c ADC's) (tested with max1363 and max1238 chips) >>> - Uses a periodic timer to provide ring buffer mode. >>> - All reads form these devices are scan modes so direct single element access >>> is not provided. >>> - Monitor mode on max1363 is not yet supported (need to do a bit debugging of >>> the board I have so as to be able to test this). >>> >>> ST LIS3L02DQ - SPI accelerometer. >>> - Uses a datardy interrupt to driver a software ring buffer. >>> - Most functionality of this device is supported. >>> >>> VTI SCA3000 (tested with an e05) >>> - Hardware ring buffer. >> >> I'd like to see something done to have the common parts of interfaces of the >> same class (e.g. accelerometers) be standard. Like hwmon does with >> temp#_input, etc. >> >> Otherwise you made it easier to write drivers, but did nothing to help >> userspace to USE the drivers :-) > Hi, > I completely agree with Henrique. There already exist 3 accelerometer > drivers in the kernel (and I'm writing a fourth on). What we are > desperately in need of is a _user_ interface. So that a generic program > can pop up and say "Oh, there is an accelerometer on this computer, I'll > use it to detect free falls." > > IMHO, I think the ADC should have a much more specific and specialised > (user and kernel) API corresponding to the accelerometers. Granted, you > probably had in mind only the accelerometers for industrial usage, but > it would be much better if the current accelerometer drivers had a > reason to be ported to this new subsystem. > > In particular, what I think would be worthy would be: > * Up to 3 pre-defined axes (X, Y, Z) - that's provided by your current > version of industrialio > * If the accelerometer is soldered on the computer, define once for all > to which _physical_ movement corresponds which axis (eg: a laptop on its > normal position going up has axis Z increasing). > * Free fall event. Either it's hardware detected, or the accelerometer > infrastructure will detect it in software. > * For each axis, what is the maximum and minimum bound and the unit - > Probably worthy for the whole ADC infrastructure > * Joystick emulation (calibrated so that when the computer is not > moving, all the values are at 0). All the current drivers have it. I think if we're trying to make something that will cover a number of device classes, we need to be more like HID and have a system that reports and possibly records the following: 1) What data is possible to be returned from each event, with the units, magnitude and any scale applied by the device sending. 2) Each event should be able to report a number of items, so that if the sensor reports X/Y/Z in one go, there is just a single event containing those values. 3) A well defined set of information that can be read (like #1) that can provide details of the device and how it relates to the environment it is in. -- Ben (ben at fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes'
