Clifton Laboratories 7236 Clifton Road  Clifton VA 20124 tel: (703) 830 0368 fax: (703) 830 0711

E-mail: Jack.Smith@cliftonlaboratories.com

DDS is an acronym standing for "direct digital synthesis." It's sometimes called a "numerically controller oscillator," but DDS seems to be the more popular term.

I devoted most of a chapter in my book to using a 16F877 PIC to build an audio DDS generator, and I don't propose to duplicate that effort here. In brief, a DDS generates its output by computing the value of the desired sine wave (or other waveform, as DDS is not limited to sinusoidal waveforms) at specific time intervals and then sending the value to a digital-to-analog converter, where the numerical data is converted to a corresponding voltage level.

The upper trace in the oscilloscope capture shows a typical DDS output. Note that the desired sine wave is approximated by discrete voltage steps.  The PIC calculates the appropriate voltage level as a byte-range number (0...255) and sends it to the DAC where it is converted to a voltage. In this case, the output is a 730 Hz sine wave.

To show you that the DDS is not restricted to sine wave outputs, the lower trace in the following oscilloscope capture is a DDS-generated sawtooth or ramp waveform. The upper trace is a synchronization waveform.

.

Let's look at how a DAC works. We'll start with a simple 4-bit R-RL ladder type DAC. The two oscilloscope plots above were taken using this circuit, breadboarded up with five discrete resistors.

Likewise, when DB2 is switched to +5V, Rload has 2.5 mA through it, DB1 controls a 1.25 mA source and DB0 controls a 0.63 mA source.

With the switches set as shown in the diagram, the total current through Rload is 2.5 mA (from DB2, through R2) and 1.25 mA (from DB1, through R3), totaling 3.75 mA, for an output voltage of 176 mV.

What about the shunting effect of R1 and R4, you may be thinking. These clearly drain current away from Rload. And, how can you just sum the currents?

The answer is yes, these are all real effects. However, we've chosen R1...R4 and Rload carefully. A 1K resistor shunting 47 ohms is negligible, at least at the resolution we expect from a crude 4-bit DAC. Likewise, a couple hundred millivolts across Rload won't make our assumption that R1...R4 are current sources that bad. Hence, we can simply sum the currents and be "close enough" for our purposes.

Don't believe me? Dig out your calculator and work through Ohm's law and send me an E-mail with the exact answer. It'll be within 10% of our simplistic analysis.

Oh yes, why is this called an R-2R ladder? Looking at the resistor values and diagram should answer this question for you. (I used real values at 3.9K and 8.2K; in theory these should be 4.0K and 8.0K).

And, why make the ratios 2:1? It has something to do with the binary system doesn't it? Yes, indeed it does. If we look at a 4-bit binary number (usually called a nibble) defined by DB3...DB0, we see that the DC output of our R-2R ladder DAC automatically tracks the binary value of the nibble. The binary value to voltage multiplier is the current generated by the least significant bit (R4, or 0.625 mA) times Rload, or 29.4 mV.

Let's see if this works. The nibble data value represented by these switches is 0110 binary, or in decimal 6. Hence, the output voltage should be 6 * 29.4 mV = 176 mV, exactly what we calculated before.

Nice when it all fits together, isn't it?

OK, time for some code. I'll first list the complete program and then explain what is behind it. The program assumes we have two of the simple 4-bit resistive DAC circuits connected to the PIC's Port B.

The following schematic fragment shows the resistive DAC connection.

Clock = 40 'remember to enable HSPLL in configuration

OSC = HSPLL, //turn 4x PLL ON

LVP = OFF,

PBADEN = OFF, 'for 18F4620 - makes port B digital

XINST=OFF

PhaseAccumA As Word, 'use these as a 4.12 (15 bit total)

PhaseAccumB As Word, 'phase accumulators

Temp As Byte

TRISB = $00 'make output

bStep = 267 'generates 730 Hz with current timing

[Note added 06 October 2006. I fixed an error in the main code body, replacing erroneous references to variables i and j with aStep and bStep respectively.

Clock = 40 'remember to enable HSPLL in configuration

DDS is a demanding application for a PIC, and the faster the clock, the better off you are, particularly when programming in a high level language, such as Swordfish. If you look at Chapter 16 of my book, Programming the PIC Microcontroller with MBasic, you will find a chapter on Digital-to-Analog conversion and several DDS programs written in MBasic, for the 16F877 PICs. In order to wring acceptable performance, I had to code time-sensitive segments in assembler. We'll see later that Swordfish produces such efficient code that we do not need assembler routines to achieve respectable performance from the 18F devices.

Swordfish will supply a set of default configuration fuses, but it's a good idea to establish any necessary configuration settings in your code, rather than depend on defaults.

OSC = HSPLL, //turn 4x PLL ON

• Use a 40 MHz crystal or resonator or external clock; or
• Use a 10 MHz crystal, or resonator or clock source and enable the built-in 4x PLL multiplier

It's much easier to use a 10 MHz resonator and enable the PLL, via the OSC=HSPLL statement.

LVP = OFF,

LVP is a feature added by Microchip that turns out to be more of a hindrance than a benefit. Microchip ships its devices with LVP enabled, so it's necessary to explicitly turn it off the first time it is programmed.

Why would you want your PIC code to reset? The answer is normally you don't want it to reset, so if you wish to use the WDT, your code will periodically disarm the WDT and thus prevent it from resetting the PIC. But, if your code has a problem and enters an endless loop, or gets hung up waiting for an external input, it won't be able to disarm the WDT and hence the WDT will force a reset, thereby extricating your program from an unexpected freeze.

If you do not need this level of supervision, keep the watch-dog timer disabled, as in the example. Otherwise, you will have to add code to periodically disarm the WDT.
 

PBADEN = OFF, 'for 18F4620 - makes port B digital

The default configuration is for the Port B pins RB0...RB4 to be analog inputs on power-on reset. Since we use these pins for digital output, we must over-ride the default configuration and force these pins to be digital. (RB5...RB7 are assigned to digital mode at power up.)
 

One more thing. I've mentioned that Swordfish will automatically set many configuration bits for you. Where do you find out what configuration bits Swordfish sets?

Assuming you have a normal Swordfish installation, look in the directory ..\Swordfish\Includes\ for the file with the same name as the DEVICE you set at the outset of the program, with the extension .BAS. In this case, the file will be 18F4620.BAS. (If you were using an 18F2580, the file would be 18F2580.BAS.)

If you open this file with Swordfish's IDE, or with a text editor such as Notepad, you will find a list of all the possible configuration fuses that you can access via Swordfish. Here's the first few lines of the public configuration fuses for the 18F4620:

Then, towards the bottom of the file you will find the configuration fuse settings Swordfish will use, by default:

By in large, the default values are good choices. In our case, the default oscillator parameter would be wrong, but the rest of the default settings match our manual overrides.

So, then, why did we go on a long detour to look at configuration fuses that do nothing but duplicate existing settings? There are two reasons:

• Default configuration fuses are a relative recent addition to Swordfish, and the earlier versions I used had no Swordfish-defined defaults. Either you manually entered the desired configuration fuse setting or you lived with whatever Microchip established as the power-on configuration.
• Although Swordfish does a very good job at defining default configuration fuses, your program may need something different. Hence, it's a good habit to set the configuration fuses the way you want them to be, and not depend upon the default. And, it's possible that a later release file might change the default settings, without you being aware of it.

You might be tempted to modify the 18F4620.BAS file, for example, to make the default oscillator mode HSPLL. That's not a good idea for several reasons. One is that a Swordfish update might replace your modified 18F4620.BAS file without you being aware of it. Another is that you might wish to provide a copy of your program source code to a friend or colleague for testing or other purpose. If your code depends upon a specially modified 18F4620.BAS file, you must also include it, and that file must be copied into the other system, displacing the standard file. All in all, it not a good idea to modify the files in the INCLUDE directory unless you have an excellent reason.

The syntax is to name the constant [SInTable], dimension the constant [16], define the type of data to be stored in the constant array [byte] and, finally, enter the data, with each value separated by a comma and with the data enclosed in parentheses.

The values in SinTable are the values of the sine function, taken every 22.5 degrees, with an offset of 8 and scaled for a maximum peak-to-peak value of 0...15.

In pseudo-code, the values of SinTable are computed as:

For i = 0 to 15
   SinTable(i) = Integer(8 + 8 * Sin(i*22.5) )
Next i

For clarity, this assumes the Sin function operates with the argument in degrees, not radians as is normally the case. There's also a bit of a discontinuity in that the offset should be 7.5, not 8, but since our byte variable is integer, we use 8. Then we force the positive peak to be 15, not 16 as would be expected from the equation.

Now, since SinTable is a constant, we can't directly compute it as part of the normal program code. We could let Swordfish compute some constants, but for SinTable, we use an electronic calculator or a spreadsheet, such as Excel.

Here's the result in Excel:

Step

Sin(22.5*Step)

Integer(8+ 8*Sin(22.5*Step))

Here's a hint to think about until the next installment. Our 4-bit DAC can convert values from 0...15 into voltages. Perhaps there's some relationship between that fact and converting our sine wave data into a range of numbers between 0 and 15.

More tomorrow, work permitting.

In our sample Swordfish program, the interval between successive sample outputs is 5.6 microseconds. How do we know that? I'll analyze it in detail later, but our code sets an output pin (Port C, bit 0) to logic high and clears it to logic low once every sample interval, so we can measure the interval. (Or, we could look at Swordfish's output assembler code and count the instructions and calculate the interval. It's much easier to throw the oscilloscope onto the waveform and measure it.) Here's the output of this "sentinel" pin:

So, we know that once every 5.6 microseconds, we must calculate and output a DAC value that corresponds to the instantaneous value of our desired sine wave output.

I should add that for a high quality output waveform, the step interval must not vary. This can be a problem with an optimizing compiler such as Swordfish, as it may "short circuit" some mathematical operations depending on the particular values. Hence the time to execute a certain program loop might vary depending on the calculations made within the loop. If there's enough interest, we can look at ways to force the output steps to always be at the same interval.

Let's consider a simple example. The illustration below shows our objective-- a target sinusoidal waveform, at 2.77 Hz. The red vertical lines represent the output step interval, in our simple case, once every 79 milliseconds. The black squares show our desired output voltage at each sample interval, assuming, of course, that our DAC has infinite resolution and can perfectly assume any output voltage between -1 and +1 volts.

I'll leave you to ponder these similarities, and how we generate our desired output frequency until a later installment.

If, in one second, our waveform goes through 997.2 degrees, and if an output sample occurs once every 79 milliseconds, then our waveform must advance by 977.2 degrees/sec x 0.079 sec/sample = 78.8 degrees/sample between every sample point.

Our waveform generator program must then output the following every sample interval: Output(n) = Sin(78.8 degrees * n). The first 13 values of the output can be computed as:

0.5 Hz is 180 degrees per second. Hence, every sample interval the desired waveform advances 180 degrees/sec x 0.079 sec/sample = 14.22 degrees per sample.

Here are the first 10 output values needed to generate our hypothetical 0.5 Hz sinewave with a 0.079 second sample interval:

Usually, we will run the DAC output through a low pass filter (also known as an anti-alias filter, for reasons we may touch upon in a later installment, time and interest permitting). We can simulate a low pass filter with our graph program by connecting the discrete output points with an interpolated waveform, using a cubic spline algorithm. Don't worry if this does not mean much to you -- consider it a way of smoothing the waveform similar to how a draftsman would have done it before the days of CAD. He would have taken out a flexible bit of thin wood or plastic and bent it so that it touched three or more adjacent data points and then drawn a fair curve between the data points using the natural curve of the wood or plastic under tension.

Here is the cubic spline interpolated output.

Oh, you don't believe it's the same stepped waveform run through a mathematical equivalent of a low pass filter? Here is the original stepped response and the spline response.

Why don't you compute it and compare your results with my answer in the next installment.

In one second, a 733 Hz sine outputs 733 /second x 360 degrees = 263880 degrees/second. Therefore in 5.6 microseconds, the output advances by 2.6388 x 10⁵ degrees/second x 5.6 x 10^-6 seconds/sample = 1.4777 degrees/sample.

Compared with the relatively coarse step interval in our examples, we would expect (DAC resolution permitting) a relatively clean output, with the need for exotic low pass filter designs.

To understand how this translates to our limited sine table and 4-bit DAC, let's go back to our Swordfish code:

PhaseAccumA As Word, 'use these as a 4.12 (15 bit total)

PhaseAccumB As Word, 'phase accumulators

Temp As Byte

For simplicity, I'll concentrate on the part of the code generating the 733 Hz signal and temporarily ignore the 2.56 KHz related code.

The word length (two bytes, or 16 bits) variable PhaseAccumA holds the total phase information that we use to index into the constant SinTable. This variable is usually called the "phase accumulator" in DDS terminology. Many high end DDS chips have a 32-bit or more phase accumulator. (The Z90 uses an Analog Devices AD9851 DDS integrated circuit with a 32-bit phase accumulator and a 10-bit DAC. Its clock rate is 180 MHz, corresponding to a 5.5 ns sample interval .) Ours is 16 bits, more than enough to demonstrate the concept.

Let's look in more detail at how we use the phase accumulator variable. We will consider the 16 bits of PhaseAccumA as 4-bit and 12-bit parts, separated by an imaginary "binary point."

The upper four bits (this is usually called a nibble, but Swordfish does not support nibble variables) is our index into the constant array SinTable. The lower 12 bits are the "fractional" parts of the phase accumulator.

If we look at a traditional decimal number, such as 1.234, we can regard the digits to the right of the decimal point as the "fractional" part of the number, and the digits to the left of the decimal point the "integer" part of the number. Our phase accumulator has exactly the same structure, except that being binary, we'll call the separator between the integer and fractional parts the "binary point," instead of the "decimal point."

If we convert PhaseAccumA's structure into decimal, the integer value runs from 0 to 15. The fractional part runs from 0 to 0.999755... in steps of 0.000244... (1/2¹² or 1/4096)