Pages: 1 2 [3]   Go Down
Author Topic: Need some advice on a multi-chip project  (Read 3653 times)
0 Members and 1 Guest are viewing this topic.
Global Moderator
Boston area, metrowest
Online Online
Brattain Member
*****
Karma: 524
Posts: 26454
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

"Is "just because I want to try it" still an acceptable answer?"

Works for me.
Logged

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 474
Posts: 18696
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

What is "this" exactly? 

Routing a single clock to multiple chips. As in, the master chip clock, not something like an SPI clock.

Quote
  I assume it's not under question that a DAC needs a clock?  So, if you have more than one DAC, and signal coherency is a requirement (e.g., 5.1 audio), you would want those clocks to be from the same source.

I would be doubting it would matter. Just looking at a DAC I happen to have here (MCP4922) there isn't a clock input, so the question doesn't arise. Plus the processor clock timing (eg. 16 MHz) is so much higher than audio (eg. 25 kHz) that if the clocks were about by half a clock cycle (ie. 31.25 nS) I doubt you would notice it.

Quote
Is "just because I want to try it" still an acceptable answer?

Sure, go ahead.
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 124
Posts: 6651
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

16MHz isn't that fast.  Other systems manage to route clocks faster than 16MHz over longer distances.
(On a related note, I'm not sure why we all seem so confident about sending that 8MHz SPI clock all over, if we're really worried that 16MHz would be such a problem...)
Logged

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 474
Posts: 18696
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

True, but we tend to keep SPI interfaces short. I've had them fail with longer wire runs.

But in principle, what you say is right. You could always clock the processor at 8 MHz, so there shouldn't be much difference. smiley
Logged

SE USA
Offline Offline
Faraday Member
**
Karma: 41
Posts: 3783
@ssh0le
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I was not that confident, but the more interesting this is how far are we talking about

thats the thing what exactly are we talking about, bell wire strung in between who knows what devices with sticky tape on the wall?

that is a grossly exaggerated vision of what I had

so maybe some clarification is needed?

and yea we string higher speed signals all over the place all the time, but its typically not the core clock of a remote device, heck I dont even know what happens if an avr gets a wonky clock, double beats, skips or gibberish on its clock lines
Logged


Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
  I assume it's not under question that a DAC needs a clock?  So, if you have more than one DAC, and signal coherency is a requirement (e.g., 5.1 audio), you would want those clocks to be from the same source.

I would be doubting it would matter. Just looking at a DAC I happen to have here (MCP4922) there isn't a clock input, so the question doesn't arise. Plus the processor clock timing (eg. 16 MHz) is so much higher than audio (eg. 25 kHz) that if the clocks were about by half a clock cycle (ie. 31.25 nS) I doubt you would notice it.

I'm just getting into this whole world, but I've found that many (audio) DACs require a clock that is several times the audio sampling rate.  For instance, i2s is going to interleave the samples (which may be up to 32-bit for float, or often 32-bit aligned for 20- or 24-bit int) for each channel (which could be one to xx) that all need to arrive in time to be one "frame" of audio.  For stereo PCM DVD audio tracks, that's 1.536Mb/s  (48,000 * 2 channels * 16 bits).

One particular example I found is an older IC that has onboard hardware decoding of AC3 and DTS, before they all required licensing keys from a bootstrap or EEPROM chip.  It has three such i2s streams -- one for L/R, one for surround L/R, one for C/SW.  They're meant to synchronize from a serial clock at at least 2x the i2s data rate.  Letting them freewheel from separate clocks would surely introduce buffer under/overruns, or rather sample window errors.  The decoder itself will PLL from SPDIF or certain digital inputs, but I don't think you can do that on i2s -- it's not phase-modulated, just TTL.  You could conceivably have long stretches of the same digit, and the clock recovery would slip.

This is all how I understand it, anyway.  I could be wrong about any or all of it.

16MHz isn't that fast.  Other systems manage to route clocks faster than 16MHz over longer distances.
(On a related note, I'm not sure why we all seem so confident about sending that 8MHz SPI clock all over, if we're really worried that 16MHz would be such a problem...)

Yeah... baby steps.  I know if I have problems with this design, I have to work on my layout skills before I should ever attempt anything faster or more timing-critical.

Before I started this thread, the oscillator was just three components on the board, in the center of the bottom row of AVR pins.  I didn't even really know what an oscillator waveform looked like, what voltage level it should be at, whether it was an AC swing around 0v or TTL .. so on, so forth.  After some research, I have a better idea how it works now, and hopefully soon it'll be second nature.
Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I was not that confident, but the more interesting this is how far are we talking about

thats the thing what exactly are we talking about, bell wire strung in between who knows what devices with sticky tape on the wall?

that is a grossly exaggerated vision of what I had

so maybe some clarification is needed?

and yea we string higher speed signals all over the place all the time, but its typically not the core clock of a remote device, heck I dont even know what happens if an avr gets a wonky clock, double beats, skips or gibberish on its clock lines

Maybe that's where I wasn't being clear...  OK, that's simple enough.  Here's the engineering description of the device itself, which of course is conceived as a learning experiment that happens to do something useful once complete:

The device will be a single-board gadget with (probably) an ATmega1284 as the master processor.  This chip will coordinate transfers, provide a user interface via its own console port (RS-232 9-pin D-sub) via a MAX232 level shifting IC, and manage up to four telnet sessions via a WizNet module based on the W5100 IP stack and Ethernet interface IC.

Four slave processors (likely ATtiny2313s) will provide interfaces via their own MAX232s to downstream serial ports terminated on RJ45 jacks.  They will communicate via control pins and an 8-bit parallel data bus with the host processor and the WizNet IC.  (The ATtiny will transfer only data to the WizNet; all addressing and controlling will be performed by the host processor.)

A single master clock will be generated with an approx. 18MHz crystal oscillator (an even multiple of common serial baud rates), which is energized by an unbuffered inverter circuit (link on first page), then (presumably) buffered and distributed in a daisy-chain to the AVR processors, and finally to a termination resistor.

An initial proof-of-concept will hopefully be capable of running on a breadboard, but the final project will be a custom PCB design.  (Maybe SMT... we'll see.)  A 3D-printed case is likely.  There will be no stringing of wires, with the exception of Ethernet, RS-232, and power.  smiley-lol
Logged

SE USA
Offline Offline
Faraday Member
**
Karma: 41
Posts: 3783
@ssh0le
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

OH!

see I was reading 4 remote pod's at the back of each device, feeding back X distance to a central location (though like a twisted pair connection)

your running RS232 to a central location and the rest is on board

well dang dude, you can do that on perf board if you keep your signal lines from being in parallel or crossing other lines at 90degrees

I think the worst your going to have is messing with the arduino stuff to work at 18Mhz, but even at 16Mhz the very slight offset doesnt really effect anything, I have an apple II with some asm magic gets up to slightly under 115,200, and a avr board at 16Mhz slightly above 115,200 and they never have issues talking to eachother (I would know its a hard disk over serial emulator)
« Last Edit: August 30, 2013, 07:52:26 pm by Osgeld » Logged


Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hard disk over serial!  That's awesome.  I heard someone created something similar to mount C64 images from SD cards (or something like that).

No concern with Arduino code, this will be vanilla AVR C++, C, and/or assembly if I feel saucy.  I love Arduino, and the community is absolutely the best, but I use it as more of a sketching tool.  Too much baggage for my taste in a "real" project.
Logged

SE USA
Offline Offline
Faraday Member
**
Karma: 41
Posts: 3783
@ssh0le
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Too much baggage for my taste in a "real" project.

I flip flop personally, if I can do it in arduino I will, its syntax is so much simpler, if I need hard core raw bit twiddin then yea arduino is the first to go.

oddly enough I have rarely really needed the speed to ditch arduino's simpleness(A I be lazy, B I dont have the time when its already there and I can pass a framework off to an intern!) , but its good to know multiple paths, including other systems like TI's msp or PIC's, FPGA, or a cypress PSoC (which is a mcu and a clpd in a single chip in 8 bit, 16 bit 8051, and 32 bit ARM flavors)

let you pick your tools, rather than your tools pick your brain
« Last Edit: August 30, 2013, 08:44:08 pm by Osgeld » Logged


Pages: 1 2 [3]   Go Up
Jump to: