Portable Digital Audio Codec System II

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. D/A Converter Manual

· C. A/D Converter Manual

· D. Selected Component Pricing

· E. National Instrument DAQ Board Pinouts

· F. Excerpts form 5206e Programmers Reference Manual

· G. PDACSII Source Code

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.

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 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.

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

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.

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.

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.

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 8-bits 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:

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.

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.