I've got a Texas Instruments PCM1804 analog to digital converter hooked up like so:
formatting link
However, It's in it's "bare minimum" configuration.. I've hooked up the analog and digital voltages, their grounds, set the clock configuration pins, and attached the crystal. When I put my volt meter between the overflow pins (OVFR and OVFL) and ground, I measure about 3 volts. If I place a small LED in place of that, it seems to randomly flicker and dim. I've done this with several PCM1804 chips and I seem to get the same result.
I've tried grounding and/or bringing the analog input pins and this still happens. Is this supposed to happen or am I doing something obvioulsly wrong.
Heh, I had forgotten the schematic symbol for a crystal. Fixed now.
Anyways, I don't have a scope, so I guess I'm stuck with a voltmeter. However, the fact that the overflow pins have enough current to drive an LED at full voltage concerns me because they should be low...
I haven't actually built anything with the pcm1804 yet, but have been pouring over the datasheets and EVM docs for a long time now trying to get familiar enough with the stuff (I'm a programmer dabbline in electronics, fairly successfully so far with a low-volume commercial design under my belt already).
AFAICT, you need to connect Vin+ and Vin- to Vcom for a given channel if you intend to get a zero signal. If you ground both pins, you'll get quite undefined results. Vin+ and Vin- are a differential pair around Vcom (2.5V nominal). That means that the voltage potential between Vin- and Vcom should be the same as Vcom and Vin+. If both Vin+ and Vin- are at ground, you've violated that rule.
Also, some decoupling caps as per the datasheet might help, if things are still oscillating badly.
As for the crystal, I'm pretty sure you can't do that. A crystal needs a driver circuit in order to oscillate, and you haven't provided one. Can't help you on how to build such a circuit, as my experience is limited to the XTALin/XTALout pins on things like ATmega's. However you might look at the PLL170x chips to get you where you need to be.
If I'm wrong, someone please correct me, like I said I'm effectively a newbie at this ;-)
Ok, just trying to check my understanding -- I need some sort of clock driver circuit, I cannot just hook the crystal up between the digital voltage and the system-clock pin?
In PIC microcontrollers, I've hooked the crystal directly up to the osc pins and it works just fine, is this because the PIC chips have a buit-in clock generator that uses the crystal to create the clock?
If so, what's the most minimal and/or practical way to go about creating the clock driver?
Thank you all for the input and trying to bear with me and my limited mixed signal processing knowledge.
The PCM1804 will operate in either slave or master mode. In slave mode you have to provide a bitclock that's at least 48x the sample rate (Fs), along with an LRCLK (left-right) that runs at at least the sample rate, syncronized with the bitclock. According to the datasheet you can run the bitclock up to 64xFs, and the mode bits determine the alignment of sample data within each LRCLK half-period. In master mode the PCM1804 drives the bitclock at 64xFs itself, and LRCLK accordingly.
The PLL170x series chips are nominally ideal for this purpose, as they take a single 27MHz crystal and can produce all the various frequencies needed for audio anywhere from 44.1KHz up to 192KHz with various oversampling multipliers.
This depends on which mode you're using the PCM1804 in. If you're driving multiple chips in slave mode, AFAICT you'll need to pay some attention to the reset sequence if you want them to be in sync. Otherwise you could just run the thing in master mode and let your uC manage as it can. Can't think of a really clean way of getting e.g. an AVR to align properly against LRCLK though. Would have to use an edge-triggered interrupt in order to prep the SPI interface to receive, but the bitclock is far too fast for that. A CPLD could be used to catch both edges of LRCLK and give you a 75% duty-cycle clock (relative to the bitclock) to feed the uC's SS# (24 of each 32 bitclocks low, twice per LRCLK period). Um, now I'm rambling....
What's got me half-stumped is how to take a 1xFs wordclock and sync e.g. a 256xFs to it. Obviously some PLL magic needed (4064, etc). But like I said earlier, I'm just a programmer dabbling in this stuff.
You're right. The fact that the OP hasn't supplied a clock source means that the chip won't function in any recognisable way.
In this kind of application the clock would typically be sourced from a master clock generator that also supplies a DSP chip. Or indeed the master clock generator may actually be on the DSP chip ( as in a design of mine ).
You're also right about biasing the diff IPs from Vcom but the OP hasn't shown us that bit.
I'm planning on using it in master mode, so syncronization with a PIC microcontroller (PIC18F4550) is going to be no problem. I'll look into intels AP-155 and the PLL170x series clock generators and report back.
How are you planning on syncing with the LRCLK? The PIC isn't fast enough to capture LRCLK edges and reset the SPI port. At 48MHz the PIC has an instruction rate of 12MHz. The 64xFs bitclock from the PCM1804 running at 48KHz will be 3.072MHz, giving you about 2 instructions to catch the edge and reset in time for the next bitclock edge. Unfortunately that's not possible, as a loop is going to have a max 3 instruction latency, plus at least 1 instruction to reset the SPI. Right-aligned output won't help you either because there's no good (accurate) way of waiting 8 bitclocks from the LRCLK edge before starting the SPI.
I've been planning on building a prototype audio capture board with a PCM1804 for quite a while now, and in a month or so will have more time to actually do so. In the meantime I hope to do some basic prep work like mounting the chips to DIP adapters (ExpressPCB-made) and gathering the necessary parts.
If you're interested in working together on building the ADC->USB section, we can probably make significantly faster progress. As you can tell I've already done a huge amount of research on the topic...
The PIC18F4450 does not appear to have anywhere near the USB bandwidth to handle the PCM1804, unfortunately. According to AN956, it has an effective max bandwidth of 80KB/sec, which is far short of the 288KB/sec required for 48KHz 24-bit stereo. My plan is to use the Dontronics FT245BM module hooked to an AVR (I don't do PICs anymore, the AVR is much more powerful) in parallel mode, which can do as much as 1MB/sec.
The best solution I can think of for dealing with the PCM1804 serial interface is to use a CPLD. My long-term plan is to use an FPGA to tie multiple PCM1804's together for a multichannel interface, so I've already learned enough Verilog to pull that off, AFAICT. A $2-4 CPLD in a PLCC package (meaning you can use through-hole sockets) would have plenty of logic capacity to handle converting the serial port into a parallel port, with the right clock sync and everything. I could probably bang out a design in a few hours. Either Xilinx or Altera parts could be used, though I'd probably lean towards Altera because their tools are easier to use. Cheaper too (see Digikey 544-1155-5-ND).
Anyway, email me if you're interested in working together on the various pieces of the design.
TTYL, Omega aka Erik Walthinsen snipped-for-privacy@Mpdxcolo.net
I had been planning on coding my own serial receiver into the PIC chip, rather than using the onboard interfaces. As for the USB speed, was that 80KB/s when operating as a HID device? (which is supposedly slower than if I were to define my own interface and code my own kernel mode driver).
I don't have the time at this moment to read the app note you pointed out, nor do I have the time to re-calculate some of my numbers but hopefully I'll get back and try to figgure this out. Thank you very much for helping me out here :)
I don't think that's likely to work. The PIC18F4550 at maximum speed will execute at 12MIPS. With 48KHz audio, you get a fraction less than
4 instructions to process every single bit. Every branch takes twice as long. You get zero idle time between bytes (OK if you unroll fully), but you're still going to have problems syncing with LRCLK. Left-aligned serial is required, but the datasheet implies (but does not give numbers for, sigh) that you've got 1 PIC instruction between LRCLK edge and where you're supposed to sample the first bit. A loop to look for the edge is going to take 3 instruction periods (test[1], jump[2]), which in the worst case would put you 180 degrees out of phase with the bitclock, right on the transition edge of the data bit.
Possibly, but I don't think you're going to get a 3.5+x improvement, while simultaneously spending 3/4 of all your cycles locked in a tight serial loop.
They only run at 16-20MHz, but they don't take 4 clocks per instruction. Gives a lot more headroom (12MIPS->20MIPS, 6.5 instructions per bitclock at 48KHz) to do a hand-written SPI loop, or use the onboard SPI but sync it with the LRCLK properly. A number of them have a parallel interface that should be glueless to a FT245BM chip. However, that means your protocol is a single RS-232 channel, ruling out an audio class device interface.
Actually with a CPLD doing serial->parallel conversion (or heck, even a discrete shift register), I'd also be tempted to use a Cypress AN2131, which is an 8051-based USB chip that can be had in TQFP-44 from Digikey for $10.53. Or, at $14.40, the EZ-USB FX2 (56-TSSOP) that I know for a fact can handle the bandwidth, being a 480Mbps USB chip. That's what I intend to use eventually to hook up multiple PCM1804's.
Graham, if you see this, I've sent you several emails but am not sure they got to you (no response yet), so if you see this please email me again. Maybe I'm dense and not catching an anti-spam trick in your address, or maybe something's getting blackholed somewhere... I'll try from my gmail address next, that *should* go anywhere
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.