circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 

September 2004, Issue 170

Multilab
Build a Z8 Encore!-Based Multipurpose Test Instrument


by Brian Millier

POWER SUPPLY

Figure 5 is the schematic diagram of the power supply. Because of the mixed-signal nature of the project, a number of voltages were necessary. Both the arb DAC and the op-amps are connected to the raw ±12-V outputs of the bridge rectified power supply. The Z8 Encore! and IrDA transceiver need 3.3 V, which I also used for the CMOS chips in the PLL and the 24LC256 flash memory. An LM1086-3.3 provides the 3.3-V supply.

(Click here to enlarge)

Figure 5—A multivoltage power supply is needed because this is a mixed-signal design. A Zener diode provides an additional –5-V supply, which isn’t shown here (refer to Figure 1).

However, the MAX232, DAC7611, and TC500 need 5 V, so a 7805 is also required. The TC500 also needs a negative voltage source, which is provided by a 5-V Zener diode. Maxim also makes the TC510 with a built-in charge-pump, but I didn’t spring for this version because I had a negative supply available.

Z8 FIRMWARE

I’d used either assembly language or BASIC for every MCU I’ve worked with over the years. I hadn’t used C language. Because the Z8 Encore!’s IDE and on-chip debug facility were tailored to work with the free ANSI C compiler included with the development kit, I decided it was time to learn something new.

I used the serial I/O, I2C, SPI, and floating point/ trigonometric functions included with the C compiler package. There is also a library titled API, which handles all of the timer functions. I used it to some extent, but in some places, particularly where setting up the timers needed to be done quickly, I wrote my own faster timer handling routines.

I used numerous variables, including a memory array of 256 or more elements for the arb waveform memory, so I implemented the large memory model in the compiler. The small memory model uses only the basic 256-byte register space in the Z8 Encore!. I also had to remember to explicitly instruct the compiler to use the floating-point library because the waveform generation, as well as many of the timing calculations, was done in floating point. The program used up approximately 60% of the 64-KB flash memory in the Z8F6401.

The program flow is fairly basic. At reset, all of the necessary I/O ports are configured properly. Then the RS-232/IrDA switch is checked to see if the unit is going to be talking to a PC directly or to a Palm Pilot via the IrDA link. The applicable UART port is then selected as the active communication port, and the program enters a loop awaiting commands.

All commands consist of a single line of ASCII text containing three numeric parameters. The first parameter is the function number (currently one through seven). The meaning of the other two parameters varies by function. The only exception is the store waveform command. After the normal command line, a series of bytes follows. These are the waveform values themselves.

After the Z8 has received a complete line, it uses the sscanf function to parse it into the three numeric parameters. The first parameter is used with the switch function to call the appropriate routine. The other two parameters, which are floating-point numbers, are used to set up the waveform shape, frequency, pulse widths, and reference voltage as required by that particular function. Only in the case of the DC voltmeter function is a value returned to the PC or Palm Pilot. In this case, a 16-bit integer is transmitted back to the host where it is scaled into the correct voltage readout. Table 3 shows the structure of the various commands used by the MultiLab.

PC & PALM APPS

Both Palm Pilot and PC applications are needed to operate the MultiLab. In the case of the Palm Pilot, I used AppForge’s MobileVB program, which is designed as an add-in tool for Visual Basic 6, and allows the Visual Basic programmer to operate in the familiar Visual Basic environment. However, it creates a program that will run on the Palm Pilot.

I have experience with Visual Basic, so MobileVB wasn’t too hard to get used to. I wrote an application to handle the various functions, but, given the time constraints of the Zilog Flash for Cash Z8 Encore! International Design Contest, it isn’t too fancy. Photo 1 shows one screen of the Palm application running in MobileVB’s PC Emulation mode. However, my digital camera couldn’t take a clear enough picture of the application running on the Palm Pilot to show you.

(Click here to enalrge)

Photo 1—The Palm Pilot application program is shown here running under PC emulation. My digital camera didn’t take a clear photograph of the Palm’s small screen. 

The PC application, which was written in Visual Basic 6, performs a similar function to the Palm Pilot program, except it can also download arb waveforms to MultiLab. Photo 2 is a screen shot of the application. Photo 3 shows a sampling of some of the arb’s output waveforms. Photo 4 shows the MultiLab without its top cover. 

(Click here to enlarge)

Photo 2—The Visual Basic PC application acts as the MultiLab’s front panel. Although it handles the same functions as the Palm Pilot application, it’s easier to use because it isn’t limited by the Palm Pilot’s small screen limitations.

 

(Click here to enalrge)

Photo 3—Here are four output signals from the MultiLab captured by my Tektronix 3052 DPO oscilloscope. Working clockwise from the upper left you can see a sine wave with added harmonics, pure sine wave, square wave, and sawtooth.

 

(Click here to enlarge)

Photo 4—Apart from the power supply, all of the MultiLab’s circuitry fits easily on a vector 8001 prototype card. The window that allows IR communication with the Palm Pilot is barely visible under the red-handled power switch.

BUILT-IN ADVANTAGE

Considering that the Z8 Encore! and C language were completely new to me,  I must admit that working with the Z8 development board and software was a pleasure. During the early stages of the project as I stumbled around with unfamiliar C syntax, the on-chip debugger was a prayer answered. The MCUs I’ve used in past projects didn’t have this built-in function, but now I don’t want to do without it. Overall, I’m pleased that the project has met my expectations.