Subtraction of literal from float crashes program (UPDATE)

[dreaquil]

Hi,

I'm currently working on a project which is done from the hardware aspect. The microcontroller is there in order to provide a pwm output regulated by a pot and theres a current sense input. The values of both pwm duty cycle and current are displayed on an LCD. Since i'm pressed for time I decided to try use the MikroC built in libraries to speed up development time. Now the pwm is displaying fine on the lcd and updating at a great rate (no lag at all). On the second row I'm trying to display the current and I've tried to display normal text as well and that works fine ... even managed to display the voltage im getting from the ADC pin for current. The problem is that when I try to calculate the current from the voltage (using floats) the program stops functioning (ie pwm doesnt even display on the lcd anymore). I've narrowed this down to a single command where I subtract 2.5 from a float and place it in itself (current_disp). I've even tried subtracting two literal floats and placing them in current_disp and that works fine. I have no idea what I'm doing wrong.

Project details

Current sensing is coming from a hall effect current sensor (ACS712)
I'm using a pic18f45k50 clocked at 5Mhz.

UPDATE: I just checked with an oscilloscope: when i program this extra line of code the micro stops outputting the PWM signal aswell so its as if it stops functioning.
 

// Lcd pinout settings
sbit LCD_RS at RD7_bit;
sbit LCD_EN at RD6_bit;
sbit LCD_D7 at RD5_bit;
sbit LCD_D6 at RD4_bit;
sbit LCD_D5 at RD3_bit;
sbit LCD_D4 at RD2_bit;

// Pin direction
sbit LCD_RS_Direction at TRISD7_bit;
sbit LCD_EN_Direction at TRISD6_bit;
sbit LCD_D7_Direction at TRISD5_bit;
sbit LCD_D6_Direction at TRISD4_bit;
sbit LCD_D5_Direction at TRISD3_bit;
sbit LCD_D4_Direction at TRISD2_bit;

void main() {
     ANSELD= 0;
     TRISB= 1;
     ANSELC=0;
     TRISC= 0;
     PORTC=0;
     
     PWM1_Init(2500);
     
     ADC_Init();
     Lcd_Init();
     Lcd_Cmd(_LCD_CURSOR_OFF);
     Lcd_Out(1,1,"PWM:");
     Lcd_Out(2,1,"I:");


     while(1){

     volatile int duty_val=0;
     volatile float duty_disp=0.0;
     volatile int current_val=0;
     volatile float current_disp=0.0;
     volatile float current_disp2;
     volatile char output1[15];
     volatile char output2[15];
     duty_val=ADC_Get_Sample(12);
     current_val= ADC_Get_Sample(10);
     current_disp= (current_val/1024.0)*5;
     duty_disp=(duty_val/1024.0)*100;
     FloatToStr(duty_disp, output1);
     PWM1_Start();
     PWM1_Set_Duty(duty_val/4);
     //Lcd_Cmd(_LCD_CLEAR);
     Lcd_Out(1,5,output1);
     Lcd_Out_Cp("%");
     Lcd_Out_Cp(" ");
     Lcd_Out_Cp(" ");
     Lcd_Out_Cp(" ");
     /*******************************This is the line**************************/
     current_disp= current_disp-2.5;
     /********************************Ends here*****************************/
     current_disp= current_disp*2;
     FloatToStr(current_disp, output2);
     Lcd_Out(2,3,output2);
     };
}

[0xdeadbeef]

Probably an unhandled floating point exception. Most probably because one of the operands is not a "normal" floating point number.
As one operand is fixed (even though it's a double constant), it's most probably the other operand (current_disp).
Then again, while the is a division before which could create a denormal, the last operation is a multiplication by 5:

current_disp= (current_val/1024.0)*5;

Again, both immediates are not float, so I'm not 100% certain if we can assume that a float is multiplied by a float.
If so, it's kinda hard to understand why multiplying a normal float with a 5 should create a float exception.
A precision exception maybe? Do you know if float exceptions are enabled and which exactly?
If they are enabled: did you try to implement an exception handler and check the exception information?

BTW: The use of immediates which are all not really floats is not good practice, but should work I guess.
E.g. you're using 1024.0, but also "5" or "2". It should be like "2014.0f", "5.0f" and "2.0f".

Anyway, why the heck do you need floating point for this kind of calculation at all?

[dreaquil]

Thanks for your reply. From what I've found online about this compiler is that it doesnt implement exception handling. I changed all the immediates to floats like you recommended but to no avail. I just figured that since I'm not really pressed for processing that the use of floating points would be fine. Can you recommend a way I can avoid this altogether please?

[0xdeadbeef]

Use fixed point arithmetics by using a factor of e.g 1024 to add some decimal places.
Since you seem to have a 10bit ADC (0..23), reading the AD value could be interpreted as fixed precision value of 0..0.999.
You just have to care for the numerical ranges. Since this seems to be an 8bit controller and "int" depends on compiler implementation,
you need to use explicit types as uint16_t (or whatever the compiler provides) or so to make sure that you are really using a 16bit type.

BTW: I'm not sure if you understood the "volatile" qualifier. In your code, it seems to be completely superfluous.

[dannyf]

I would find out if floattostr can handle negative number and if so if the resulting output is too big for your string.

[dreaquil]

ah that's right .. ill try adding the decimal places to see if avoid the floating point is the problem. At some point I thought the problem might be being caused by the code optimizer so I made the variables volatile just in case so that they won't be optimized out (not sure if that's the right way to go about it). I'll also check the floattostr function but it seems that this compiler doesnt provide too many technical details about their functions. Thanks for your reply guys .. really helpful

[dreaquil]

!Crashing no longer happening... just need to adjust my equation as I think I have messed something up somewhere.

[dannyf]

If a compiler does not tell you how its functions are to be used, and their limitations, that's not a compiler worth using.

[dreaquil]

Yeah, I've been having non stop problems.. I think im going to scrap the compiler altogether... its crashing the lcd again using non flaoting point..