making a delay unit out of RAM chips...

[Peter Snowberg]

to make the transition quickly and easily from cheap delta-sigma A/D to parallel and back to serial for the D/A,

No need to do that at all. Since we're practically drowning in RAM these days, either use a Nx1 DRAM, or only use one bit of a wider RAM. That's the point of using serial in/out ADAs - it makes the delay easy, and gets the controller and any glue logic out of the signal path entirely. That's one good reason for using sigma/delta - it's inherently a serial conversion technology.

But R.G...... above you we mentioning the difficulty of getting a PIC to do this task. :?

I should add that if I had found a cheap, easy to use sigma/delta ADA or a simple serial output/input ADA, or a simple, fast way to get the address counting done in a PIC, we'd already have delays made from a PIC, an ADA and a single-bit memory chip running out our ears. It's not because I haven't looked.

I just posted the way using four 74HCT299s and an HEF4040 to get a 16 bit delay memory. If you don't want to do the SIPO & PISO conversions, you raise the speed requirement of the PIC by 64 times!  :shock:  :wink:  That's why you haven't seen what you're looking for.

Availability of random RAM chips isn't a problem.... it's availability of processor cycles on a cheap microcontroller.

If you want to go the shift register route (@48KHz - typical stereo codec)  the PIC needs to complete 96,000 RAM access cycles per second. Not a problem at all. If you want to stick with a 1 bit memory you raise the requirement to 6,144,000 accesses per second and no PIC can handle that. Period.

I like having no glue or M2 (Mickey Mouse) logic, but it isn't realistic here.

Much of the reason for using serial interfaces on CODECs:
- Smaller (& cheaper) IC packages
- Smaller layouts
- Clock noise is primarily at the bit clock frequency, not the word clock (sample rate) frequency
- you can even get chips(!)

That TLV320AIC23 is interesting, but it's in TSSOP or BGA packaging. I'll do TSSOP, but BGA is beyond my (or any DIY) production capacity. There are tons of CODECs available and they all speak with just about the same interface language. The trick is finding ones that you can actually buy that will be available 6 months from now.

A couple years back I was working with lots of CODECs from Crystal but they never had any to see for production because they were all ending up in PC sound cards and they were on allocation. The Rep said, "Imagine you build shovels and the gold rush just started."

what would you prefer for reading (delaying) backwards purposes:

serial or parallell data?

Serial & DSP.

Anything less will click. :|

[puretube]

....

[Peter Snowberg]

Nice smiley Ton.

I went through the above scenario a little more and decided that the approach using 2 x 74HCT164, 2 x 74HCT165, and 2 x 74HCT574 with a 4040 for timing and one piece of off-the-shelf glue logic would be the way that actually worked.

I think that by far the best way to use a PIC in a delay these days is to use a dsPIC30F5011/5013 and a serial CODEC with a big 16 bit wide SRAM.

The dsPIC above is ~$11 in "quantity", the CODEC is cheap, and the SRAM is cheap too.

The dsPIC changes everything!    

[puretube]

he he he: actually the smileys should illustrate a BBD...
but this was the 1st thread I found conc. delay...
(well, it`s a kinda like a FIFO as well)  




ps: found them on Colin`s new "anonymous" board  :wink:
(btw, Colin: I`ve been to that emoticon page once, and that directly tripled my spam.....)

[Peter Snowberg]

I got the BBD reference right away.

No passives (mounted on both sides and a mix of SMD & through hole) shown, but here's something to ponder.