The BigNumber library wraps the `bc`

arbitrary precision calculator into a set of Arduino routines that seem like a reasonable basis for DDS calculations requiring more than the half-dozen digits of a floating point number or the limited range of scaled fixed point numbers tucked into an `long int`

.

Treating programming as an experimental science produces some Arduino source code and its output as a GitHub Gist:

All that happened incrementally, as you might expect, with the intent of seeing how it works, rather than actually doing anything.

Some musings, in no particular order:

The library soaks up quite a hunk of program space:

Sketch uses 13304 bytes (43%) of program storage space. Maximum is 30720 bytes.

I think you could cut that back a little by eliminating unused `bc`

routines, like square root / exponential / modulus.

That test code also blots up quite a bit of RAM:

Global variables use 508 bytes (24%) of dynamic memory, leaving 1540 bytes for local variables. Maximum is 2048 bytes.

All the `BigNumber`

variables live inside the `setup()`

function (or whatever it’s called in Arduino-speak), so they count as local variables. They’re four bytes each, *excluding* the dynamically allocated storage for the actual numbers at roughly a byte per digit. With 10 decimal places for all numbers, plus (maybe) an average of half a dozen integer digits, those ten `BigNumbers`

soak up `200 = 10 × (4 + 16)`

bytes of precious RAM.

You can load a `BigNumber`

from an `int`

(*not* a `long`

) or a string, then export the results to a `long`

or a string. Given that controlling a DDS frequency with a knob involves mostly adding and subtracting a specific step size, strings would probably work fine, using `snprintf()`

to jam the string equivalent of a `long`

into a `BigNumber`

as needed.

You must have about ten decimal places to hold enough significant figures in the `HertzPerCount`

and `CountPerHertz`

values. The library scale factor evidently forces all the numbers to have at least that many digits, with the decimal point stuck in front of them during string output conversions.

The biggest integers happen in the `Oscillator`

and `ThirtyTwoBits`

values, with 9 and 10 digits, respectively.

It looks useful, although I’m uncomfortable with the program space required. I have no way to estimate the program space for a simpleminded DDS controller, other than knowing it’ll be more than I estimate.

While poking around, however, I discovered the Arduino compiler *does* provide (limited) support for `long long int`

variables. Given a 64 bit unit for simple arithmetic operations, a simpler implementation of fixed point numbers may be do-able: 32 bits for the integer and fraction should suffice! More on that shortly.