On Fri, 10 Oct 1997 14:04:55 BST "Grob, Siegfried" writes: >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. >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. > Operating directly, there'd be 19 address inputs to the EPROM. If you connect the 12 low-order addresses to a 74HC4040 12-bit binary counter and the 7 high addresses to a shift register, then there's only 3 or 4 PIC pins required to control the counter and the shift register. This setup segments the voice data into 128 blocks of 4096 samples (about 0.5 seconds) each. During playback, the PIC would only need to clock the counter at the sample rate, unless a word spans over multiple blocks. Then the shift register would need to be adjusted. The multiple blocks in the word could be located so only one shift of the register is needed to go to the next one. The output from the DAC would have glitches of a few hundred ns (out of the 125 us sample frame) at the start of each new sample. These should largely disappear in the analog filter. This approach looks best for when price is more important than sound quality. >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. It would be nice to have more than 8 bits of PWM resolution, so the data in the EPROM could be stored in ulaw format then outputted linearly. But getting just 8 bits pushes the PIC about to the limit. Oversampling the data before converting it (such as by making interpolations of the data and outputting at 16 KHz) should reduce the energy in the 4-8KHz range in the output and make the analog filter's job easier. Though there's only one output pin, more pins would be required to route the EPROM data back into the PIC, which isn't necessary if an external DAC is used. > >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. You say later that the ROMs will output constantly once started with just clock pulses. So the PIC only needs to generate 8 clock pulses per sample, it has about 15 instructions per clock pulse running at 4 MHz xtal (a 4 MHz xtal will not be fast enough to make the PWM work though). Starting in a new place would take longer, but this would be between words where the pause wouldn't be noticed. > >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. Use a codec chip, which contains a ulaw DAC with serial input, and a good analog filter (as well as another analog filter and a ADC, which won't be used in this project). It should be possible to have the codec take data directly from the serial flash ROM, thus the PIC only need to generate clock and control pulses. >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. Consider using two memory chips for this. Then they can operate independently of each other, and the extra space will probably be needed anyway. The two outputs could be "mixed" by binary addition for a single DAC, or use two analog channels. It should also be noted that music does not sound very impressive at 8 KHz sample rate and 8 bits per sample. > >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... Being able tor read consecutive bytes is still very useful in "2-channel" operation, since once the address is set up a block of maybe 32 or 64 samples can be read rapidly into PIC RAM. The PIC would need enough RAM for two such blocks. While one is being prepared (by reading two places from the EPROM and adding together), the other one would be playing to the DAC hardware. For each block of 64 (combined) samples to be played, two address sets and 128 byte reads would be required. Continuous play would require clocking the EPROM at about 144 KHz.