digital inputs lag 0.5-1.0 second before registering change

It appears as though there's some sort of buffer or something on our digital in's...
We noticed that our banner sensors had a 0.5-1.0 second lagtime in registering the change from a 1 to a 0.
Then we took a pwn cable and shorted out the white to the black, and noticed the same phenomenon... in other words, it's something in the programing or the RC hardware.

for testing, we were using...
- default code

- a printf statement in user_routines_fast.c, in the function where it says to put code you wish to be executed every program loop (I don't remember the function name... but it was second to last I believe)

- rc_dig_in01 and rc_dig_in07, same thing happened on both

We'd connect black to white, and watch printf keep spitting out 1's for about .5 to 1 second, then it'd go to zero. Disconnect, watch 0's print out for .5-1.0 secs, then change to 1.

What is going on???

[steven114]

Sometimes this happens because you are writing too much data to the serial port. If you write faster than your terminal emulator can print out on your screen, it will appear to lag behind. I've been thrown by this a few times - the solution is to either print less data or use a better terminal.

[Greg Marra]

Have you considered that the latency could be in the computer you are using to read the printfs? One of our mentors uses a laptop that gets about 12 seconds of latency on its serial port.

What if you make the code to immediately provide feedback to something else (say a servo) as soon as the digital input goes to one? This way you could see if the problem is really in the digital input, or if it is in the way you are reading the digital input.

[KenWittlief]

printf's slow down the code in the RC, and as others have pointed out the serial port is very slow.

Your final version of competition code should have all the printf statements commented out (to get the fastest code loop execution times). Be aware that if you fine-tuned some SW function with printF's in the code, it will run faster when you comment them out, and it may act differently.

[Dave Flowerday]

Check it with Hyperterminal. The terminal window built into the IFI loader definitely has lag in it.

[Greg Ross]

Originally Posted by steven114

Sometimes this happens because you are writing too much data to the serial port. If you write faster than your terminal emulator can print out on your screen, it will appear to lag behind. I've been thrown by this a few times - the solution is to either print less data or use a better terminal.

That would be my guess. Try only printing whenever the value changes.

Thank you all muchly... I'll take the printf out of the equation and use a servo or pwm or something to test the response of the digital in. The info about the printf function is very helpful.