Re: Measuring a Pulse Width
 

The 2004 IR receiver code can be found in receiver.c, which can be found in this file: http://kevin.org/frc/2004/frc_tracker.zip. Also keep in mind that the CCP-based code I mentioned earlier won't work on the FRC-RC because IFI put output buffers on the CCP pins.

-Kevin

Re: Measuring a Pulse Width
 

Well, for those that guessed I was using a -2.5V to +2.5V pulse you were right. After adjusting the offset I was able to get the mini-RC to trigger. (See attached) Thanks for the heads up.

I wrote a quick program to test how many edges per second (interrupts/s) the mini-RC was receiving. I was getting very odd results. At about 1Hz there was 2 interrupts/s, which was good; however, at 1kHz there was 2,200 interrupts/s. After awhile I realized it was the printf statement that was introducing the error. Does anyone know just how much of an impact making a printf causes?

Re: Measuring a Pulse Width
 

When ever we get strange results, I always suspect the printf statements, problem is we never seem to be able to determine how much of an impact the printf statement has on the performance. It seems like you have a perfect setup to experiment with and find out how much an impact printf makes. Perhaps you could use the Dashboard program to help compare the results of using printf statements versus not.

Re: Measuring a Pulse Width
 

I'm no expert but, could your Interrupt handler be counting all interrupts and not just the portb pin transitions. The printf statement will generate interrupts.

Re: Measuring a Pulse Width
 

Hmm...when you say it was "about 2 interrupts/s", are you sure you weren't getting about 2.2 and not noticing the excess? And are you sure it was right on 1kHz? That 10% looks like it could maybe be adjustment error on the signal generator.

I would expect printf to eat time and push the number of interrupts/sec down, not up.

Oh, wait...printf/the serial drivers use interrupts, don't they? If I remember correctly (haven't tested it), interruptible pins can set their interrupt flags without their particular interrupts enabled (so the flag is set but we don't jump out to an interrupt), so when another interrupt comes along the ISR might take action on a disabled pin. Is this right or am I confused? At any rate, perhaps something similar is happening in your case; you could be checking the state of your inputs in the ISR without determining whether an interrupt actually originated from them, and so if printf throws an interrupt, it might conceivably cause overcounting. Of course, aren't printf's interrupts high-level ones handled by the Master processor? Hmm...I'm confusing myself now. Comment?

Allow me to state that I generally have no idea what I'm talking about, so please don't laugh too hard.

Re: Measuring a Pulse Width
 

I ran a quick test this morning and measured how long it took to output a simple printf command. It takes 940 uS to complete this command:
It takes 5.3 mS to output this command:
It takes 3.14 mS to output IFI's printf example.

Re: Measuring a Pulse Width
 

Thank you everyone for all your help. Yesterday I was able to successfully integrate the PING))) sonar sensor and the mini-RC. The problems I was having were solved by using two I/O pins and using interrupt 1. I tried staying clear of interrupt 1 because Kevin Watson's encoder code uses it. Friday I will look into reducing the I/O required to 1 and figure out why I can't use a different interrupt.

My ultimate goal was to release this code and a white paper as an easy to implement system alongside Mr. Watson's code. I'll try as best as I can to avoid I/O's already used by his code. Look for a white paper in a couple weeks.

Re: Measuring a Pulse Width
 

First off let me say congratulations on your success!! I love seeing people stay focused on a goal regardless of the difficulties they encounter along the way.


I have always been an impatient person. Waiting to read your white paper is almost more than I can stand :ahh: Just kidding!!!!
Is it possible that you can give a quick description on how you used two I/O pins on a device that shares one pin as both an In and Out (trigger and signal).

Looking forward to reading you white paper. Please post a note here when it's ready to read.