Alan G. Smith wrote: >I am looking at a project which needs to transmit some information >verbally. ... Mike Keitz answered: ... > It's also possible to store the voice data samples in digital form > in a large EPROM or flash EEPROM. This may be better for > production since standard digital programmers can be used. A > 4M-bit device will store about 64 seconds of 8-bit/8KHz samples > with no compression. The PIC could do some simple decompression > like ADPCM. Using a parallel memory chip, you'd need extra address > latches or counters. This seems like an ideal application for the > big serial flash chips rumored to exist. You'll also need to > convert the data to analog, using a resistor tree, PWM, or a codec. > The codec will have the best quality, as it could process the > samples u-law for better dynamic range. Also it integrates a > low-pass filter into the chip. I have played with that idea before. I agree with your calculation, a 4Mbit memory stores 64 sec of 8bit/8kHz samples. Let's go more into detail and possible implementations: 1) parallel EPROM + resistor ladder: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This solution implies the least software overhead by connecting a 'classic' parallel EPROM or flash to your PIC and doing the D/A conversion by a resistor ladder. Disadvantage: A lot of I/O-Pins are used. 2) parallel EPROM + PWM: ~~~~~~~~~~~~~~~~~~~~~~~~ If you choose a PIC with a CCP-Module, you can use the PWM as D/A converter, advantage: only 1 pin for the output. Select a PWM frequency high enough to be inaudible and a multiple of your Sampling rate. E. g.: 8kHz sampling rate, 16 kHz PWM-rate. 3) serial EPROM + PWM: ~~~~~~~~~~~~~~~~~~~~~~ Obviously this cuts the pin-demand drastically. But the software is working hard now. Assume a lot of support by the PIC: a I2C-Module and a PWM. For reading 1 byte from a serial EPROM or Flash you have to send about 7 bytes of adress data to the EPROM first, then read your data byte. This is 8 bytes * 8bit/byte = 64 bit data exchange between PIC and EPROM. With 8 kHz sampling rate this is 64 bit * 8000 Hz = 512 kbit / second. This is a quite fast I2C Communication speed! Really challenging to implement the I2C routine in software on a PIC. 4) more features: ~~~~~~~~~~~~~~~~~ The Analog output has to be low pass filtered (interpolation filter) with a cutoff at 1/2 the sampling rate. It must suppress the sampling rate frequency (8 kHz in this example) good enough to be inaudible. Therefore we might consider raising the sampling rate to 16 kHz, which most people don't hear very good, if at all. Then we can design the LPF easier (just one or two RCs) or omit it completely. The tradeoff obviously a doubled data transfer. Using the above example it is 1 Mbit/second. I had an application in mind where I needed an output of two independent channels, e. g. channel 1 with background music, channel 2 with spoken announcements. This doubles data transfer again to 2 Mbit/second. All serial Flashes I know support continuous reading of consecutive data bytes. So as you read your sample data always one byte after the other, you needn't send the address to the Flash every time, just read one byte after another. This reduces the 64 bit/sample down to 8 bit/sample of data transfer. Unfortunately this doesn't work for my preferred two-channel reproduction, as both channel data is stored at different addresses. But at least a read-ahead-cash can be implemented in the PIC. So let's assume a data volume of 1 Mbit/second or 128 kbyte/s between PIC and serial Flash. With a PIC oscillating at 20 MHz this is 1 byte every 40 instruction. So the PIC is quite busy with setting up I2C, updating address bytes to be sent, and caching data received! Now you want to implement some "simple decompression like ADPCM"? Well, there exists a Microchip Appnote about ADPCM implementation, where they have implemented a simplified ADPCM method based only on integer arithmetics. If I remember correctly, a 20 MHz PIC was really busy to decode a 4 kHz (or 8 kHz, I don't know any more) ADPCM signal. After all the above, do you think you have enough time for decompression? The summary: If you want to store audio in an external serial Flash, you should look for a PIC with hardware I2C and hardware PWM. ADPCM is probably too complicated to implement. Maybe an AVR with 4 times the speed of a PIC and hardware support can do my favourite 16kHz 2-Channel audio reproduction at low voltages (3.3V), maybe a Scenix is fast enough to run a "virtual hardware" 2 Mbit/s I2C master with a 16 kHz 9bit PWM output? maybe PICs speed up to 33 Mhz at 3.3 V supply voltage? Any comments to reduce the necessary processor performance are greatly appreciated! ------------------------------------------------- Siegfried Grob School of Electronic and Electrical Engineering University of Leeds Institute of Integrated Information Systems Woodhouse Lane Leeds LS2 9JT fax: +44-113-233-2032 e-mail: siegfried.grob@student.uni-ulm.de or: eensrg@electeng.leeds.ac.uk