Floating point problems w/PIC16F

[fredmatic]

I wrote a small piece of code for the PIC16F690 to use it as a sweep frequency generator. I have a few lines of code using floating point, which at the end I re-cast the float into an integer for a timer.

[Ttelmah]

You are probably actually triggering a maths overflow, which isn't being handled.
fcount, contains a random value. Possibly zero. 1/fcount, then gives an invalid result.
What is fcount meant to hold?. Initialise it.
Initialise icount.
As a general comment, multiply by 2000000, rather than dividing by 0.0000005, and multply by 0.5, rather than dividing by 2. Division takes significantly more time than multiplication.

Best Wishes

[fredmatic]

I initialized the fcount to 1000, and the problem still exists. I step thru the program with the ICD2 and when I hit the first floating point line, the ICD2's next step is at the " #include <16F690.h> " line in the "main.h" hearder file the CCS compiler initially generated. So I have no idea what could be causing this.

[Ttelmah]

Try running it in something like the MPLAB simulator, rather than the ICD2. I'd suspect you are hitting an ICD problem of some sort, but 'prove it' first.

Best Wishes

[andyfraser]

Hi,

I have seen a similar thing when debugging with ICD2. When you single step over a compiler library function the debugger jumps to the corresponding include file. Try setting the breakpoint to the line after the one you want to stop on then look at the value in fTemp.

Andy

[Wayne_]

This is because you are executing a CCS library function which you don't have the code for so you can't step through it in C.

Switch to assembler mode at this point and you will see what I mean!
When you have stepped through the assembler and it returns back to your main code you can switch back to C.

If you continue to step through while in C mode it will still work and return you to the correct point but it will just look messy.

Or you can just but a break point after the routines and run it!