PDACS II
Portable Digital Audio CoDec System II
Final Report
Christopher Lee Medrano
Scott Charles Robey
Thomas Grant Pugliese
CPSC 483 - 501
Dr. Mahapatra
Acknowledgements
PDACS II would like to thank the following people for their help with the
implementation of the project.
Dr. Rabi Mahapatra, Instructor
Nan Ni, Teaching Assistant
Ajay Thadhlani, Teaching Assistant
Trey Griffin, Teaching Assistant
Table of Contents
1. Abstract and Introduction …………………………………. 2
2. Choosing a Platform ………………………………………... 3
3. LCD Interface ………………………………………………. 8
4. A/D Subsystem ……………………………………………… 10
5. D/A Subsystem ……………………………………………… 18
6. Keypad Interface Design …………………………………… 23
7. Accessing the Coldfire Bus Connectors …………………… 24
8. Low-Level System Software ……………………………….. 27
9. Technical Problems ………………………………………… 29
10. Conclusion………………………………………………….. 31
11. References .………………………………………………….. 32
12. Appendices ………………………………………………….. 33
 A. LCD Manual






B.
C.
D.
E.
F.
G.
D/A Converter Manual
A/D Converter Manual
Selected Component Pricing
National Instrument DAQ Board Pinouts
Excerpts form 5206e Programmers Reference Manual
PDACSII Source Code
-1-
Chapter 1: Abstract & Introduction
Abstract:
The purpose of PDACS is to provide a simple way to record and store audio for
later playback. The original PDACS was implemented in the spring of 1999 semester
using a Xilinx FPGA. While an FPGA provides for rapid development, a more dedicated
processor would have many benefits. Our proposal is to implement PDACS using the
Motorola Coldfire MCF5206e embedded processor on a M5206eLITE demo board.
Using the MCF5206e processor, we can also simplify the design. Several functions that
needed external hardware on the original PDACS can now be done on-chip. We will
interface A/D and D/A converters, a LCD, and a keypad. With time permitting we will
also add audio compression and a serial interface with GUI. The MCF5206e also has
much better performance for both I/O functions and integer calculations.
Introduction:
PDACS 2, like the original PDACS is designed for recording, storage and
playback of audio. Users will specify which functions they wish PDACS to perform
using a keypad, and a LCD will be used to display the output to the user. Audio will be
recorded using a microphone. The analog audio signal will then be converted to digital
using an A/D Converter. The digital signal will then be sent to the M5206eLITE
Demo Board where it will be compressed (if time had permitted) and stored in memory.
The user can then elect to playback the audio that has been recorded through a speaker or
to store the audio on a PC (if time had permitted).
Much background research was done throughout the implementation of PDACS
2. Documentation from the original PDACS provided a great deal of useful information,
especially with regards to the external hardware in the audio subsystem. Research into
digital audio principles was needed to ensure proper conversion of the analog signal.
Research into compression algorithms, was needed even though compression is no longer
a priority of PDACS 2. In addition, a great deal of time was spent learning to use and
experimenting with different developing environments, as many of these environments
did not perform optimally. Also research into obtaining connectors to access the board’s
data, address, and control lines proved to be very frustrating and time consuming.
-2-
Chapter 2: Choosing a Platform
At the time of the initial proposal it was our plan to implement the project using the
Motorola M-Core embedded processor board. The M-Core board is built around the
MMC2001 embedded processor. Figure 1. Shows a block diagram of the MMC2001
processor architecture.
Figure 1. MMC2001 Block Diagram
Based on the block diagram of the processor, the MMC2001 embedded processor would
be perfect for the implementation of PDACS II. In addition to providing access to its
data and address buses, it also has two independent UART channels, as well as a Pulse
Width Modulation module, Interval Mode Serial Peripheral Interface for, and 2 general
purpose I/O ports. The existence of the UART channels would make serial connection to
a PC very easy. The GPIO ports would allow easy interface of a keypad and LCD. And
the accessibility of the address and data buses would allow us to interface the A/D
converter, D/A converter, and memory module using address decoding and chip select
-3-
lines. The on-chip timer functions would be used to clock the A/D and D/A converters.
The project seemed very feasible until we took a closer look into the architecture of the
evaluation board itself.
After examining the architecture of the M-Core board and looking at the
connector pin assignments we noticed that there were connectors on the board for
everything but the data and address bus. Figure 2 shows the layout of the evaluation
board.
Figure 2. MMC2001 Evaluation Board
P1, P2B, and P5 are the locations of the pin connectors on the boards. They are 2-by-20
pin connectors that are the evaluation boards I/O and interrupt connectors. P1 has
connectors for a keypad, and a few interrupt lines. P2A has more keypad connectors and
had lines for the serial peripheral interface. P2B had connectors for the UART channels
and pins for the Pulse Width Modulator module, and P5 had connectors for the on-chip
emulation (OnCE) debug module. The board allowed serial communication. But
because of the lack of parallel communication with the board other than a few keypad
lines, we decided that the board would not be sufficient to effectively implement the
project. Had the board allowed access to the address and data buses we would have had
no trouble accessing them especially since an EVBProto breadboard board was included
with the evaluation board. Many header pads on the breadboard (P1, P2A, P2B) had
mounting holes that would have made wiring wrapping fairly easy. Figure 3 shows the
EVBProto Breadboard.
-4-
Figure 3. The EVBPROTO BREADBOARD
Next we turned to the Motorola M5206Elite Board since it was available. The
M5206eLITE is based on the MCF5206e Coldfire Processor. After looking at the system
configuration of the board we determined that the board allowed access to the address
and data bus. Figure 4 shows the system configuration of the board.
Figure 4. M5206eLITE System Configuration
-5-
With 2 serial interfaces (J4 and J9, one of them for communication with a RS232
Terminal or a PC with emulation software), a 5V Tolerant GPIO connector (J10), an
Open Collector GPIO connector (J11), and access to the address and data lines through
the Microprocessor Expansion Bus (J1 & J2), the M5206eLITE appeared to be a good
choice for the platform of our project. The 8 data lines available at the GPIO ports
allowed for easy wire wrapping, and with the proper cable all of the processor signals
would be available through the Microprocessor Expansion Bus. However, it would later
prove to be extremely difficult, if not impossible to obtain the correct cables for the
Microprocessor Expansion Bus.
After obtaining the M5206eLITE board, the first task was to connect to the board
using the serial interface connected to our PC. Using HyperTerminal we attempted to
connect to the board. We found that we were unable to connect to the board, and we
spent a good deal of time trying to find the problem. Originally we thought that it was a
problem with the serial connection we had between the board and the PC. After we
determined that this was not the problem we thought that we had a potential power
problem. Finally we determined that the board was defective and we were forced to
obtain a new board.
Setting up the Debugging Environment for the 5206eLITE Board
For PDACSII, the Green Hills MULTI Compiler was used. A detailed description of the
selection process is given in Chapter 9: Technical Problems. There are 7 steps involved
in setting up the compiler and getting a project started on the 5206eLITE board.
1.
2.
3.
4.
5.
6.
7.
Acquire and install a license.
Install the parallel debugger
Create a working directory and copy files
Create and configure a build file.
Add source files to the project.
Connect to the remote device
Run the program in the debugger
1. Once MULTI is installed, a license can be requested using the provided license
requestor application. Install the license using the provided license installer
application.
2. Next plug the parallel debugger into the board.
3. To make sure that no default files are overwritten, MULTI must be run from a
different directory for each project. You can create the directory in MS-DOS and
then change into it, or you can put a shortcut on the desktop with the working
directory of the shortcut set to the directory where your project is. Copy
cf5206elite.lnk and cf5206elite.ocd from the C:\Green\demo\ocddemo directory
into your project directory. The cf5206elite.lnk file is a memory map for the board
and cf5206elite.ocd is a setup script used to initialize the board on boot up. When
you start MULTI, it will create a file named default.bld in the current directory.
-6-
4. Next add your own project build file. Type the name of your project ex ‘hello.bld’ in
the Add box and click on the Add button. Now you have to set up your hello.bld file
to use the memory map and script file. Double click on hello.bld to move down in
the hierarchy. Now Click Add and select cf5206elite.lnk to add this file to the
project. Next click on Target and select coldfire.bld from the C:\Green directory.
This tells the program which processor to build for. Now select
Options->Advanced and type
ocdserv -nobss lpt1 cf5200 -s cf5206elite.ocd
in the Remote box. This tells the program to use the correct script file on start up.
Close the options window and select File->Save. Click on the upward pointing
arrow button and then double click on hello.bld again. The above line should now
show up in the Remote box.
5. Add sources file to your project. Type the name of each source file into the Add box
and click the Add button.
6. Click the Remote button to connect to the board. Two boxes should pop up and the
one on the left should show the OCD> prompt.
7. Click on Debug to start the debugger and run the program from there.
-7-
Chapter 3: LCD Interface Design
In order to give a status display for our PDACS device we decided to use a LCD
Interface. The Optrex LCD DMC20434 was our choice of display. It was conveniently
available in the lab’s inventory, and it had all the capabilities we needed for our project.
LCD Implementation:
The first step in implementing our LCD device was figuring out how it would be
interfaced with the 5206eLite coldfire demo board. Since our parallel port was only 8bits wide and we needed 11-bits for normal operation, we decided to run the LCD in 4-bit
mode. (Appendix A) By running in 4-bit mode, we were able to use only 7-bits for
transferring instructions to our device.
The following shows the difference between 11-bit method and 7-bit method.
 11-bit mode
8 I/O lines.
1 Enable line
1 Read/Write line
1 Register Select line
*This would have been possible had there been a 16-bit parallel port device attached
to the coldfire board.

7-bit mode
4 I/O lines
1 Enable line
1 Read/Write line
1 Register Select line
*This was our choice of operation because we only had 8-bits to work with.
Hardware Implementation:
LCD Attached to GPIO J10 in 4-bit Mode Operation
LCD
Optrex
DMC20434
GPIO (J10)
D7
D6
D5
D4
D3
D2
D1
D0
N.C.
-8-
Figure 5. LCD Subsystem
The LCD was attached to our coldfire board via the GPIO port at J10. (Figure 4)
Software Implementation:
For the software implementation of this device we implemented a LCD library written in
C that contained a set of abstract functions that would allow a user to use the LCD to its
maximum potential.
Basic Functionality:
 Set LCD mode
 Turn LCD ON/OFF
 Set Display Position
 Initialize LCD
 Display Characters and Strings to LCD
 Turn Cursor ON/OFF ; Blink ON/OFF
 Create Custom Characters
 Display Custom Characters
Testing LCD Interface:
The LCD interface performed perfectly in testing. We demonstrated the ability to write
characters to any position on the LCD. We also demonstrated an animated Waveform
scrolling horizontally on our LCD display that was created using our custom character
create and display functions.
-9-
Chapter 4: A/D Subsystem
The purpose of the A/D Subsystem is to obtain an analog signal from a
microphone, digitize the analog signal, and provide the digitized audio to be received by
he M5206eLITE board for storage and playback. We decided to use 8-bit, 8 KHz
sampling since telephone quality speech is 3 kHz and Nyquist’s theorem states that the
sampling rate must be at least twice the desired signal frequency to accurately represent
the analog signal. 8-bit encoding of a 0 – 5 V analog signal would allow the signal to be
represented by a total of 256 possible encodings. This would allow the analog signal to
be represented accurately to within 0.01953125 V. Since the A/D and D/A subsystems in
PDACS II would be similar to those in PDACS I not much time was allotted to the
implementation of both systems in the initial proposal. It became apparent very early
into the project that even though many of the schematics for the A/D and D/A subsystems
were available thanks to PDACS I, that this part of the project was not nearly as easy as it
looked. Unforeseen problems hampered the progression of this portion of the project and
forced us to allocate a lot more time to this area. The complexity of this portion of the
project was expressed to us early in the semester by a previous member of PDACS, who
explained that the audio subsystem was the most difficult part of the project, so we
prepared to invest more time into this area. Problems that arose throughout the semester
were primarily due to a general lack of knowledge of audio components and signal
processing, in addition to unpredictable component behavior and failure. The few
semesters of electrical engineering courses would prove to be totally insufficient for
dealing with the real world problems that would arise in the project.
A block diagram of the A/D subsystem is provided below, each component of the
A/D subsystem will be elaborated on in the following subsections.
- 10 -
MIC & MIC
JACK
INPUT FILTER
Amplifying Circuit
A/D Converter
DC Offset &
Inverting Circuit
8 data lines out
to 5206eLite
board
CLOCK
GENERATOR
Figure 6. A/D Subsystem
Section 4.1 – Microphone and Microphone Jack
The first step in implementing the A/D subsystem was acquiring a microphone
and microphone plug to obtain an analog signal from the microphone. Originally an
Optimus high-impedance, low-power microphone was used. After building a very basic
circuit with the microphone plugged into a simple 3-conductor, 3.5 mm microphone plug,
the analog signal was observed using a built in oscilloscope VI in LabView. A pin out
description could not be obtained for the microphone plug, but it was known that one pin
was GND, one + 5V and one the analog output signal. After trying every combination of
pin assignments a signal could not be obtained from the microphone jack. Several
different variations of the 3.5 mm microphone jack were experimented with but none of
them produced any output. It was then thought that the signal was too weak and needed
to be amplified before it could be observed. Various amplification circuits were built but
all of them failed to show any analog signal coming from the microphone. Finally we
acquired another microphone, a SUN lapel microphone, and immediately we were able to
observe an analog signal coming from the microphone jack. It was never determined
exactly why the original microphone did not work; a possible explanation is that the
microphone is simply incompatible with the different jacks we were using. Figure 6
shows the pin configuration of the microphone jack.
- 11 -
OUT
+ 5V
GND
Figure 7. Microphone Jack
4.2 - Amplifying Circuit
The next step in the A/D subsystem was building an amplifying circuit to amplify the
analog signal from the microphone jack. Since the A/D converter encodes all analog
signal values between 0 and 5 Volts, the amplifying circuit must provide the appropriate
gain to take advantage of all the possible encodings. Research by PDACS I showed that
a circuit with a gain of about 193 V/V would put the analog signal in the range of 0 to 5
Volts. Using a 351 op-amp in an inverting configuration and 3 resistors, an amplifying
circuit with a gain of 193 V/V was produced. The gain for an inverting amp is
– Ro/Rs * Vin; where Ro is the resistance across the op-amp and Rs is the resistance at
the source. Figure 7 shows the inverting amplifier circuit.
Figure 8. Inverting Amplifier, gain = 193 V/V
- 12 -
After building the circuit and testing the output using LabView we weren’t getting any
signal. Initially it was thought that the amplifying circuit was not appropriate so an
alternate amplifying circuit using a LM386 – 400 mW Audio Amplifier was built.
Leaving the gain inputs of the LM386 open the IC produces an internal gain of about 20
V/V. By applying capacitors or resistors between the gain terminals we can produce a
gain between 20 and 200 V/V. Various configurations of the audio amp were tested but
none produced any kind of output. Figure 8 shows the LM 386 Audio Amplifier.
Figure 9. LM 386 Audio Amplifier
Finally, after the microphone issues were resolved we reverted back to the original
inverting amplifier circuit. The inverting amp would now provide a 0 to 5 V signal with
the appropriate offset circuit when the microphone was placed approximately 1 foot from
the mouth. The circuit was tested using a basic data acquisition -> analog input VI in
LabView.
4.3 - Offset and Inverting Circuit
Since the amplifier of section 3.2 is used in an inverting configuration the signal must be
reverted back so that it is in the range of 0 to 5 V. In addition, the microphone provides
an analog signal with both positive and negative values so the signal must be offset in
order to get rid of the negative values and prepare the circuit for the input filter. Figure 9
shows the inverting and offsetting circuit.
- 13 -
Figure 10. Inverting/Offset Circuit
Testing the circuit using LabView showed that the output of the circuit was within the
range of 0 to 5 V.
4.4 - Input Filter
It was discussed at the time of the proposal that a possible way to improve the quality of
audio for the system would be to put a bandpass filter on the input signal. PDACS I used
a low-pass filter with a cut off frequency of 3.33 kHz to filter the input signal. It was a
believed that if a bandpass filter was introduced allowing only frequencies in the range
100 Hz – 3.33 kHz to pass then unwanted low frequencies from power supplies and other
components would be filtered out. This part of the project was to be implemented after
the rest of the audio subsystem was completed and working. A National Semiconductor
LMF100 High Performance Dual Switched Capacitor Filter was obtained and it was
intended to be inserted into the A/D subsystem after the rest of the system was
completed. Near the end of the semester research into using the LMF100 as a bandpass
filter was done. The data sheet for the LMF100 was extremely poor. It was not
extensive at all and only provided a very select number of example configurations, and a
very limited description of pin operation. Application notes could be not be found for the
chip, and severe problems in other areas of the project caused attention to shift away from
the implementation of the bandpass filter and prevented it from being incorporated into
the final version of the project.
Since a low-pass filter was to be used for the output, we decided to build the low
pass filter to make sure we could get it up and running in case there wouldn’t be time to
implement and bandpass filter.
A LTC1062 5th order Low Pass Filter was to be used. The chip could be selfclocked using its own internal clock, or an external clock could be used. The ratio of
cutoff frequency to input clock frequency was 1:100. That meant that in order to cut off
all frequencies above 3.33 kHz we would have to provide the filter with a clock
frequency of 333.3 kHz. Originally it was thought that it would be possible to use the on-
- 14 -
chip clock with a capacitor to provide the appropriate cut-off frequency but the clock’s
maximum frequency was 140 kHz thus allowing a maximum cut-off frequency of only
1.4 kHz. It was clear that we would have to use an external clock. PDACS 1 had used an
external clock generated by the FPGA, but since initially we were not planning to use the
FPGA at all it was decided that the appropriate clock frequency would have to be created
elsewhere.
After speaking with Professor Mahapatra and the TA’s a few different solutions
were proposed. The first was to use a 4 MHz crystal oscillator and a clock divider. This
would allow us to provide either 500 kHz or 250 kHz clock signals, but these signals
were not even close to the desired clock frequency of 3.33 kHz. The other solution was
to use a 555 timer to produce the appropriate clock signal. Theoretically using an LM555
timer in astable operation with appropriate resistors and capacitors could be used to
provide a 3.33 kHz clock signal. Figure 10 shows the schematic of the LM 555 in astable
operation.
Figure 11. LM 555 Timer in Astable Operation
The data sheet provided a simple equation to calculate the resistor and capacitor
values necessary to provide the appropriate clock frequencies:
F = 1.44 / ((Ra + 2Rb) * C)
Using this equation we found that with Ra = 1 kohm, Rb = 3.9 kohm, and C = 470 pF we
could produce a frequency of about 348 kHz, close enough to 333 kHz to be used. After
building the circuit and analyzing it using an oscilloscope, we found that it was producing
a clock frequency of 222 kHz not even close to the calculated frequency. Playing with
different resistor values seemed to have little effect on the frequency so a new circuit was
designed using a capacitor with greater value. With Ra = 200 ohm, Rb = 110 ohm, and
C = .01 uF the circuit should theoretically provide a 342 kHz signal. This circuit was
built and tested but again produced a frequency of 222 kHz. It was then believed that the
555 timer was bad, so a new timer was obtained and tested. It produced a higher
- 15 -
frequency but the signal was extremely poor, and could not be used. After trying several
different National LM555 timers it appeared that the chip could not handle high
frequencies. So a Texas Instruments TLC 555 timer was purchased and tested. The
timer had very similar specs and operation so it could be easily placed into the circuits in
place of the LM555. The chip did not produce predictable frequencies based on the
equation given in the data sheet but after tweaking the resistor values a little we were able
to get a 333.3 kHz frequency from the chip using Ra = 1 kohm, Rb = 2.7 kohm and C =
471 pF.
With the appropriate clock frequency we could now wire the low-pass filter.
Figure 11 shows the schematic of the low-pass filter where R = 330 ohms, C = .1uF, V+
= +5 V, V- = -5 V and Fclk = 333.3 kHz from the 555 timer.
+
Figure 12. LTC1062 Low-Pass Filter
4.5 A/D Converter
An National Semiconductor 8-bit ADC0804 Analog to Digital Converter was used to
digitize 0 – 5 V analog signal. It was built in self-clocking, free-running mode in order to
test it without the use of the microprocessor. In this configuration the internal clock is
used as the clock in signal to clock the chip. This allowed the chip to run at 8.88 kHz,
well above the desired 8 kHz sampling rate. The INTR line was wired to the WR line so
that a microprocessor would not have to be used to provide acknowledge signals for the
A/D converter. Figure 12 shows the diagram of the A/D converter in self-clocking, freerunning mode.
- 16 -
Figure 13. ADC0804 A/D Converter
After wiring the A/D converter the data bits were tested using LabView. The chip
was not producing valid outputs, and soon after proceeded to overheat. It was then found
that in free-running mode the A/D must have its WR line momentarily grounded in order
to ensure proper operation. A switch was introduced to the system to allow the WR to be
momentarily grounded on startup, after it was grounded the switch was left open. The
chip then proceeded to work correctly.
To test the A/D converter a function generator was used to provide a sine wave
analog signal to the A/D converter. Using a built in function generator VI in LabView a
5 V peak-to-peak sine wave was produced and sent to the A/D converter. The data bits
were then observed using a built in digital data acquisition VI. The data bits appeared to
be changing as predicted with the change of the analog signal. With the approach of midterm presentations a simple test circuit was designed to show some definite observable
operation of the A/D converter. LEDs were wired to the data bits of the A/D converter to
observe the encodings of the analog signal. This test circuit for the A/D subsystem was
not effective for evaluating the output of the A/D converter. The function generator and
microphone provided a signal that changed too quickly to observe a change in the LEDs.
Instead a new test circuit was designed. A 10 kohm potentiometer was used instead as
analog input into the A/D converter. When the potentiometer is slowly turned from 0 to
5 Volts the LEDs can be observed to be counting from 00000000 to 11111111. The test
circuit performed nominally and was demonstrated in the mid-term demonstration.
After countless hours of wire-wrapping and testing the A/D subsystem was finally
completed and working as desired after more than half of a semester’s worth of work.
The next step in the production of the audio subsytem was to implement the D/A
subsystem
- 17 -
Chapter 5: D/A Subsystem
The purpose of the D/A Subsystem is to take digital inputs from the evaluation
board, convert this digital signal to analog and send the analog signal to a speaker for
playback of the original audio signal obtained by the A/D Subsystem. A block diagram
of the D/A Subsystem is provided below. Each component of the system will be
elaborated on in the following subsections.
8 data lines +
1 control line
from board
D/A Converter
w/ current to
voltage converter
Audio Amplifier
W/ Volume
Control
Output Filter
Inverting Circuit
8 Ohm
Speaker
Clock
Generator
(333.3 kHz)
Figure 14. D/A Subsystem
5.1 - D/A Converter
The first step in implementing the D/A Subsystem was to get the D/A converter
working and properly converting the digital signal to analog. A Texas Instruments 8-Bit
Multiplying TLC7524 digital-to-analog converter was used in unipolar, free-running
mode. The conversion time of the chip is 100 ns, easily fast enough for the rate at which
changing data would be provided to it by the evaluation board. The D/A converter was
initially used in current-mode. This meant that the D/A converter would output current
only, an op-amp was used to convert the current to voltage to be used to for an analog
signal to the speaker. Figure 14 shows the configuration of the D/A converter
- 18 -
Figure 15. TLC7524 D/A Converter in Unipolar, Free-Running Mode
In this configuration the analog output would be a factor of the Vref voltage, which is 5V,
and the data lines. Figure 15 shows the expected analog output chart for the D/A
Converter.
Figure 16. Unipolar Binary Code
After the D/A converter circuit was built it was tested using LabView. A simple built in
VI was used to provide 8 digital data lines to the D/A converter. This would allow the
data bits of the D/A converter to be easily manipulated. The analog output of the D/A
converter was tested using the built in data acquisition, analog-in VI in LabView. When
the circuit was first tested it appeared that the D/A converter was bad. The D/A converter
did not seem to be providing a good analog signal. The signal was fixed at –5 V, which
is correct only if the data lines of the D/A converter are all 1’s. Changing the data lines
and the chip select appeared to have no effect on the analog output. After investing some
time and effort into debugging the problem it was found that the original schematic from
PDACS 1 was incorrect. It had simply reversed the output pins of the D/A Converter.
After reversing the output pins of the D/A converter it appeared as though the D/A was
working as desired. The D/A was tested by changing the data lines in the LabView VI
- 19 -
and observing the analog output of the D/A converter. Various values were input to the
D/A and it was producing the appropriate analog voltage. The chip select was then tested
and showed to latch the output of the D/A when driven high, as it was supposed to. After
it was established that the D/A converter was working properly, attention was shifted to
the rest of the D/A Subsystem.
After completing the rest of the D/A subsystem the D/A converter was then wired
to a 74HCT4020 – 14 Stage binary ripple counter for testing. The upper 8-bits of the
counter were wired to the data inputs of the D/A Converter in order to produce a
predictable series of data inputs so that the analog voltage could be easily observed.
Figure shows the setup of the counter.
Figure 17. 74HCT4020 Binary Ripple Counter
Again the D/A chip was not working properly, this time the chip was providing no output
voltage. It was at this time that other components of the project seemed to be behaving
abnormally; inordinate amounts of noise were being noticed on several of these
components. It would later be found that noise from a keypad, and an inverter IC was
causing the abnormal behavior. Because of this the D/A converter was re-wired on
several breadboards and tested. The converter did not produce any decent output
regardless of the status of the data and chip select lines. Next the D/A converter was
wired in voltage-mode operation to see if we could obtain any kind of analog signal from
the chip. In this mode a fixed voltage is placed on the current output terminal (OUT1),
the analog output voltage is then available at the reference voltage terminal (Vref) where
Vout = Vin * (D/256); Vout is the analog output voltage, Vi is the fixed voltage and D is
the decimal representation of the digital bits of the D/A Converter. Again the chip was
not providing any signal. It looked as though the chip was bad or damaged.
Because it was the end of the semester a new TLC7524 chip could not be ordered
and Mid-State Electronics and other local electronic stores did not carry any D/A
converters. Another chip was found from a previous project, the National Semiconductor
DAC0830, and it was intended to use this chip in place of the TI chip. The DAC chip
operated similarly to the TLC chip based on the data sheet but according to PDACS 1 the
- 20 -
chip did not have a fast enough conversion rate for the 8 kHz sampling. Regardless, the
chip was wired but due to time restraints was not integrated and tested in the final project.
5.2 - Inverting Circuit
Since the D/A converter produced an analog output voltage equal to – Vref * D/256, the
signal from the D/A would need to be inverted to put the signal between 0 and 5 V. The
following is the schematic of the simple inverting ciruit.
R2
1K Ohm
R1
1K Ohm
Vin
741
-
+10V
Vout
+
-10V
Figure 18. Inverting Circuit
5.3 - Output Filter
In addition to filtering out unwanted frequencies, the output filter also provides another
service. Because the D/A converter does not produce a continuous waveform, the
primary function of the output filter is to smooth out the discrete waveform and convert it
to a continuous one. The D/A conversion time is extremely fast but it will not produce a
totally continuous waveform. The tiny steps in voltage would prove to be very
detrimental to the quality of the sound produced, if a filter did not exist to smooth out the
signal. The output filter is the same as the low passe filter that was initially used on the
input. Again an LTC1062 is used with a cut-off frequency of 3.33 kHz, provided by the
TLC 555 timer. Figure 17 shows the diagram of the output filter.
- 21 -
Figure 19. LTC1062 Low Pass Filter
5.4 - Audio Amplifier with Volume Control
The audio amplifier circuit was designed to provide the right amount of gain to
amplify the signal enough to be heard. An LM 386 Audio amplifier was used to amplify
the signal and a 10k potentiometer was used for volume control. Leaving pins 1 and 8
open allows the LM 386 to operate with a gain of 20 V/V. Figure 18 shows the
configuration of the Audio amp with volume control
Figure 20. Audio Amp with Volume Control
The circuit was tested using a function generator VI in LabView to provide a
waveform to be output by the circuit. The circuit produced an audible signal whose
volume could be controlled slightly using the potentiometer.
- 22 -
Chapter 6: Keypad Interface Design
A 4x4 button keypad will be used to provide our PDACS with a 4-bit Keypad data signal
depicting which key has been pressed as well as generating an interrupt preempting our
CPU to read and respond to the 4-bit control signal. The control logic for the keypad
interface was implemented using a Xilinx FPGA.
Keypad Implementation:
The design used for the keypad was taken from the Xilinx FPGA tutorial chapter 16.
Play
Stop
Record
Interrupt
Keypad Data
Keypad
Coldfire Board
Figure 21. Keypad
The 4-bit control signal will be decoded in the following manor.
 The two most significant bits of the keypad data lines refer to the row of the key
pressed 0—3.
 The two least significant bits of the keypad data lines refer to the column of the key
pressed 0—3.
Testing the Interface:
The interface was tested using the LED’s located on the FPGA to display the generated
keypad data and interrupts. The keypad worked fine and it was decided that debouncing
would be handled through a software routine implemented on the coldfire board.
- 23 -
Chapter 7: Accessing Coldfire Board Bus Connections
This 5206eLite coldfire allows users to access all data, address, and control lines through
connections J1 and J2. (Figure 4) These connections required a female Samtec 80-way
connection of the SFM 0.050" series.
There were no commercially available items or kits for gaining access to the data,
address, and control lines on the 5206eLite board. The following is a list of investigated
options on getting a connection to access data, address, and control lines from 5206eLite
board.
Options:
 Soldering wires on to surface mounted pad of female SFM 0.050" Samtec 80-way
connection.
Arguments: This process would require a fine tipped soldering iron and lots
of precision soldering work to attach all pins to wire connections. There is a
risk of damaging the connectors that cost around $12 each. Another course of
action would require mounting the Samtec connection to a printed circuit
board, but as far as is known, there is no existing retail circuit board in which
the connection could be mounted.

This leads to the second option of designing a PCB (printed circuit board) to connect
directly on to connections J1 and J2 of the 5206eLite coldfire board via a surface
mounted Samtec SFM18002SDLC connection. (Refer to Appendix D)
Arguments: This would involve hiring a person to design a custom PCB to
meet our needs as well as paying to have the circuit boards manufactured.
The time of manufacturing would not take very long, but the price would be
around $350 for a quantity of 10 two layer PCB’s of 30 sq. in as quoted on
http://www.pcbsvcs.com/main.html. (Refer to Appendix D for referenced
price list) The task that would have taken the most time would have been the
actual design of the special PCB for connecting to the coldfire board,
however, I could not find any information on the rates for circuit board
design. Despite its drawbacks, this would be the best way to go for future
projects using this board, but because of current time constraints, lack of PCB
design knowledge, and possible cost constraints implementing this procedure
would have been difficult.

Modify double row 40 pin connectors that came with M-Core kit.
Arguments: The first question that might come to mind is why not use a 80
pin connector instead of the M-Core kit connectors? The answer is that no
such connector containing 80 pin connections exists. Using the M-Core kit
connectors would require us to damage two M-Core connectors. The
connectors as is do not fit into the Samtec slot on the coldfire board. We
- 24 -
would need to file off the sides in order to get them to fit in. Another problem
that arises is that the ribbon cables are not held on to the connectors properly
after being modified; thus, we run the risk of having the cable separate form
the connection ends if we are not careful. The demo board that is included in
the M-Core kit allows us to access the lines running through the ribbon cable
easily.
Selected Course of Implementation:
The modification of the M-Core connectors and the accompanying demo board are
sufficient for building our prototype. The best possible solution would be to mount the
Samtec connectors on to a custom PCB, but that would require more time and resources
than we can spare. For our purposes, we decided to use the M-Core connectors and its
accompanying demo-board.
Solution Implementation:
The two M-Core connections were fitted into connection J1 on the coldfire board, and
one M-Core connection was fitted on to connection J2 to give us access to the first 40
pins of connection J2. The open end of the M-Core connections had wire pins inserted
into each individual pinhole of the M-Core connection. The open ends of the wires were
then individually wire wrapped to a double sided pin array mounted on a breadboard in
order to provide easy access to their corresponding data, address, or control lines on the
coldfire board.
Coldfire Board
J1
J2
Accessing Pins
1-80 on J1
Accessing Pins
1-40 on J2
Coldfire Board
Lines available for
wire wrapping.
- 25 -
Figure 22. Accessing Board Connectors
Testing Bus Interface:
Testing bus interface consisted of a simple continuity test between the lines on the
coldfire board and its corresponding connection on the bread board.
- 26 -
Chapter 8: Low Level System Software
System Initialization
There is an elaborate setup required to boot the processor, and because PDACSII does
not run an operating system, we were required to perform these functions ourselves. Poor
documentation caused this to be a long and slow process. The first task is to set up the
memory space so that we can access external devices. The chip select initialization code
sets the LCD at address $40000000-$4000FFFF with autoacknowledged transfers using
chip select 3. The A/D converter is set at address $50000000-$5000FFFF also with
autoacknowledged transfers but using chip select 1.
The next initialization function is an assembly routine that creates a copy of the vector
table at $30000000, fills it default handlers, changes the vector base pointer (VBR) to
point to it, and puts the processor into supervisor mode. The assembly function then calls
a C function that places the address of each interrupt service routine (ISR) for the timer,
A/D, and button into the vector table. The Pin Address Register (PAR) is programmed to
set the 3 external interrupt lines to be non-encoded. The function also programs the
appropriate Interrupt Control Registers (ICR’s) to be autovectored. The Interrupt Mode
Register (IMR) is then set to enable only the interrupts needed.
Timer and LCD Programming
Once a device has a memory space, interrupt request line, and ISR associated with it, its
individual initialization routine can be run. The timer is programmed by writing to its
control registers. The countdown reference number and clock source are set which
determine the frequency of the timer events. The LCD initialization was fairly
straightforward due to the excellent documentation of the API. The LCD is set to 4-bit
mode and then a series of initialization commands are run to put the display in a known
state.
Interrupt Service Routines
The interrupt service routines are fairly straightforward. The most complicated issue was
linking assembly with C using the Green Hills compiler. We required assembly because
there was no keyword recognized by the compiler to specify that the routine was an ISR
and that an RTE instruction must be executed on exiting. The ISR’s consist of assembly
wrapper functions that immediately call C functions to service the interrupt. When the C
function returns, the wrapper functions then issue an RTE instruction and the program
returns to normal execution.
The key press ISR just sets a global variable that is checked in the main function to
control execution. The timer interrupt simply outputs “timer” but would eventually have
been used to send data to the D/A converter at regular intervals. The A/D converter reads
data and stores it in a buffer it the external DRAM. Every 2048 samples (approximately
4 times a second) a flag is set which tells the main function to output the current A/D
value to the LCD as a waveform.
- 27 -
Interfacing Devices
Three devices are integrated with the Coldfire board: a button, a LCD, and an A/D
Converter. The button runs through an FPGA debounce circuit and is connected to
IRQ1* pin of the processor. It is used to control the flow of the program code. The LCD
is connected to the GPIO lines, which are activated by chip select 3 CS3*. The A/D
converter is wired to the CPU as shown in Figure 23. An 8MB ADRAM was also added
to the board to store samples. Adding the RAM simply involved plugging it in and
accessing the correct memory address.
5206e
A/D
Converter
DATA
CPU
CS1
CSRD
WE1
WR
IRQ4
INTR
Figure 23. A/D Converter Interface
- 28 -
Chapter 9: Technical Problems
Problems with Development Board
The M-Core evaluation board did not provide us with a means of accessing the data and
address lines from off the board. Consequently, we selected the 5206eLite Coldfire
board for our project. The Coldfire board presented us with similar problems when we
couldn’t find a ribbon cable or demo-board to access the data, address, and control lines
from the Coldfire board. However, with some minor modifications of the M-Core
equipment we believe that issue has been resolved.
Software Development Environment
Our initial software environment Metrowerks was adequate for compiling, but the
parallel interface for downloading and debugging code had major bugs which would
cause the Metrowerks environment to crash. Using the serial interface in conjunction
with the debug monitor on the Coldfire was too slow of a method for testing and
debugging our code. We did obtain a license for another development environment from
Green Hill. The Green Hill environment did allow us to use the parallel debugger. The
Green Hill development environment was not very intuitive and was difficult to figure
out, yet because we were able to use the parallel debugger, it became our choice for
developing our software in. Other development software, which was tested and rejected,
included the Microtec X-RAY and Diab Data Compilers. The X-RAY compiler required
learning a complicated scripting language to allow the build process to work. It also did
not work well with Windows NT. The Diab Data seemed like a decent environment and
was well recommended. The problem for us was that the license support people would
never return our emails.
Noise and Interference
Near the end of the semester we ran in to countless problems with noise and interference.
When trying to interface multiple devices to the Coldfire board, they would interfere with
each other. We used a discrete inverter chip on the breadboard to invert the R/W- line
that ran to the A/D converter. This chip caused a huge amount of noise, which we
observed with the Oscilloscope. The 16-key keypad was also causing errors so we used
the buttons on the FPGA demo board for input and replaced the inverter chip with logic
inside the FPGA. Replacing the faulty components solved those isolated problems but
we are still getting random errors that we believe are being caused by noise from the
improvised bus connectors. The chip select lines and internal CPU lines are being
randomly set active which is causing spurious output on the LCD and random CPU
exceptions. The board could also be going bad because the same things that used to work
a week ago are not working now even though we have unwired all components we
believed were causing problems.
Problems Encountered in the Audio Subsystem
Building the A/D and D/A subsystems proved to be a very difficult and frustrating task, it
seemed that as soon as one problem was corrected another arose. Had the D/A subsystem
worked correctly for any extended period of time it would have been possible to test it by
- 29 -
connecting it directly to the A/D subsystem. With this configuration both the A/D and
D/A subsystems could have been tested and improved upon before final integration of the
project. The subsystems had at one time worked correctly by themselves, as had other
portions of the project, but integration of all the parts of the project proved to be very
difficult. Numerous problems arose throughout the semester that prevented the Audio
subsystem from working correctly. Some of the major problems include: failure to obtain
signal from microphone, A/D converter overheating, D/A converter failing numerous
times, in addition to countless other problems because of a general lack of predictability
with the electrical components. A great deal of valuable information was learned from
experimenting with the various components of the Audio subsystem that could not be
learned on paper, or in a near perfect environment, like that in the electrical engineering
courses and labwork. Many of the problems were not difficult to resolve once a general
knowledge of the component was gained, but since these problems had never been
encountered before (by us) they proved to consume a great deal of time and effort, and
had a detrimental effect on the progress of the project.
- 30 -
Conclusion
This project was a positive learning experience for our group. We got a first hand look at
the complexities of developing an embedded system. Even though we didn’t meet our
proposed goals we reached several milestones on the 5205eLite platform.





Parallel Communication through the GPIO
Interfacing the LCD with the 5206eLite
Interfacing the Development environment through parallel debugger.
Generating and handling timer interrupts as well as handling external interrupts.
We also generally successfully implemented our subsystems independently of the
5206eLite.
In order to simplify any future projects on the 5206eLite we suggest a PCB be designed
for accessing the bus lines on connections J1 and J2. We recommend the addition of a
PI/T, which would require only one chip select and some minimal software work, but it
would provide the user with two 16-bit bi-directional ports.
Additional Projects for the Future:
 Finish PDACSII once the above mentioned enhancements have been made.
 Load a RTOS on board and control a robot from it.
 Serial communication between boards.
 Interface A/D for reading temperatures using thermistors.
 Interface board with a hard disk.
 Create remote mini-weather reading station.
 Create symbolic calculator.
 USB interface.
The 5206eLite board has plenty of capabilities, but it has bad interfaces and bad
documentation. One instance of this was that the pinouts represented for J1 and J2 are
misleading and imply that the pins are number like a standard IC pinout with pins 1—40
on the bottom row and 80—41 on the top row. In actuality the pins are laid out with odd
numbered pins on the top row and their following even counterpart on the bottom row.
Most of the development environments written for this board don’t run very reliably on
MS Windows NT.
- 31 -
References:
Arrow Electronics - www.arrow.com/suppliers/intel
Atmel - www.atmel.com
Intel – www.intel.com (flash memory)
PDACS www.cs.tamu.edu/course-info/cpsc483/common/99a/g5/g5.html
MMC2001 specs www.mot.com/SPS/MCORE/products_mmc2001.htm
MMCEVB1201 specs www.mot.com/SPS/MCORE/products_mmc2001_devkit.htm
Mouser electronics – www.mouser.com/manufacturers (LCD cost)
PDACS – www.cs.tamu.edu/course-info/cpsc483/common/99a/g5/g5.html
National Semiconductors – www.national.com
Texas Instruments – www.ti.com
Phillips Semiconductors Homepage - www.philipslogic.com/
Linear Technologies Homepage – www.linear-tech.com
Motoraola 68k/Coldfire Homepage – www.mot.com/coldfire
Coldfire Discussion List – www.wildrice.com/coldfire
Pohlmann, Ken C., Principles of Digital Audio, Howard W. Sams & Co., Inc. 1985
Watkinson, John, The Art of Digital Audio, Butterworth-Heinemann Ltd. 1994
Sedra, Adel S. & Kennith C. Smith, Microelectronic Circuits, Oxford University Press
1991
Yip and Rao, Discrete Cosine Transform: Algorithms, Advantages, & Applications
- 32 -