NetBurner Community Forum

Just want to answer rnixon's question, sorry for the confusion.

What I mean is that the following statements are the same, and will give me wrong results:
x = (a - b) / (double)(MAXADCCNTS - ((range == 1) ? 819.0 : 0.0));
x = (a - b) / (MAXADCCNTS - ((range == 1) ? 819.0 : 0.0));

and I said casting MAXADCCNTS alone won't fix the problem.
x = (a - b) / ((float)MAXADCCNTS - ((range == 1) ? 819.0 : 0.0));
since 819.0 , 0.0 are double, and the devision is still (float/double).

Only casting the whole denomenator helps.
x = (a - b) / (float)(MAXADCCNTS - ((range == 1) ? 819.0 : 0.0));

Looks like nobody's using rel20_rc_4.
Why i am still using this old version, as I posted in another thread long time ago. Upgrading the compiler causes traps in my firmware.
And I donot have much ram space available in the mod5213.

I used 2.0rc4 for a long time and never noticed this type of anomaly. Are you sure it's a compiler problem and not something in your code? I don't think the compiler has changed from 2.0rc4 to now. Your examples are still incomplete. Did you cut and paste the example I provided into a project and call it?

Hello, Tod.
Thank you for your info.
Currently I cast the denomenator to float, and that fixes the error.
My guess is that the calculation of (float)0.0/(double) expression is the mistaken, since (float)0.0/(float)expression is correct.
I can not use your code directely without lots of mods,since I have limited resources for display.

However I 'd like to try something if you think my Netburner Version might not be the cause.
If you have any suggestions u want to try to rule out the possibility of compiler defects, please let me know.

Will get back to you probably next week.

Not sure why you can't use my code unless you don't have a serial port. That's the only display I did. If you want further help (and for future problems of this nature) you should do the following:

1. Create a new project for your board using the NetBurner device Executable Wizard
2. Select just the EnableAutoUpdate option.
3. In the resulting main.cpp create a function above UserMain with your example code.
4. Call your function from UserMain.
4. Compile and run and verify your problem is repeatable.
5. Cut and paste main.cpp (all of it) into a post here.

This should take you about 5 minutes. The total example in your case should be maybe 50 lines of code.

Then anyone that wants to help can cut and paste your function into the equivalent test project on their system and give you feedback. Even if the person testing uses a different board and different version of the compiler they can give you useful feedback. Seeing your UserMain lets everyone know you haven't done anything there that could affect the function call.

The fact that using a new compiler causes your code to trap is also very suspicious. It seems probable (but not certain) that you have an error that is just begging to be discovered.

Hello Tod,

Hope you are not mad at me. I've been tied up by another project lately, sorry for the late reply.
I have reproduced the error based on your code snippet.

void TestAgain()
{
#define MAXADCCNTS 4095.0
float a = -1.0;
float b = -1.0;
char range = 0;

a = atof("-1.0");
b = atof("-1.0");
float x = (a - b) / (double)(MAXADCCNTS - ((range == 1) ? 819.0 : 0.0));
printf("%f\r\n", a);
printf("%f\r\n", b);
printf("%f\r\n", x);
// std::cout << "Testing define with cast:" << x << " \n";

float test = atof("-0.0");
printf("%f\r\n", test);
// std::cout << "Testing atof:" << test << "\n";
}
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Waiting 5sec(s) to start 'A' to abort
Application started
-1.000000
-1.000000
-166194084099362416019908175423602688.000000
-2.000000

From my observation:
1) The problem was caused atof, if I delete
a = atoff("-1.0");
b = atoff("-1.0");
then I will not get the huge negative number.
2) The following atof() call give me wrong result
float test = atof("-0.0");
float test = atoff("-0.0");
while double test = atof("-0.0") is correct.

3) I used printf 'cause #inlclude<iostream> won't compile, even though I have added the path
C:\Nburn\gcc-m68k\include\c++\3.4.2
maybe you can help me out.

I am glad I 've recreated the error.

Thanks.

I'm not mad at you, my wife thinks I'm mad but that may be because I mutter about C++ in my sleep.

I don't think cout vs printf would matter but your statement about the include path you used was very interesting. I take back what I said about the compiler not changing. Your path indicates you're on gcc 3.4.2 ( which coincidentally is having its 8th birthday today) and the current version of the NNDK uses 4.2.1 (a relative youngster at 5 years old 7/2007).

You may have found a compiler bug that has been corrected. I'm not sure why <iostream> won't work for you though. Just for future reference I'm attaching a screenshot showing the four directory paths I always include for C++. This both allows things to compile and allows the indexing system to have enough information for content assist to work with the standard library.

**** Build of configuration Release for project bugTest ****

mingw32-make -k all
Building file: ../main.cpp
Invoking: GNU C++ Compiler
m68k-elf-g++ -m5206e -O2 -gdwarf-2 -fno-rtti -fno-exceptions -I"C:\Nburn\include_nn" -I"C:\Nburn\MOD5213\include" -I"C:\Nburn\gcc-m68k\include\c++\3.4.2" -I"C:\Nburn\gcc-m68k\m68k-elf\include" -I"C:\Nburn\gcc-m68k\lib\gcc\m68k-elf\3.4.2\include" -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -DMOD5213 "../main.cpp" -o"main.o"
Finished building: ../main.cpp

Invoking: GNU C/C++ Linker
m68k-elf-g++ -m5206e -Wl -Wl,-n -T"C:\Nburn\MOD5213\lib\MOD5213.ld" -Wl,-R"C:\Nburn\MOD5213\lib\sys.ld" -Wl,-Map="bugTest.map" ./main.o -Wl,--start-group,"C:\Nburn\lib\MOD5213.a" "C:\Nburn\lib\NetBurner_nn.a" -Wl,--end-group -o"bugTest.elf"
c:/Nburn/gcc-m68k/bin/../lib/gcc/m68k-elf/3.4.2/../../../../m68k-elf/bin/ld.exe: region rom is full (bugTest.elf section .text)
c:/Nburn/gcc-m68k/bin/../lib/gcc/m68k-elf/3.4.2/../../../../m68k-elf/bin/ld.exe: region rom is full (bugTest.elf section .text)
collect2: ld returned 1 exit status
mingw32-make: *** [bugTest.elf] Error 1
mingw32-make: Target `all' not remade because of errors.
Build complete for project bugTest

Sorry, I just looked up the specs on the module you're using; it doesn't have enough Flash to use the C++ stream library. That's why you're running out of ROM space. I wrote up some benchmark results in my post, The Cost of Type Safe Code. I ran with various compiler settings if you want to see more about what's going on.