Cannot access "double" values

[chantilly_team]

We are having problems with using double or float values.
We have installed the new compiler(version 2.40). But still cannot use doubles in it. When we tried to write : double x = 0.75; it gives us compile error. Also we cannot print float or doubles through printf(). We dont know what to do.
Any help is appreciated.

Team 612

[jgannon]

Could you give us the actual error when you try to compile? Also, I don't think that this printf function supports floating-point variables. I have never been able to print floating point variables (without scaling them and casting them as integers), and I seem to remember someone else saying it couldn't be done.

[Mark McLeod]

I can use
double f=9.9;
without any trouble.

This Microchip implementation of printf doesn't support the printing of floats, but you can easily print them on
your own.

#define ACCURACY 1000 //How many decimal places are important to you
 
void PrintFloat(float value)
{
	long i, i2; // Don't need to be longs if you only need a few significant digits
 
	/* Separate the whole number from the fraction and print each of them */
 
	i = (long) value;
	i2 = (long) ((value-i)*ACCURACY); // You can get fancy and round by adding .5
 
	printf(" %d.%03d \r", (int)i, (int)i2); //e.g., "234.078"
}

(Been there, did this a few days ago on http://www.chiefdelphi.com/forums/sh...489#post328489)

[DanDon]

Unless I'm mistaken, u can print floats like this:

float x;
x=5.999;
printf("%f", x);

This has worked for me on my desktop, but i haven't tested it on the robot yet. I'm going to be testing it on monday, I'll post my results then.

Dan
Team 375

[jgannon]

Originally Posted by dhoizner

This has worked for me on my desktop, but i haven't tested it on the robot yet.

Yes, with a normal C compiler, it's no problem. However, %f doesn't work in the C18 compiler. I don't know the reasoning, but the general consensus (and my own experience) indicates that it doesn't.

[Mike Betts]

OK, let's be clear here. "printf" is not a C function. C does not define any I/O. It is written by you.

Now, IFI, Keven Watson and others have been gracious in providing you with a couple of examples as to how to accomplish this. You have the source code for whichever printf you are trying to use. If you feel the (IMHO: insane, stupid and ignorant) need to use a float or double, change printf to suit your own needs.

Mike

Post Script: Sorry for the rant but this stuff is getting really tiresome...

[jgannon]

Originally Posted by Mike Betts

OK, let's be clear here. "printf" is not a C function. C does not define any I/O. It is written by you.

Now, IFI, Keven Watson and others have been gracious in providing you with a couple of examples as to how to accomplish this. You have the source code for whichever printf you are trying to use. If you feel the (IMHO: insane, stupid and ignorant) need to use a float or double, change printf to suit your own needs.

Mike

Post Script: Sorry for the rant but this stuff is getting really tiresome...

With all due respect, take a breath, Mike. The original poster observed a problem, that:

Originally Posted by chantilly_team

we cannot print float or doubles through printf()

Mark McLeod and I confirmed that you can't do this with the I/O libraries provided with the C18 compiler. Mark went so far as to suggest a simple solution for being able to output floating-point numbers. Nobody was complaining. Nobody wanted to argue what abilities are inherent to C, or what actually comes from libraries. Nobody wanted to rehash the "INTEGERS FOREVER WOOO!!!1" discussion. The question has been answered... there's no need to rant. If people asking questions has become tiresome for you, maybe you need a break from CD or something. Making newbies feel dumb is pointless.

[Mike Betts]

Originally Posted by jgannon

With all due respect, take a breath, Mike. The original poster observed a problem, that:

Mark McLeod and I confirmed that you can't do this with the I/O libraries provided with the C18 compiler. Mark went so far as to suggest a simple solution for being able to output floating-point numbers. Nobody was complaining. Nobody wanted to argue what abilities are inherent to C, or what actually comes from libraries. Nobody wanted to rehash the "INTEGERS FOREVER WOOO!!!1" discussion. The question has been answered... there's no need to rant. If people asking questions has become tiresome for you, maybe you need a break from CD or something. Making newbies feel dumb is pointless.

Joey,

You are correct, of course. However, I must inquire: If someone does not read the information presented, should we help at all?

But I must point out that printf is not a "library" function or inherent to C. It is defined (in the default code V2.4) in printf_lib.c (maybe a poor choice of file names) and supports %d, %x, %X, %u, %l and %b formats. All are integer formats (and, IMHO, for a reason, but I'll avoid the "INTEGERS FOREVER WOOO!!!1" rehash).

My issue is that people are not even looking at the code they are given.

I can understand (begrudgilngly) questioning libraries where you have no view of the source code. But to complain about source code that YOU have control over...

I would ask you... How many threads have started with "The printf routine does not ..." or "the default code will not..." or My camera does not..."?

Too many people are looking for "plug and play" code... They need to realize that, in the real world, it just does not exist. In the real world, we have no IFI or Kevin Watson to give us exquisite examples of embedded programming... What we have are spec sheets, manuals and application notes... And with this, we manage to send robots to distant planets and the bottom of the ocean...

I'm sorry... I'm tired and... Maybe you are right.... Maybe I should not be posting in this state... Still, I hope that "the light" is going on in at least one mind out there...

Regards,

Mike

[Mark McLeod]

There is some additional confusion here in that printf in the new 2.4 version of the compiler is now an available library function. It's provided in the mcc18 clib.lib. It's recommended by FIRST that programmers remove the old printf_lib files from their projects to take advantage of the more efficient implementation (fewer calories/less filling of program space).

That said, I have to agree with Mike that it's always a good idea to read the available documentation on any software/compiler/development environment/etc. You are only handicapping yourself by not doing so. There are always implementation oddities/quirks/limitations that programmers must make themselves aware of. How long did you beat your head against the wall trying to figure out why your code wasn't working? In the case of the new C18 printf that's to be found in the manual that came with the compiler describing the C18 libraries.

New programmers have a particular challenge with the somewhat overabundence of software implementations available this year. We have three different default versions for the FRC released by FIRST this year. While that's great for the intermediate programmers and certainly helps to stretch their programming "muscle," it can make it more difficult for a newbie to sort through the documentation/headers/code for each of these versions to decide what to use/combine and what to ignore/disgard. It'll be much easier after all this has had time to settle a little bit and we all get through this somewhat transitional stage in the evolution of FIRST software.

[Mike Betts]

Originally Posted by Mark McLeod

...How long did you beat your head against the wall trying to figure out why your code wasn't working? In the case of the new C18 printf that's to be found in the manual that came with the compiler describing the C18 libraries.

I hardly have a dent... I'm using a slightly modified version of Kevin's original "serial_ports.c" and not the C18 libraries.

For embedded applications, I've written my own printf since I ported Unix V to a 68020 back in '86.

I guess I'm a control freak...

Regards,

[Mike Betts]

Originally Posted by Mark McLeod

...It's recommended by FIRST that programmers remove the old printf_lib files from their projects to take advantage of the more efficient implementation (fewer calories/less filling of program space)...

Mark,

I'd be very interested where you read/heard that...

Mike

[jgannon]

Originally Posted by Mike Betts

However, I must inquire: If someone does not read the information presented, should we help at all?

If you've read through the FIRST Q&A, you've seen that maybe 90% of the questions are answered either in the manual or in another previously-asked question. Nonetheless, somebody at FIRST takes the time to sit down and answer them all, to make sure that everyone understands that which they desire to know. Would it be better if everybody read the whole manual, and looked through all the source code? Of course. But, as long as we're here, oughtn't we help those who don't? We could try to teach them a lesson ("READ THE MANUAL OMG NOOB"), or we can give them a solution. Mark McLeod's post in this thread is an excellent example; he provided a solution. I won't hesitate to remind people to "search before your post", but at the same time, it doesn't hurt to explain why their compiler can't find adc.h, or why they can't compile code that they're keeping on their desktop.

Originally Posted by Mike Betts

[printf] is defined (in the default code V2.4) in printf_lib.c (maybe a poor choice of file names) and supports %d, %x, %X, %u, %l and %b formats. All are integer formats

This is an excellent piece of information for this thread... though it isn't a solution, it explains why chantilly_team is encountering this problem.

Originally Posted by Mike Betts

My issue is that people are not even looking at the code they are given.

I can understand (begrudgilngly) questioning libraries where you have no view of the source code. But to complain about source code that YOU have control over...

I see no complaints from chantilly_team with regard to IFI's implementation of printf... am I missing something? It looks like just a question to me. "IFI wrote crappy CMU camera code" is a complaint. Don't like it? Rewrite it yourself. "I can't get the IFI-provided camera code to lock onto a tetra. How can I make it work?" is a question. Since these resources are available, let's help people learn how to use them in the ways that they want (a la Mark McLeod's post).

Originally Posted by Mike Betts

Too many people are looking for "plug and play" code... They need to realize that, in the real world, it just does not exist. In the real world, we have no IFI or Kevin Watson to give us exquisite examples of embedded programming... What we have are spec sheets, manuals and application notes... And with this, we manage to send robots to distant planets and the bottom of the ocean...

Amen. Nonetheless, guiding people in the right direction can't hurt. I'm sure that someone at NASA has pointed out something that Dave Lavery overlooked in a spec sheet or manual.

Originally Posted by Mike Betts

I'm sorry... I'm tired and... Maybe you are right.... Maybe I should not be posting in this state...

Build season wears us all down, but when we get to Atlanta, everything regenerates, because we've been inspired.

Just the observations of a FIRSTer who has asked no shortage of stupid questions, but still ended up having my life changed by this program.

[Mark McLeod]

Originally Posted by Mike Betts

Mark,

I'd be very interested where you read/heard that...

Mike

In the morning I promise I'll look up the reference and pass it along. It's past my bedtime. (need a sleepy emoticon)

[chantilly_team]

ok, We got the problem solved. We can now use double and float values. But they have to be declared on the top, that is, they should be global varibles and they dont work in the sub-routines. (thats what we discovered). We can now use tan functions and inverse tan functions. But the process is very very time-consuming and slow. We fear that the processor might just get crashed in real time. So instead we are converting everything into a pre-made table and use the table to get the tan and inverse tan values. That is a lot faster and we would recommend using it that way. Thanks for your help though.

Team 612.

[jgannon]

Originally Posted by chantilly_team

We can now use tan functions and inverse tan functions. But the process is very very time-consuming and slow. We fear that the processor might just get crashed in real time.

This is what Mike was hinting at, of why it's not a particularly good idea to use floating-point variables on embedded systems.