The Arduino platform doesn't enjoy working with floating point ("FP") numbers. It's slower than you'd think it aught to be. The core of the issue is that the microprocessors the Arduino platform is designed to run on do not have an integrated floating point unit (FPU) or other similarly dedicated hardware. They only have the built-in hardware to perform integer math, an arithmetic logic unit (ALU). Arduinos perform floating point math in software. Although it depends on which compiler (and compiler options) you are using and which libraries are being linked, it's probably IEEE 754 single-precision binary floating-point format ("binary32")^[Note]. While the extra code space is concerning, those concerns are present when linking any extra libraries. Uniquely pertaining to the use of FP operations is their slow speed relative to the analogous integer operations. Using an ALU for FPU operations means converting the FP numbers' signs, significands, and exponents into integers, performing operations on each integer, then converting back to FP. The same operation may be performed in a single cycle using integers and the ALU. The lesson here is to avoid floating point numbers on Arduinos.

I need to do some geometry at run time to figure out how my gizmo is positioned, specifically the sin(x) and cos(x) functions. The math.h header normally implements these by linking a floating point library. With the above in mind, I set out to implement sin(x) and cos(x) using a lookup table of integer values.

Sine and cosine functions normally output values ranging from -1 to 1. Integer precision can be increased by scaling these values up. Any script that makes use of these functions will likely perform other math operations on them, such as multiplying and dividing, which puts practical limits on the scaling factor. For example, a result value of type int from multiplying the output scaled by a factor of 1000 would risk overflow if multiplied by a number greater than 32. Reducing the scaling factor reduces precision. I suggest setting the scaling factor to achieve the minimum required precision, then choosing the variable storage types. I chose a scale factor of 1000 and was sure to employ type long variables, which allows the use of multiplicands up to 2,147,483, giving me 1 mm precision with measurements on the order of 1000 mm.

My uses required only integer angle values, and the 360-degree sinusoid and cosinusoid waveforms can be mapped to a single quadrant of the sine wave, which means my lookup table only needed 91 values. Excel was used to calculate the scaled and nearest-rounded values of the first quadrant of sin(x), and to format it as a C++ array. It was stored in flash using the PROGMEM macro.

The library is programmed as a namespace instead of a class with static members as an experiment to gain experience using namespaces. It could easily be converted to the latter. Code is linked below (git develop branch, for now) with the bulk of it transcribed.

IntegerGeometry.h

/*
 * IntegerGeometry.h
 *
 * Created on: Oct 31, 2017
 * Author: Tyler Lucas
 */

#ifndef IntegerGeometry_h
#define IntegerGeomtry_h

#include "inttypes.h"
#include "avr/pgmspace.h"

namespace IntegerGeometry
{
    int sin1000(int angle); // returns 1000*sin(angle)
    int cos1000(int angle); // returns 1000*cos(angle)

    // 1000 times sin(angle) from 0 to 90
     const static uint16_t sin1000table[/*91*/] PROGMEM =
     {
         0,
         17,
         35,
         52,
         ...
         999,
         999,
         1000,
         1000
     };
}

#endif // IntegerGeometry_h

IntegerGeometry.cpp

/*
 * IntegerGeometry.cpp
 *
 * Created on: Oct 31, 2017
 * Author: Tyler Lucas
 *
 * SOHCAHTOA
 */

#include "IntegerGeometry.h"
#include <Arduino.h>

namespace IntegerGeometry
{
    int sin1000(int angle)
    {
        // map angle to 1st quadrant
        int reducedAngle = ((angle % 360) + 360) % 360;
        if (reducedAngle >= 270) // quad IV : sin(x) = -sin(-x)
            return -sin1000(-reducedAngle);
        if (reducedAngle >= 180) // quad III : sin(x) = -sin(pi+x)
            return -sin1000(180 + reducedAngle);
        if (reducedAngle > 90) // quad II : sin(x) = -sin(pi-x)
            return sin1000(180 - reducedAngle);

        return pgm_read_word(&IntegerGeometry::sin1000table[reducedAngle]);
    }

    int cos1000(int angle)
    {
        return sin1000(angle + 90);
    }

}

Here's an example of its use in RobotArmMember.cpp (likely soon to be moved to PositionVector.cpp):

int BoomPositionVector::getRadius(int angle)
{
    long radiusL = this->length;
    radiusL *= IntegerGeometry::cos1000(angle);
    radiusL /= 1000L;
    return (int)radiusL;
}

Note that the multiplication takes place before scaling the result down (division). (Can you figure out why this may be important?)

After preliminary testing (output verification with Excel) and a few weeks of use, it seems to work well. The use of a namespace instead of a class with static members appears to be without complications, though this example does little to push the boundaries of either use case.

Note: If using avr-gcc with floating point numbers, especially with the AVR8 family, you must link libm.a. It is written especially for AVR microcontrollers. The Arduino IDE may do this automatically.