[SOLVED] mikroc math lib dont work

[bestrider14]

Hi

i try to do some trigo in my code but all in the math lib crash my pic, its compile whit no error but its keeping my pic to reboot in loop. i try cos,tan,atan all the same result. but if i try in mikroc for 16f/18f pic it work well if i sim on proteus. but for dspic it crash in proteus and in hardward.

thanks

 

[hanif]

why don't you use look up tables for trigonometric calculation check following links
https://forum.allaboutcircuits.com/threads/evaluating-trigonometric-functions-in-programming-pic-c.17618/

https://stackoverflow.com/questions/1571502/trigonometric-functions-on-embedded-system

 

[bestrider14]

yes that an idea but i need some precision. its for calcule the pitch and the yaw from my drone. for the moment i code myself some math fonction but i lost a little bit in precision

 

[hanif]

did you test any simple code without trig func on your dspic after you got this problem. i find this link it relate to repeated crash

https://www.mikroe.com/forum/viewtopic.php?f=101&t=57598

 

[bestrider14]

yes i run my code live on my dspic but whit my fonction that a write myself but i would like too use the original it seem more precise

 

[Aussie Susan]

How much accuracy do you really need and can afford to compute?
Generally speaking the algorithms for trig functions can take mSec to calculate which can limit how often you are able to make your calculations (considering that you will need to use your processor for other things as well).
Practically speaking you will not get angle measurements better than a couple of degrees and being a few degrees out will not make any real difference.
I gather you are using one of the dsPIC33 families of device in which case you will have a reasonable amount of ROM space to place a lookup table and in my opinion, this is certainly the way to go.
Susan

 

[bestrider14]

i have a ds33fj128ms802 so i think i have some rom to place a table. if a can have +/- 1deg of precision it will be fine. its for balance my drone. i have programe all the thing (remote,engine,...) its the last thing i need is the balancement

thank for your help by the way

ps: sorry if i made mistake in my sentence i try to do my best in englis

 

[Aussie Susan]

With that device you can drive it up to 40MIPS but as it is in a drone, I expect that you will also be concerned about the current the MCU will require: more MIPS = more current = faster draining of the battery = less time before it falls from the sky!
At 1 degree accuracy you will need 90 entries each of (say) 4 bytes = not much ROM space, and you have 128KB to play with.
However, I really think you need to consider the accuracy that you actually need.
Draw a line on a piece of paper. Now, starting at one end of that line, draw another at a 1 degree angle to it and see how far you have to draw the lines before you can see a gap between them. Try the same thing with a 2 degree angle and a 3 degree angle.
Also think of the control mechanism you have for your drone - how accurately can you control that?
Without any specific knowledge of your problem except for many decades of an engineering background, if you can get better than 3 (or even 5) degrees then you are doing well. Control systems need speed of response more than they need accuracy - within reason.
There is an old joke used by aeroplane navigators to their pilots that "you are 1 degree off course".
Susan

 

[bestrider14]

the look up table could be one of the solution but i need to use fonction like pow(), and sqrt() where they are in the same lib so he crash my pic to :/

- - - Updated - - -

ok guys i need your help here I "resolve" my bug but i dont know why it work.

void ini()
{
 Unlock_IOLOCK();
  RPOR7 =   0b0000001100000000; //OUTPUT TX UART 1 PIN RB15
  RPINR18 = 0b0000000000001110; //INPUT RX UART 1 PIN RB14
  lock_IOLOCK();

//UART1
  TRISB.B15 = 0; //OUTPUT RX UART 1
  TRISB.B14 = 1; //INPUT TX UART 1

UART1_Init(300);

}

void Main()
{

  double doub;
  char txt[23];

  init();
  //MPU6050_Init();
  //Calibrate_Gyros();
  //Zero_Sensors();
  UART1_Write_Text("hi");

  doub = sin(2);
  UART1_Write_text("");   //resovle my probleme but WHY ?????? What the hell
  //UART1_Write(0x00); // NO

  FloatToStr(doub, txt);
  UART1_Write_Text(txt);
  UART1_Write_Text("bey");

}

if i put a UART1_Write_Text(""); my pic run well(at leat for this test i dont have try on my main projet) but a UART_Write(0x00); wont work my dspic will crash at the line of sin(2); and reboot. but if i add the UART just next it work. i need light on this i would like to understand and if i can have a better solution much "clean" thanks you

 

[doraemon]

Hello!

I think Susan is right, you don't need accuracy to stabilize a drone. There will be so much disturbance
(air movements) around the drone that a few degrees will be more than enough.
Beside this: I don't have knowledge about PIC, but anyway most of the MCUs I know have an ADC
accuracy of 12 bits. Similarily, low cost accelerometers and gyros are in the same ranges, which
means that having a higher accuracy is simply useless.

If you want to build a full 12-bit sine table (of course, only a quarter of it is fine),
then you need 1024 x 2 = 2kbytes. And if you don't want to bother with symmetry, you can write
the full table which will cost you 8k of flash.
Similarily, you can build a sqrt table which will be faster than anything else.

Susan: "more MIPS = more current = faster draining of the battery = less time before it falls from the sky!"

I don't think it's an issue here. I don't know the consumption of the PIC, but the CPUs I am using consume
less than 10 mA at full power. And the drone's power is about 1000 times higher. This means
that even if you can cut most of your CPU power, you can save at most 1 second out of a 16 minutes flight.

Dora.

 

[bestrider14]

So if i follow you right. that is the equation a need to resolve

ACCEL_YANGLE = 57.295*atan((float)-ACCEL_XOUT/ sqrt(pow((float)ACCEL_ZOUT,2)+pow((float)ACCEL_YOUT,2)));

so i made a look up table for atan and sqrt and for pow function it easy to create a new function by myself.

 

[Aussie Susan]

Bestrider14 - I don't know the function you are calling (I assume it is a library function of some sort) but if it is expecting a pointer to a string then passing it a null pointer, the function will still assume that it is a valid pointer value and try to dereference it and therefore use whatever value at RAM location 0x00. It will then increment its copy of the pointer and continue until the value pointed to is a null (the typical value that indicates the end of a string).
However, the "" null string means the function will passed a valid pointer value that happens to have a single (null) value and so it will return straight away.
Of course, it all depends what you are trying to do here: passing a function that looks like it is intended to write the characters of a string to a UART and then passing it a null string is the same as doing nothing at all!
Looking at your equation, do you really need the 'pow()' function at all? The exponent you are using in both cases is 2 which is same as multiplying the value by itself. Also there are tricks you can pull with the 'sqrt' as you are using it in this case - look up "fast inverse square root" on Google.

Dora - I'll admit to not really knowing much about drones but unless they have separate power supplies for the motors and the control electronics then that seems reasonable. My experience is mainly on low power portable systems where people can be very concerned about the odd extra mA (or uA!!!)
However, my comments about accuracy also apply by extension to a 12-bit ADC. 12-bits represents 4096 steps or 0.025% accuracy at the LSB. Again, you will be doing well to get 8-bit accuracy unless you go to some lengths to get rid on every noise source etc. when you might get 10 bits at best.
Susan

 

[bestrider14]

Thank for the reply. I think i will go for the look up table cause it seem to crash in my main project. The function dont need a pointer so i dont know why it crash. Cause on proteuse it run super well but on hardware not so i try to see what it can cause the crash on hardware cause i do multiple fonction like spi/i2c/uart/... all work well but all in the math lib (sin,cos,tan,atan,...) crash on hardware but not in simulation. So what it can cause that on my hardware. But thanks you for the help

 

[Aussie Susan]

The function dont need a pointer so i dont know why it crash.

If you are referring to the "UART1_write_text" function, then it most certainly does involve a pointer. I suggest that you read up on how (by convention) C compilers interpret strings as arrays of characters with a null terminating character, and also on the equivalence of array addressed and pointers.

So what it can cause that on my hardware.

Simulators do not always simulate the hardware correctly. The ONLY true guide to what is correct is how the hardware behaves.
By the way, you have mentioned several times that you get a "crash on hardware". What exactly do you mean? Does it freeze, or reset or what? Also how to do you know it is doing this - are you using a debugger on the hardware and if so, what behaviour are you seeing?
If you are getting 'crashes' in multiple places form apparently different causes, then it would seem to me that there is something else that is fundamentally wrong, but there are multiple areas to look at (e.g. power supplies, correct connection of all power and control pins etc.)
Susan

 

[bestrider14]

I made this code for test the function.

void Main()
{
  AD1PCFGL = 0xFFFF;                           // digital not analog
  CMCON = 7;

  TRISA.B0 = 0;
  PORTA.B0 = 1;
  
  cos(2); //just this will crash in hardware
  

  do
  {
    PORTA.B0 = 1;
    delay_ms(100);
    PORTA.B0 = 0;
    delay_ms(100);

  }while(1);

}

my led will never flash. but if i delete the "cos(2);" it work fine, and i do some other test before and i can tell that the pic reboot in loop when it reach the fonction cos(2) or anything else in the math lib

 

[Aussie Susan]

I don't know your environment (I've always used the free Microchip compilers and IDE) but it would seem to me that it could be a corrupted library file.
However, what MCU are you actually using? All you've said is that it is a dsPIC.
However, you said that it works OK for the PIC16/PIC18 families. When you changed families to the dsPIC33, did you change the library as well? (I would imagine that this is the sort of thing the IDE should take care of for you.)
Also I *assume* the compiler is correctly promoting the integer argument ("2") to a double to pass to the "cos" function but it would be worth a try to use a double constant as the argument, just in case.
Otherwise, I'll leave it to others with experience in such things to help you.
Susan

 

[bestrider14]

im using Mikroc pro dspic and yeah the IDE take care of this its 2 different. IDE by the way for a 16f/18f and dspic. My MCU is a dspic33fj128mc802. i have try to redonwload the IDE just to be sure that i dont have a bad library file. i dont thinks thats a bad file cause if i can simulate it should be ok so its why I think i made a mistake in hardware but i cant see what can cause that and just whit this lib.

cos
Prototype double cos(double f);

Description Function returns the cosine of f in radians. The return value is from -1 to 1.

Example doub = cos(PI/3.); // doub = 0.500008

Here Is the prototype of the fonction cos I dont know if it can help. Now I will try to send a double like you say.

 

[andre_luis]

for 16f/18f pic it work well if i sim on proteus. but for dspic it crash in proteus and in hardward.

Did you check if Watchdog is enabled by default ?

 

[bestrider14]

Watchdog is disable in the ide but i can try but is realy a function in the math lib that make the crash if a delete the line my code will work so i dont think this can be the wdt but i will take a guess

 

[andre_luis]

but is realy a function in the math lib that make the crash if a delete the line my code will work

In general user functions containing pointer structures is more likely prone to corrupt the whole program than precompiled functions from compiler. I think that Susan got the exact point at post #14; You are probably inputting the numeric variable inside UART1_Write_Text() function at the wrong way.