As discussed in detail on the Electronics page, my design uses a digital signal processor (Motorola DSP 56002) to control the STM. The DSP, in turn, is controlled via a serial RS-232 link to a standard PC. The idea is to handle all time-critical tasks - i.e. the X/Y scanning of the STM tip and the feedback loop for controlling the tip height - on the DSP, and run the user interface on the host PC. Also, a number of image processing programs are available for post-processing or analysis of the scanned images on the host PC.
Currently (that's May 2006), most of the DSP software is complete, although there will certainly be some changes. The only things that's missing is PC software that receives and displays the scanned images. Actually, I don't have any PC software at all, yet – since the DSP receives simple ASCII commands on the serial link, I just use a terminal program to control the STM.
The following notes on what the DSP software does and how it's done are preliminary and quite incomplete. If you are interested in details, you'll probably have to look into the source code.
Please refer to the References for some links to tools and applications for the Motorola DSP 56002.
The main tasks of the DSP software are to
Using the DSP to generate the scans gives a lot of flexibility. My current software provides for selectable scan size, resolution, and center position, as well as rotation of the scan direction and of course variable scanning speed. The scan is just repeated over and over, until the parameters are changed or the scan is stopped; I hope that this will help thermal equilibration. Spectroscopy (variable gap voltage or tunneling current set-point during the scan) or tip-sample interaction are not implemented so far. (That's controlled tip-sample interaction; I have seen plenty of undesired "interactions"...)
The feedback loop itself is currently quite simple: In each ADC sampling step, it compares the logarithm of the measured tunneling current to the logarithm of the desired current, and adjusts the piezo Z output proportionally to that difference. Taking the logarithm is meant to compensate for the expoential dependence of tunneling current vs. gap distance. (I use an approximation for the logarithm, where only the integral power of two of the argument is determined, and a linear interpolation used inbetween.)
Some additional calculations are carried out as part of the feedback loop (and contribute to the rather large share of computing power it takes, as mentioned below): Average value and mean square fluctuation of the tunneling current, average slope observed in the scans (for automatic slope compensation).
Getting the tip to tunneling distance is actually more involved than keeping it there: In a loop, the piezo is fully contracted, the stepper motor moved one half-step, and then the piezo slowly extended while looking for tunneling current. If the desired current can't be reached, contract the tip and start over again. -- The procedure currently runs at 7 steps per second. Since each step averages 70nm, and I find that I can manually adjust the tip to about 100..200µm from the sample, this coarse approach may take a few minutes. But it will safely bring the tip to tunneling distance, and it's fun to watch!
The serial communications are uncritical as long as only commands and individual parameter values have to be transmitted. I chose to encode commands and parameter values in ASCII, so I can use a terminal program on the PC to control the STM. Only a few bytes at a time need to be transmitted. -- When it comes to transmitting image data, however, the RS-232 data rate of 115 kBaud (11.5 kByte per second max.) may well be a bottleneck for faster scans. Hence the driver for the DSP's aynchronuous serial interface (SCI) is interrupt-based and uses a massive ring buffer for transmission. A small buffer is used to receive complete command lines before passing them on to the command interpreter.
A preliminary quick reference of the DSP software's user interface (serial command syntax and LED display) is available as a Rich Text Format (RTF) document.
After having a closer look at Motorola's free C compiler for the DSP56002, I decided to write the software in assembler. Besides being worried about memory and processing speed efficiency, I was somewhat disappointed that the compiler does not seem to support a number of specific functions of the DSP and evaluation module:
The DSP56002 uses a modified Harvard architecture, like most DSPs. Unlike typical general-purpose microprocessors, it does not share a single data and address bus to fetch instructions and data ("von Neumann architecture"). Instead, three separate data and address buses enable the DSP to fetch an instruction and read or write two separate data words, all in a single instruction cycle. Motorola has labelled the program memory/bus "P", the two data buses "X" and "Y".
However, Motorola's evaluation board does not fully support the performance advantage provided by the Harvard architecture. To keep things simple, there is just one external RAM memory, 32k 24-bit words. You have two options of how to map it into the P/X/Y address space; but in any case, it supports only one data access per cycle, of course. (It is fast enough to serve the DSP56002 at 60 MHz without wait states.)
All is not lost, though, since the 56002 itself comes with 256 words each of fast X,Y RAM on-chip (address 0 .. $FF), as well as 512 words of fast P RAM (address 0 .. $1FF). These memories are - of course - connected separately to their repective data buses and are hence accessible in parallel, at full processing speed. I use these memory banks for the more time-critical tasks, like interrupt handlers and stack. The main memory on the EVM is addressed in "partitioned memory mode", which provides 16K words each to shared P/X and separate Y memory, and is mostly used for low-priority tasks.
This results in a somewhat complicated memory map, which I'm listing here in case you want to have a closer look at the source code provided below. Fortunately, the 56002 assembler supports multiple program and data address spaces by providing multiple address counters for P, X and Y.
For the really curious, the current version of the source code is available here as a ZIP archive. Please be aware that it's not finished yet: Transfer of image data to the host is still missing, and other parts may change later.
The copyright regulations for all material on this site apply to the software as well: Use for commercial purposes requires my explicit permission. Use for non-commercial purposes is granted free of charge, but I ask that you disclose the source and include a suitable copyright notice, and would appreciate if you let me know (email firstname.lastname@example.org) when you re-use this stuff. Thanks!Processor Load
Chosing a DSP as the platform for controlling the STM was just an educated guess: The Motorola DSP56002 had a good-quality codec on board, and the processing power and RAM seemed adequate. I had not done any quantitative estimate of the required processing power, however.
The code I wrote is definitely not typical DSP code and does not make good use of the specific strengths of the DSP. (Tight loops or repeats of the same op-code, accessing multiple data buses in each cycle...). As mentioned elsewhere, a modern general purpose microprocessor should certainly be able to do the job as well.
To get a better idea of the processing power actually used, I measured the duty cycle the processor spends in different subroutines by toggling a test output on entry and exit of these routines. In case you are thinking about using a different platform, here are the numbers for a DSP 56002 running at 60 MHz:
No meaningful number for the SCI driver (RS-232) is available until I actually transmit image data back to the host PC. I would expect up to 10% additional load for that task. -- In summary, it turns out that the DSP56002 is a reasonable match for the task at hand, with some computing power to spare for future extensions, but not hopelessly oversized as well.
Host PC: Scan control
I changed my mind concerning the platform I intend to use for the host PC software for controlling the STM. Instead of LabView, which I favoured initially, I'll probably use Visual C++.
The main reason is that I'm afraid of running into limitations with LabView: The number of parameters controlling the scan process is larger than I originally expected, and I find it easier to handle them in multiple dialogs than one big "virtual instrument" panel. I might also want custom controls, e.g. an option of selecting a new scan size/position in the image of the current scan. Maybe all of this can also be achieved with LabView (although I'm not sure about custom controls for the student version?), I just don't have the experience.
Since there's nothing else to say about the PC software yet, I'll leave the following paragraphs on LabView in here for the time being...
LabView is a graphical programming "language", specifically designed to control and automate instrumentation. Programming basically consists of setting up a front panel (by selecting knobs, displays etc. from a large range of standard elements) and "wiring" them in a data-flow block diagram which defines the actual operation. Among many other PC ports, LabView can drive the serial port and sound cards (apparently via the Windows Wave I/O drivers).
I have never worked with LabView, but it looks promising to me: It should be easy to build nice-looking front ends (although I'm not sure about very complex instruments, where you wouldn't want all control elements to be visible on the screen at all times - are pop-up front panels or dialogs possible?). Using the I/O functions, specifically for the serial port, also appears easy enough. On the downside, complex mathematical expressions might be painful to enter - do you really have to build and wire dozens of arithmetic blocks??
LabView is proprietary to National Instruments - originally a manufacturer of data acquisition boards, I understand - but is supported by many instrument manufacturers, who will provide LabView drivers for their instruments. Still, the programming environment itself is only available from National Instruments. While the full versions are intended for professional use and quite expensive (several 1000$), a student version based on the nearly current revision 5.0 is available for about US$ 85 from Addison-Wesley. The restrictions of that version are hopefully not critical for most amateur projects: No ActiveX controls, no external C DLLs (this might be annoying?), no stand-alone executables.
Host PC: Scan evaluation
Scanning the Internet for shareware and freeware applications suitable for post-processing of images was one of my early activities during the STM project. (Back in 1998 - somewhat premature considering the time it would take to take first images...). I re-checked the links below occasionally, most recently in April 2006, and was very pleased to find that all four packages were still around, and had been actively developed in the meantime. All applications are available for Windows 9x/ME and Windows NT/2000/XP (and other platforms, in some cases). I have to admit that I just skimmed them quickly, so these notes are by no means intended to be reviews, but just annotated links:
A general-purpose tool for quantitative image processing and analysis. Distributed by Scion Corporation, a manufacturer of video capture boards, Scion Image is based on NIH Image (by the National Health Institute) and hence available for free. The software offers the typical range of filtering, segmentation, object recognition etc. also found in commercial packages. The user interface can't deny its Macintosh heritage.
NIH itself is still continuing development of NIH Image, and is maintaining a Java implementation called ImageJ. ImageJ is public domain software; the complete source code is part of the standard distribution. On my old PC (120 MHz Pentium) it ran noticeably slower than a native application, but any reasonably current machine should be fine. Due to the Java implementation and a software plugin interface, ImageJ is very flexible and extendable, and seems to have a large and active user base. I have also heard it praised for its stability.
Another general-purpose image processor. Developed by The University of Texas Health Science Center, Image Tool is also available for free. Image Tool has an impressive range of features, including a powerful Pascal-like script language. From what I saw during a first quick tour, it compares very favorably to some expensive commercial packages. When I tried version 2.0 Alpha in 1999, it was quite unstable, but I am happy to see that development has been continued. The current version is 3.0, which is meant to be the "final release".
The Scanning Probe Image Processor is different from the three packages mentioned above, because it is specifically geared to post-processing and evaluation of scanning probe microscopy images. To that end, SPIP offers precise quantitative angle and distance measurements, image calibration (using scans of suitable standard samples), tip characterization, roughness measurements, 3D visualization...
SPIP was originally developed at the Danish Institute for Fundamental Metrology. A spin-off company, Image Metrology, has been founded to commercialize the software. A free trial version is available for the Windows platforms, which is limited to 128*128 image size. (Reduced to 64*64 after 30 days of use.) Prices for the full commercial version are not available on-line, but quite probably out of the amateur's reach.
An impressive piece of Linux software, available under the GNU license. To quote the project description:
The GXSM software is a powerful graphical interface for any kind of 2D and 3D (multilayered 2D mode) data acquisition methods, but especially designed for SPM and SPA-LEED, which are used in surface science. It includes methods for 2D data (of various types: byte, short, long, double) visualization and manipulation. It can be used for STM, AFM, SNOM, SPA-LEED, but is by far not limited to those! Especially in standalone mode it can perform many SPM typical image manipulations and analysis tasks.
Developed over several years by Percy Zahl and a number of others, GXSM started out as a simple control program for an STM driven via an AD/DA converter card with DSP. It can still control scanning microscopes and other imagers (if they use the right DSP sub-systems), but has grown strongly and now also seems very capable in visualizing and analysing images. I have not tried this myself, but I think I will!
STM Project Homepage