The version with the LUT is AVR specific, but the generic library that calculates 1/D should work just fine on the Due.
(http://code.google.com/p/arduino-distance-sensor-library/)

This project looks really impressive and is very cleanly written and documented.

I have several questions:

• Did you start from scratch or is this code based on an other RTOS implementation?
• How does RTuinOS compare to protothreads? (http://code.google.com/p/protothread/)
• How does RTuinOS compare to DuinOS? (http://code.google.com/p/duinos/)
• What was the main goal for developing this project? (since other similar implementations exist)
• Is/was this part of a university thesis or research project?
• You have 10 example applications in your library, have they been tested in real world applications or are they just a proof of concept at the moment?

I think that this project deserves more attention.
Maybe you can move your project to a public Github repository?
That would make it a lot easier for people to find.

[Program flow:]

The last days, I have been working on my first Python program named: "arduino_testsuite"

GitHub project page: http://jeroendoggen.github.com/Arduino-TestSuite
Page in the Python Package Index: http://pypi.python.org/pypi/arduino_testsuite

This program allows automated running of several Arduino unit tests. The testing process is started on the PC but the tests run on the actual Arduino hardware. One set of unit tests is typically used to test one Arduino library.

Program flow:
The following steps are performed for each set of unit tests:

• Read the config file to find out which tests to run
• • The script compiles and uploads an Arduino sketch that contains the unit testing code.
  • The unit tests are run on the Arduino board.
  • The results of the test are printed over the serial port and analyzed by the Python script.
• The script starts the next test, repeating the above steps for all test that are requested in the configuration file.
• The script prints a summary showing an overview of all the failed/passed tests in the complete testsuite.

Dependencies:

• The unit tests are written with the "Arduino Unit Testing Library": http://code.google.com/p/arduinounit
• The tests also use "Arduino Unit Testing Helper Library": http://code.google.com/p/arduino-unit-test-helper-library
• The code is uploaded to the Arduino board with "Arscons: scons script for Arduino": http://github.com/suapapa/arscons

Why is this useful:

• While reading the book "Test-Driven Development for Embedded C" by James W. Grenning, I was wondering if some of the proposed methods could be applied to the arduino platform
• More info on TDD: http://en.wikipedia.org/wiki/Test-driven_development
• I found two tools for unit testing: http://code.google.com/p/arduino/wiki/ArduinoTestSuite and http://code.google.com/p/arduinounit
• I preferred the simplicity of the "arduinounit" approach over the "ArduinoTestSuite" which is -as far as I know- used for Arduino core development.
• The only thing missing was an easy toolset to run multiple test at the same time...

Typical test output:

Code:

jeroen@computer:~/tests$ python -m arduino_testsuite
=============================================================
Planned tests:
 1. examples/floatingPin
 2. examples/inInterval
 3. examples/simpleTest
 4. examples/buildErrorTest
 5. examples/nonExistingFolder
 6. examples/slowTest
 7. examples/verySlowTest
==============================
.... output normally continues for a while ... link to full log below.

Full log in: https://raw.github.com/jeroendoggen/Arduino-TestSuite/master/resources/example.log (number of characters per post is limited)

Comments are more than welcome. (remember, this is my first Python program...)
 

Update: The current version provides a unified interface for four sensors:

SRF04 & SRF05 Ultrasonic Ranger
Sharp GP2Y0A21YK IR Distance sensor
Sharp GP2Y0A41SK IR Distance sensor

This version no longer uses a LUT, but calculates the transfer functions of 1/D at runtime (they are nearly linear).

Inheritance diagram:
http://arduino-distance-sensor-library.googlecode.com/hg/Documentation/InheritanceDiagram-DistanceSensor_v2.png

I have a semi-decent version of the generic DistanceSensor class.
(warning: the code compiles but is not yet tested using actual sensors)

Top level class: DistanceSensor
Level1 classes: hardware type/group specific code: class for analog sensors and class for timing based/acoustic sensors (AccousticDistanceSensor, AnalogDistanceSensor)
Level2 classes: sensor type specific code:  (DistanceSRF04, DistanceGP2Y0A21YK)

Now adding other sensors with different LUTs or timing options should be straightforward: just add a new "level2" class.

Source: http://code.google.com/p/arduino-distance-sensor-library/

Doxygen documentation: http://arduino-distance-sensor-library.googlecode.com/hg/Documentation/latex/refman.pdf

Inheritance diagram:

direct link to the spreadsheet: http://gp2y0a21yk-library.googlecode.com/hg/Calculations/CalculationsDistanceSensorTransferfunctionLUT.xls
(works fine for me using LibreOffice)

The option for runtime calibration is planned for "Version 0.6: Compare different sensors, calculate replacement LUT (at runtime) based on calibration points" (copy past from header file :-) )

I currently have 5 sensors that are tied together sitting on my desk.
My plan is to do this runtime testing/calibration using 5 sensors to check for inter-sensor differences.
I haven't done the experiment yet because I needed some extra wires + breadboard, to connect them all at the same time.

It think the best approach would be conditional compilation with 3 options:

• speed optimized: my current code
• code size optimed: the multimap version using your approach
• default: 4(?) bit LUT combined with multimap 

A more (too?) complex solution might be:

• a standard generic LUT: 8 bits
• + a 'differential' LUT for each individual sensor: using calibrated values: 4 bits

Lots of possibilities...

Is was not aware of your multimap code, but it might be interesting to add your approach as an extra option since it will result in a smaller code size, at the expense of some execution speed.

What you are doing in the multimap function is almost what I did in a spreadsheet to calculate my LUT values.
I measured some values and calculated the intermediate points using two polynomial approximation of the tranfer function. (one for 80 to 20 cm, an other one for 20 to 5 cm).
You can find the (messy) spreadsheet here: (the comments are in Dutch): http://code.google.com/p/gp2y0a21yk-library/source/browse/Calculations/CalculationsDistanceSensorTransferfunctionLUT.xls

How exactly would this make the lib more generic? Since the only hardware specific code is the actual LUT.
I plan to make one generic "DistanceSensor" lib, that supports other distance sensors. (e.g. http://code.google.com/p/srf04-library ('sonar' sensor))

(español, con traductor Google)

Es una buena idea añadir más información a los ejemplos.
He añadido una página wiki, con un poco información básica.
http://code.google.com/p/arduino-signal-filtering-library/wiki/SignalFilteringBasics

"Int" es de 16 bits en el código de Arduino, ya que el ADC es de 10 bits, esto debería ser suficiente (para algunos de los cálculos es necesaria una mayor precisión)

@ionhs: Realmente no se entiende la pregunta, pero un estándar de Arduino no es lo suficientemente rápido para procesar la señal de audio en tiempo real.
@JMN: Mi uso principal del filtro de un sensor de distancia :-) (Sharp GP2Y0A21YK IR Distance sensor) (http://code.google.com/p/gp2y0a21yk-library )

I don't really speak Spanish, but this might be useful: http://arduino.cc/forum/index.php/topic,52681.msg376017.html#msg376017

Depending on your program/goals you could:

• Sample the sensor from time to time and use "millis()" to calculate the time that has passed and then calculate the average displacement
• Sample the sensor using fixed timing, e.g. 10 samples per second, using a periodic wake-up of the board, and then calculate the average displacement. Periodic wake-up can be achieved using this nice library: https://github.com/rocketscream/Low-Power

I would prefer the second option.

Maybe this was not really clear: the filtering code was written by scjurgen, I just reused it.

I wrote a small c program to do some tests and to understand the calculations better.
Data  multiplied by 0.08 is always less than 82, but the "long tmp" value in binary representation is much bigger (18 up to 30 bits in my tests).

I have split up the calculations in four parts and I print the intermediate results in decimal and binary.
The program prints the tmp value for three possible incoming samples: 1, 512 and 1023 (using 0,0,0 or 1023,1023,1023 as the 'history')

tmp1 = (data * 662828L);
  --> print tmp1:
       tmp1: 662828
       tmp1: 00000000000010100001110100101100
tmp2 = ((data * 662828L) >>  4);
  --> print tmp2...
tmp3 = ((((data * 662828L) >>  4) + ((_v[0] * -540791L) >> 1) + (_v[1] * 628977L))+262144);
  --> print tmp3...
tmp4 = ((((data * 662828L) >>  4) + ((_v[0] * -540791L) >> 1) + (_v[1] * 628977L))+262144) >> 19;
  --> print tmp4...

Total output:
http://arduino-signal-filtering-library.googlecode.com/hg-history/2770a5e0dae02e0ef56ace52d35fc6c350648b25/TestCode/FilterShiftingTest/debug.txt

The code: (+compiled linux and win32 binary)
http://code.google.com/p/arduino-signal-filtering-library/source/browse/TestCode#TestCode/FilterShiftingTest

[16]

Thanks!

I actually did not really pay to much attention to the math and just used that version based on performance.
(the other version of the code written by 'scjurgen' all use floating point math)

The 16 bits in an Arduino short seemed reasonable, considering the 10 bit ADC.
(16 vs 8 bits for the short type: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1261049420/1#1)

I made little library based on some of your filter code.
The goal of this library is to make is very easy for anyone to use (basic) signal filters when reading analog sensors.

I plan on adding more filters later on: running average, Kalman,...

http://code.google.com/p/arduino-signal-filtering-library/
 

I added some Arduino specific settings and keywords to a C++0x Kate highlighting style.
The colors are loosely based on the original Arduino IDE syntax highlighting style.
_{The XML code it still quite dirty, but it works...}
http://code.google.com/p/arduino-kate-syntax-highlighting/

Example:

These reading are strange and might be caused by a low supply voltage.
The sensor should work at 3.3V, but if you have a 5V Arduino board, I would advise to use the 5V Vcc.

PS: I did some sensor calibration tests and created a small library:
http://arduino.cc/forum/index.php/topic,83947.0.html