> Hi Guys,
> I wonder if this is a good way to sample PCM sound (8KHz, 8bit).
> I have a 24LC64 full with 8kbytes of raw 8 bit unsigned data taken
> from audacity (i recorded myself saying a word).
> I am using Microchip AN991's way of accessing I2C eeproms and
> it works. The problem is i am not geting what i expect : sound.
> I only get some clicks and that's it.
> I am doing the folowing :
>  - i read a byte from eeprom
>  - i output it to PortB
>  - i wait 2500 cycles (the clock is 20MHz and dividing this by
>     8000 i get 2500)
>  - i increment the address for eeprom
> ....and so on....
> On PortB i have a R-2R simple DAC and then a simple speaker
> driven by a common-collector 2n2222 transistor.
> This is the code i was talking about :
>
> while (1) {
>        ControlByte = 0xA0;
>        HDByteReadI2C(ControlByte, HighAdd, LowAdd, &Data, Length) ;        //High
> Density Byte Read
>        PORTB = Data;
>        Delay1KTCYx(2);
>        Delay100TCYx(5);                //2500 cycles delay (for 8khz)
>        LowAdd++;
>        if (LowAdd == 0) {
>                HighAdd++;
>                if (HighAdd > 0x5F) HighAdd = 0x40;
>        }
> }

> Hi Guys,
> I wonder if this is a good way to sample PCM sound (8KHz, 8bit).
> I have a 24LC64 full with 8kbytes of raw 8 bit unsigned data taken
> from audacity (i recorded myself saying a word).
> I am using Microchip AN991's way of accessing I2C eeproms and
> it works. The problem is i am not geting what i expect : sound.
> I only get some clicks and that's it.
> I am doing the folowing :
>  - i read a byte from eeprom
>  - i output it to PortB
>  - i wait 2500 cycles (the clock is 20MHz and dividing this by
>     8000 i get 2500)
>  - i increment the address for eeprom
> ....and so on....
> On PortB i have a R-2R simple DAC and then a simple speaker
> driven by a common-collector 2n2222 transistor.
> This is the code i was talking about :
>
> while (1) {
>        ControlByte = 0xA0;
>        HDByteReadI2C(ControlByte, HighAdd, LowAdd, &Data, Length) ;        //High
> Density Byte Read
>        PORTB = Data;
>        Delay1KTCYx(2);
>        Delay100TCYx(5);                //2500 cycles delay (for 8khz)
>        LowAdd++;
>        if (LowAdd == 0) {
>                HighAdd++;
>                if (HighAdd > 0x5F) HighAdd = 0x40;
>        }
> }

> On Dec 12, 2007 8:37 PM, Hector Martin <EraseMEhectorspam_OUTTakeThisOuTmarcansoft.com> wrote:
>
>>Note that PIC16s and PIC18s internally divide the clock by 4, so the
>>delay would be 625 cycles. Also, the I2C read will take some time. Your
>>best bet for timing is to use one of the PIC's built in timers. In fact,
>>if you're running your EEPROM at 100Khz, it will be too slow since you
>>have to read/write 4 bytes = 40 bits approximately (after adding in
>>start conditions and whatnot), so your maximum sampling rate would be
>>100/40 = 2.5Khz. You should read chunks of data of a longer length (to
>>reduce the overhead of three bytes for each I2C transaction), buffer
>>them in memory, and have an interrupt running off a timer put them into
>>PORTB.
>
>
> In the end i will use two buffers and a timer for feeding my DAC with values
> but this is my first work in this field and i wanted to hear some sound out
> of my design :) Thank you for your correction, i will fix my delays now to see
> what i get.

>
>
>
> Dumitru Stama wrote:
>
> > On Dec 12, 2007 8:37 PM, Hector Martin <@spam@hectorKILLspammarcansoft.com> wrote:
> >
> >>Note that PIC16s and PIC18s internally divide the clock by 4, so the
> >>delay would be 625 cycles. Also, the I2C read will take some time. Your
> >>best bet for timing is to use one of the PIC's built in timers. In fact,
> >>if you're running your EEPROM at 100Khz, it will be too slow since you
> >>have to read/write 4 bytes = 40 bits approximately (after adding in
> >>start conditions and whatnot), so your maximum sampling rate would be
> >>100/40 = 2.5Khz. You should read chunks of data of a longer length (to
> >>reduce the overhead of three bytes for each I2C transaction), buffer
> >>them in memory, and have an interrupt running off a timer put them into
> >>PORTB.
> >
> >
> > In the end i will use two buffers and a timer for feeding my DAC with values
> > but this is my first work in this field and i wanted to hear some sound out
> > of my design :) Thank you for your correction, i will fix my delays now to see
> > what i get.
>
> So break the problem into parts.
> First make the D/A make sound. A running binary counter will
> get you a nice ramp (sawtooth) that sounds like an Oboe.
> That way you know your playback rate is OK and that your amplifier
> is not clipping or otherwise wonky.
>
> Then make sure you are reading/writing the EEPROM correctly.
> For example, write the compliment of the address
> (plus some offset),to each location
> and then make sure you are reliably getting it back.
>
> And as noted by others, you only need to write the start address
> to most serial EEPROM devices. Subsequent reads will get you
> the next byte in the sequence so your overhead is greatly reduced.
>
> Robert
>
>
>

> On Wed, 23 Jan 2008 16:39:02 +0200
> "Dumitru Stama" <spamBeGonespanacspamBeGonegmail.com> wrote:
>
> > This is almost the value I should get by sending "250" to the DAC but
> > instead I get 2.35,
> > almost half of what it should be. Am i right here ?
>
> I'm guessing you are not connecting to the correct node of the R/2R
> network. 10k/20k should work well with the PIC outputs. Note that there
> are two different applications for R/2R: One uses an opamp at the output
> and works with currents
> (http://www.allaboutcircuits.com/vol_4/chpt_13/3.html)
> the other one is designed for volrages
> (http://www.avr-asm-tutorial.net/avr_en/AVR_DAC.html - note that the
> opamp here is only as a voltage follower, not current to voltage
> converter).
>
> John
> --

> On Jan 24, 2008 3:49 AM, John Coppens <RemoveMEjohnspam_OUTKILLspamjcoppens.com> wrote:
> > On Thu, 24 Jan 2008 01:01:13 +0200
> > "Dumitru Stama" <RemoveMEspanacTakeThisOuTspamgmail.com> wrote:
> >
> > > I think i will try to test the ladder using some jumper switches
> > > instead of PIC pins, this way at least i will know is not a "not enough
> > > current" issue.
> >
> > But that is very easy to discard as a problem... Simply put out all ones,
> > and measure the voltage in each output pin. It should be very near VCC.
> > If that's ok, DO check the configuration. If you have the one intended
> > for an Opamp amplifier (first link I sent), you cannot measure it without
> > the opamp functioning (the opamp is needed to present a short to the R/2R
> > network).
> > The second configuration is slightly different, and should not be loaded
> > at all (if you have an amplifier at the output, be sure it has its supply
> > connected, and that the input can handle the 0-VCC swing of the R/2R
> > (ie., don't supply it with VCC), else the inputs will load the network
> > and produce things like you describe.
> > John
>
> Do i really have to have an opamp functional to test the voltages ?
> I only have about 5v as VCC and it is a bit hard to supply the amp
> with enough juice. I have already sent 0xFF to PORTD and i have
> voltages close to VCC on every pin. I will try to build it again with
> 100k and 200k resistors and check the voltages step by step, after
> each part : 1bit, 2bits, ..... 8 bits.

> Vasile Surducan <piclist9STOPspamspam_OUTgmail.com> wrote:
> > Hand made R-2R ladder is the worst option ever for a DAC.
>
> Not necessarily ...
>
> > I hope you have read first the theory of R-2R D2A and the non linearities
> > you may get because of resistor unmatch.
>
> I'm with you so far ... although you can do pretty well with, say, 25 1%
> resistors of all the same value (from the same batch, if possible) to build
> an 8-bit converter.
>
> > Also the inequal output impedance with bit variation...
>
> Nope, dead wrong on that one. Assuming the bit drivers have negligiple
> resistance compared to R, The output impedance of an R-2R network is
> constant, and it's R! See the following link for details:
>
>  http://www.dtweed.com/circuitcellar/caj00100.htm#1532
>
> The PDF link works, but the HTML version has gone missing. The relevant
> text is on page 2, with diagrams on page 3.
>
> -- Dave Tweed
>