floats, libs and includes

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a project that makes extensive use of floating point values, and it works, albeit SLOWLY, with no libraries linked in and headers as follows:

#include 
#include 
#include 
#include 
#include 
#include 

I researched a bit and found lots of references to including libm.a. However, I'm not sure what to include it instead of. In the current project, if I simply add it to the linked libraries list, it compiles and loads properly, but all the floating point stuff apparently just stops working.

For this test, I had my logic analyzer set to record several pin transitions on the beginning and end of several code blocks. The idea was to test the speed of the floating point operations (using the include files above) and then to link in libm.a and repeat the test. Nothing else was changed, yet the second test didn't trigger at all, meaning that my floating point routines weren't getting executed at all.

Can anyone suggest where I might learn why this is happening?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
However, I'm not sure what to include it instead of.

Nothing. If you don't link to libm.a, it uses generic calls.
Quote:
but all the floating point stuff apparently just stops working.

Linking libm.a shouldn't do this, it should just be faster. Perhaps if you showed us your code.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve,
The code is more than 500 lines long, so I shall show one portion that apparently no longer executes with libm.a linked:

PORT_LED0 |= (1<<LED0);
			// reset SPI byte counter for next time
			bytesReceived = 0;
			// copy curr -> prev in leg structure
			leg_prev = leg_curr;
			// reset IK error counter
			countIKErrors = 0;
			// apply deltas to curr leg structure, tally error
			XYZChange(xmitUnion.deltas.dx,
				xmitUnion.deltas.dy,
				xmitUnion.deltas.dz,
				leg_curr_ptr);
			countIKErrors += leg_curr_ptr->IKError;
			// apply rotation, tally error
			RotateCoxa(xmitUnion.deltas.dtheta, leg_curr_ptr);
			countIKErrors += leg_curr_ptr->IKError;
PORT_LED0 &= ~(1<<LED0);

This code (for a hexapod robot) performs the complicated math in XYZChange() and RotateCoxa() using a struct contained in the xmitUnion union.

The code for XYZChange():

/////////////////////////////////////////////////////////////////////
void XYZChange(	float xDelta, float yDelta,
				float zDelta, leg_t *legptr)
{
	IKResult ikR;
	float origX = legptr->xTarsus - xCoxa;
	float origY = legptr->yTarsus - yCoxa;
	float origZ = legptr->zTarsus - zCoxa;
	float newX = origX + xDelta;
	float newY = origY + yDelta;
	float newZ = origZ + zDelta;
	float R = sqrt((square(newX))+(square(newY)));
	ikR = IKCalculate(R, newZ);
	if (ikR.result == LEG_ERROR_NONE)
	{
		legptr->femurAngle = -ikR.femurAngle;
		legptr->tibiaAngle = ikR.tibiaAngle;
		legptr->coxaAngle = atan2(newY, newX);
		legptr->xTarsus += xDelta;
		legptr->yTarsus += yDelta;
		legptr->zTarsus += zDelta;
	}
	legptr->IKError = ikR.result;
}
/////////////////////////////////////////////////////////////////////

Like you stated, I expected to just have a bit better performance when I used libm.a, not for this code to stop executing altogether. The pin defined as LED0 is the one that I am timing with my scope.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the transcendentals in libm.a work. The generic codes in libgcc.a that are used when it's not specified are written for 32 bit and simply do not work on an AVR so if your code apparently "worked" without libm.a it must actually have been relying on buggy results from the non-libm.a code, suggest you now debug the algorithm again now that an accurate math lib is being used.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A fine idea. You just made me think, "it was doing something, but just because the LED pins were working right doesn't mean the internal results were correct."

So I'll take your advice, leave it as-is with math.h, float.h included and libm.a linked in, and then start from the beginning...

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know if you need (or want) float.h. It is simply a bunch of redefinitions. It is possible that it is not compatible with libm.a.

Regards,
Steve A.

The Board helps those that help themselves.