GUI

If you want to design your own GUI or embed the generator in another system, the code in Listing 1 is all you need. The Python files that create a convenient GUI to control the instrument can be downloaded from the Linux Magazine FTP site [13], along with the code for iio.py. The GUI routines include:

• dds_gui.py
• vlab.py
• flab.py
• dial.py

The dds_gui.py program for the function generator uses the Tkinter GUI toolkit [14]. The code mostly sets up the GUI elements and wires the button events to the appropriate routines. At the end, the program sets the instrument into its default state, enters the main loop, and waits for user input.

The vlab.py and flab.py routines extend the capabilities of a Tkinter Label and add editing facilities (for voltage and frequency, respectively), enabling a cursor to be moved from digit to digit and for that digit to be incremented and decremented.

The dial.py routine implements a custom Tkinter widget (control) that simulates the dial or spin knob often found on these types of instrument. Buttons allow you to jog values up and down by a single digit and to move up and down by a decade. These controls work closely with the frequency and voltage labels.

The Linux Setup

Although the following procedure should work on any modern Linux distro, I used Arch Linux on my Rasp Pi. A fully bootable SD card image of the instrument's OS and all the source code are available on my GitHub page [15].

To access the DAC and DDS chips, some device drivers must be loaded. In turn, those drivers must be given information on the location and capabilities of the chips. These types of devices do not support auto-discovery, so in the world of embedded ARM processors (and increasingly elsewhere), a device tree is used to locate and load suitable drivers for devices. Listing 2 shows the device trees for the DAC and DDS chips.

# dac_tree.txt
$ ls -1 /sys/bus/iio/devices/iio\:device0/out*
/sys/bus/iio/devices/iio:device0/out_voltage0_raw
/sys/bus/iio/devices/iio:device0/out_voltage0_scale
 **
# dds_tree.txt
$ ls -1 /sys/bus/iio/devices/iio\:device1/out*
/sys/bus/iio/devices/iio:device1/out_altvoltage0_frequency0
/sys/bus/iio/devices/iio:device1/out_altvoltage0_frequency1
/sys/bus/iio/devices/iio:device1/out_altvoltage0_frequency_scale
/sys/bus/iio/devices/iio:device1/out_altvoltage0_frequencysymbol
/sys/bus/iio/devices/iio:device1/out_altvoltage0_out0_wavetype
/sys/bus/iio/devices/iio:device1/out_altvoltage0_out0_wavetype_available
/sys/bus/iio/devices/iio:device1/out_altvoltage0_out_enable
/sys/bus/iio/devices/iio:device1/out_altvoltage0_phase0
/sys/bus/iio/devices/iio:device1/out_altvoltage0_phase1
/sys/bus/iio/devices/iio:device1/out_altvoltage0_phase_scale
/sys/bus/iio/devices/iio:device1/out_altvoltage0_phasesymbol

If you have used any Rasp Pi HATS before, you might be familiar with adding overlays in the config.txt file. In the present case, one overlay file, dds_hat.dtbo, is copied to the /boot/overlays directory and referenced from /boot/config.txt:

lcd_rotate=2
gpu_mem=64
initramfs initramfs-linux.img followkernel
dtoverlay=dds_hat

The .dtbo overlay is a binary file produced by compiling a .dts file with the device tree compiler [16], available with most ARM-based distros. As stated earlier, the overlay tells the kernel where to find a specific device (e.g., its SPI address), something about its configuration (e.g., clock frequency), and which device driver to load. This information is passed to the device driver so that it can communicate with the device and set it up appropriately. The overlay provides a description to the kernel of the device and the environment in which it exists.

Once the drivers are loaded during boot-up, the appropriate entries should appear in the /sys file tree, and you will see that the entries correspond to those used by the Python routines in Listing 1.

To avoid having to run the dds_hat program as root, you can add some udev rules so that non-sudo users can access the IIO subsystem:

$ cat /etc/udev/rules.d/99-iio.rules
ACTION=="add", PROGRAM="/bin/sh -c 'chown -R alarm:alarm /sys/bus/iio/devices/iio\:device0/*'"
ACTION=="add", PROGRAM="/bin/sh -c 'chown -R alarm:alarm /sys/bus/iio/devices/iio\:device1/*'"

These rules are quite broad, and this approach is not recommended on a multiuser server; however, for an embedded device like this, it seems acceptable.

You should now be able to run the Python program and enjoy your function generator!

Conclusion

Although scope for improvement always exists, both for hardware and software, I hope the instrument described here and the details of how it was built, its function, and how it works internally prove to be of interest. This DDS HAT board could be put to a number of other uses with different software. For example, you could produce complex amplitude, phase, and frequency modulation schemes. Some examples can be found in the datasheets and associated application notes for the DDS chip that would allow integration into a communications system.