Very nice. Although the current Arduino I2C library works for me (single reads to a register), I thought it was kind of "klunky" the request operation.

Thanks for the replies.

pluggy, I am just a beginner and like to leverage the libraries as much as I can, but thanks for the tip.

Graynomad, I did some more digging.  0022 adds the time out to the reading part of the code: https://github.com/arduino/Arduino/commit/4dad13532fbd9fcc14acd157d3fc20e295c38101#diff-0

Question to the implementors:

+  // to be 20 clock cycles long and have about 16 clocks between the edge   

+  return clockCyclesToMicroseconds(width * 21 + 16);

The comment in the new code says 20 clock cycles long, but code uses 21 cycles.  I remember in my implementation 20 was more accurate than 21...   Is 21 more accurate than 20?

Thank you very much for the fix. Now I don't have to redefine pulseIn()

In the old forum I asked for help to bail out of pulseIn(): http://arduino.cc/forum/index.php/topic,49345.0.html
The suggestion was to redefine the function and add a time out.  That was with IDE 0020

I am reading IDE v 0022 and one of the fixes is:

* Applying the timeout parameter of pulseIn() during measurement of the
  pulse, not just while waiting for it.

Does this fix the "problem" I was having? In other words, there is time out for
1- waiting for previous pulse to end
2- waiting for pulse to start
3- waiting for pulse to stop

Thanks.

I did some measurements on the NEC remote pulses
I used *20+16 for width

These are the results on average of 50-100 measurements:

Theoretical (usec):  560  1690  2250  4500
Measured  (usec):   532  1674  2227  4549
Difference (usec):   -28    -16     -23   +49


So *20+16 seems to work (Arduino 0021 and  Duemilanove 168)


One additional comment: The reason I needed a bailout is because I am measuring HIGH pulses from the IR receiver. The normal off state of the receiver (no IR received) is HIGH, so if you get a spurious signal of one pulse the receiver out signal will go low, then high and stay there until the next event. In the meantime, pulseIn will wait for the end of the HIGH pulse forever...

alfonso.nishikawa,

thanks!. With further info from this post: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1289639566
the code works. I needed to recalibrate width to be 20X

For the application I'm using (NEC remote protocol) the granularity is good enough.

I guess I understand why this is not in the standard release; it will increase the granularity of the pulse measurement. I wonder if there is a better way to bail out of the function.

Thanks again.

Edit: Further reading indicate that the multiplier is 19: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1282768194

Thanks!. I suppose I need to recompile the Arduino code (which I don't know how to do). Is there a function I could use in my own code?

I'm stuck in a pulseIn waiting for the pulse to end. The time out parameter waits for the pulse to start. There is no other time out parameter for the pulse to end.
Thanks...

You can use a single Arduino to do all of that. I just finished a (Sony) remote control to control a DAC, including volume and documented it here: www.hifiduino.blogspot.com .

Agree. I guess I am proposing a flag to just disable the automatic pull ups.

It would be nice to have a flag to disable the internal pull up resistors in i2c and implement external pull ups to 3.3V

Isn't that part of the learning process?

designer2k2,

Inspired by your designs, I tweaked my 3-line large font.  Here are some pictures: http://hifiduino.blogspot.com/2009/06/new-fonts.html

Yeah, Sony protocol is the easiest. I've implemented this code and works well. The latest code in this thread is interrupt based so you can do other things besides looping around waiting for the remote.

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1176098434/3#3
I posted the last code and it has some minor errors, but it works.

De acuerdo a este post: http://billgrundmann.wordpress.com/2009/03/02/the-overhead-of-arduino-interrupts/ se tardan 51 ciclos para atender al interrupt. Supongamos que lo que haces en el interrupt se tarda 49 ciclos, entonces lo maximo que puede medir es 16MHz/100 o  160KHz

When I learned programming, we had to use a keypuncher. Well, that was frustrating! :-)