Problem with printf()

[Roger]

That seems curious, Kevin. We've done printf's without "\r\n" at all, and it still works.

[Kevin Watson]

Originally Posted by Roger

That seems curious, Kevin. We've done printf's without "\r\n" at all, and it still works.

I'm not sure if printf() always needs to see \r\n, but I've experienced this problem in the past with the 2.4 compiler (I'm not sure about 3.1). I just threw up my hands and always use \r\n in my code.

-Kevin

[Chaos in a Can]

I've had some odd problems with printf myself, though I've never had a problem with \r\n.

When I used a printf with about seven %d's, something that should have shown up as a 1 or 0 was printing about 150.
It wasn't until I tried using separate printf's for each value that I found that it had either swapped or skipped some of the values and was printing an input from the joystick where it should have been printing a digital input.

[Mr. Freeman]

I'd like to thank everyone again for their help.

Here's how we solved it:
There was a lot of code not working in addition to the printf(). However, I discovered some printf()s that were actually working, in a different section of the code.
It turns out that we had to have the operator interface plugged in for that code to work. We scratched our heads for awhile about this and came to the conclusion (one of us finally remembered) that without a connection to the OI, the watchdog processor must set all PWMs & Relays to 127 & 0, respectively.

Upon further investigation and testing, we think that with no connection to the OI, the process_data_from_master_up() function never gets called from main.c
However, once a connection with the OI has been established and then lost, the RC keeps printing whatever it should have been printing before the connection to the OI was lost.

The reason we took so long to hook the OI up was that we were under the assumption that we had had this code working and printing before without an OI connection in the past. We now believe that perhaps we did have a connection to the OI at the time we were testing, but simply didn't remember that we hooked it up.

This thread has still yielded some good advice. I was not aware that putting commands before all vars were declared was incorrect, and I now have a couple things to try when my printf()s stop working in the future.

Again, thank you everyone for your help.

[Alan Anderson]

Originally Posted by Chaos in a Can

When I used a printf with about seven %d's, something that should have shown up as a 1 or 0 was printing about 150.
It wasn't until I tried using separate printf's for each value that I found that it had either swapped or skipped some of the values and was printing an input from the joystick where it should have been printing a digital input.

This is a symptom of not matching the format information with the size of the variable to be printed. %d wants an int. If you instead give it a char, it will also grab the next byte of data to go with it, and everything will be misaligned from that point on. It's a good idea to get in the habit of always explicitly casting your %d-printed variables as (int).