Re: Printf has just entirely failed to do anything
 

hmm i kind of got lost somewhere.... but ye .. if u still cant complie ur program with

#include <stdio.h>

just a quick question.. have u added

-nw=2066 in ur Alternate Settings in MPLAB C18?

and if its already fixed then dunn wrry:)

Re: Printf has just entirely failed to do anything
 

No, I don't think I have it fixed yet.

The code compiles. There are no errors or warnings. I haven't modified the settings in MPLAB at all--I didn't know I was supposed to. It looks like the default code has that option set by default, as it is already there.

Thanks for the hints, though.

JBot

Re: Printf has just entirely failed to do anything
 

OK--I just got back to the robot today (wow, Christmas break was like being locked in a small shed with no heat and snow all over the place, then getting back was like walking out of said shed into the sun). I did not try any of the old code/HEXes. I have been trying to get my new code working. It worked when I first put it on the controller, but problems showed up when I was trying to interface to a position sensor (like a pot, but has no mechanical limit; just snaps back around to 0). I was getting a good analog signal in; it ranged from about 16888 to 19000 (I think). At this point, everything was gravy. I decided to write up a quick program to watch the input, keep two static doubles, one min, one max, and check if the value coming in was out of range and adjust the according value, and printf both values every slow loop. I discovered either a compiler glitch or a printf bug, as both of my variables look like they have good data; I am getting good data back in the terminal for min, but not for max. For max, I either get 0 or -32767 (very suspicious, but I don't see where my code is overflowing and writing over one of the bits...). I put the printf on a separate line, instead of having a
. At this point, the printed value was in the 18000's range, which is believable for that sensor, but the value coming in didn't go over 17000. I tried typecasting to double (which had no effect, I didn't expect it to).

Why is printf so buggy? and does Kevin Watson have something that works a little better?

Attached is the zip of my current code sans Kevin Watson's serial_ports.c/h and camera.c/h as he does not want these redistributed. Just plop them in the directory and it should work again.

Thanks for trying to help.
JBot

Re: Printf has just entirely failed to do anything
 

I ahvent used C for a year
but arent u supposed to write
Printf("a is %d",&A);
Seems like you forgot the &..if im wrong tell me why..

Re: Printf has just entirely failed to do anything
 

I have never seen that syntax before. After looking it up, I found this:
from http://www.sysprog.net/cpointer.html:
So no, I would guess that would pass printf the address of the variable instead of what (I think) it wants: the value to print. Then again, with my code breaking as fast as it is, I am beginning to wonder about some very basic assumptions...

Thanks,
JBot

Re: Printf has just entirely failed to do anything
 

Values in the 18000 range seem rather large for data coming back from an analog input. Analog input values should be in the 0-1023 range as they are 10-bit data. Time to unzip your source code i suppose...

Edit starts here---
Printf's formatting identifier '%d' is actually meant for signed integers, NOT doubles (fixed-point printing of a double is %f, which back in the day was 'float', or single-precision floating point vs double-precision floating point. I digress too far in these parenthesis, sorry). Looking at your source, your min, max, and "i" variable are all doubles. You will get rather wacky results using the wrong format identifier for a given variable type. For analog inputs, stick with a regular int to store/manipulate data. PWM values can be put into a character since they are 8 bit values (0 to 255).

No ampersand is needed for printf, unless what you wanted to print was the memory address of the variable. Sometimes thats useful for debugging pointers that don't seem to be in the right place :ahh:

--Eric

Re: Printf has just entirely failed to do anything
 

You should define i, min and max to be type "unsigned int", not "double" and use "%u" instead of "%d" in your printf() calls.

-Kevin

Edit: Whoops, looks like esquared answered your question while I was composing my posting.

Re: Printf has just entirely failed to do anything
 

So which is it, or are both valid? Ahh, I'll just look it up. %u or %f, I'm not quite sure. I'll probably try both.
EDIT: Just reread your post, Kevin. So it's %u for an unsigned int or a char, and %f for doubles? I'll test this either tomorrow or the next meeting.

I was wondering if it wasn't printf mangling what it was supposed to print...

Thanks
JBot

Re: Printf has just entirely failed to do anything
 

%u for unsigned, %f for doubles is correct.

Using signed vs unsigned is somewhat a matter of preference for analog inputs. The advantage of signed is if you have calculations that have multiple steps and may temporarily take your integer value below zero. For example, you have a scaling function that has an offset in it, so that some positive value from the sensor still equates to zero after the calcs are done. Depending on how your code is written, this may not be necessary, but can make your code more readable.

The disadvantage of signed is taking your value and applying it to something like a PWM output, where you're dealing with unsigned values. Even then using an int you want to be sure you're not exceeding 255 when assigning to the PWM output.

--Eric

Re: Printf has just entirely failed to do anything
 

Microchip's implementation of printf() doesn't support %f. Unless you really need it, I'd stay away from floating-point operations because the underlying hardware doesn't support it (i.e., it has to be emulated in software).

-Kevin

Re: Printf has just entirely failed to do anything
 

i.e. do not code a For loop of floating point divisions in an interrupt handler. :]

Re: Printf has just entirely failed to do anything
 

I would like floating point accuracy, and I know there are ways of representing a floating-point number inside an int, but I haven't really sat down and thought it out. I don't know how I want to shorthand this. Any suggestions?

I will probably keep using floating-point until it gets so slow that I get a code error. I know that this is emulated; I've seen other threads on not using floating point variables, but aside from speed, I don't see any reason to change. And I know I'm not taking anywhere near 26ms to complete a loop right now.

I'll have to figure out an alternative to %f, though, and that might be the motivator to switch from floating point.

Thanks for your help.

JBot

Re: Printf has just entirely failed to do anything
 

Fixed point arithmetic is good for this. Look at the white papers here on CD, especially if you're trying to do trig (look up "binary radians" or CORDIC to get some of the more useful stuff).

Re: Printf has just entirely failed to do anything
 

First, think about what you are trying to printf to. The robot has no screen, so printf does not work. If you want to work from the command window from the IFI loader, then you must work with the concurring program.

I think that MP lab doesn't use printf anyway, I think they use something else...