daisy-chaining clocks

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On an ATmege168, is the output from CLKO suitable for clocking another ATmega168? If so, how far can it be extended? How can you tell?

The only documentation I can find says:
This mode is suitable when the chip clock is used to drive other circuits on the system.

It's not obvious that "other circuits" includes other AVRs.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CLKO is a standard AVR-output, and therefor quite powerfull. It will drive 10 AVR's without blinking an eye ;) So it depends on how far you want to push it :)

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Plons wrote:
CLKO is a standard AVR-output, and therefor quite powerfull. It will drive 10 AVR's without blinking an eye ;) So it depends on how far you want to push it :)
What about duty-cycle?

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The duty should see the same, but you will likely get a phase shift. How many times are you looking at chaining? As stated earlier, one CLKO can be used to drive many AVR's directly, so unless you are talking about having MANY AVR's on a single board, you shouldn't have to daisychan them.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
The duty should see the same, but you will likely get a phase shift. How many times are you looking at chaining? As stated earlier, one CLKO can be used to drive many AVR's directly, so unless you are talking about having MANY AVR's on a single board, you shouldn't have to daisychan them.
I think it's going to be a dozen. Neglecting a possible small change in duty cycle is not a good idea. It will be multiple identical "boards" connected to run at precisely the same frequency if not the same phase. We need to daisy-chain something.

Added:
From the documentation I can find, I can't tell that CLKO is even suitable for one AVR. If it will work, I need a source that those who are not me are willing to use for design work.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you're planning on runing the clock over a cable? If that's the case, you're likely going to find that the waveform is highly distorted at the other end, unless you use drivers designed for this. I would suggest having a clock board that generates the clock, and fans it out to each of your other boards. I would also suggest differential signalling for carrying the clock signals.

Another option, and it will be more like daisy chaining, will be to have a differential receiver and transmitter on each board. Have the CLKO run from the AVR to it's transmitter. On all the boards, except the master, the receiver drives the CLKI pin. (you can also have it drive the transmitter, to reduce phase and any duty distortion concerns)

Added, for your Added: ;)
It may not say it directly, but it is inferred. You can drive the CLKI pin from any logic level clock source. (if so selected by your fuses) The CLKO pin is a logic level clock source. Putting it together you get that you can drive one AVR's CLKI pin from the CLKO pin of another.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
you're planning on runing the clock over a cable?
No, but the design is to be periodic. That is why I put "boards" in quotes.
Quote:
Another option, and it will be more like daisy chaining, will be to have a differential receiver and transmitter on each board. Have the CLKO run from the AVR to it's transmitter. On all the boards, except the master, the receiver drives the CLKI pin. (you can also have it drive the transmitter, to reduce phase and any duty distortion concerns)
I suspect some thing like that is what we will end up with. It would be nice to do it directly through the AVRs.
Quote:
Added, for your Added: ;)
It may not say it directly, but it is inferred. You can drive the CLKI pin from any logic level clock source. (if so selected by your fuses) The CLKO pin is a logic level clock source. Putting it together you get that you can drive one AVR's CLKI pin from the CLKO pin of another.
That still leaves the duty cycle issue. If one daisy is 10% smaller than the previous, the twelfth daisy is going to be rather small.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
That still leaves the duty cycle issue. If one daisy is 10% smaller than the previous, the twelfth daisy is going to be rather small.
No no. Let one AVR drive the clock-inputs for all the others. And if they are further away than 5 inches, you need a decent clock-driver.

Quote:
Added:
From the documentation I can find, I can't tell that CLKO is even suitable for one AVR. If it will work, I need a source that those who are not me are willing to use for design work.
Like I said earlier: the CLKO is driven from a standard AVR-output circuitry. Why would that cause a problem ??

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
That still leaves the duty cycle issue. If one daisy is 10% smaller than the previous, the twelfth daisy is going to be rather small.

The duty cycle coming out of the AVR will be very close to 50% to start with. The only thing that will change the duty cycle will be a delay in one edge of the clock or the other. This would be the case if the transmission line has a filter (RC or RL, or combination of the two) and some solid state component (diode) to affect one edge or the other.

Using a shielded twisted pair transmission line of 6" to 12 " shouldn't be an issue. More then 12" and I'd be looking at placing a line driver on each PCB that can operate at the frequency of the master CLK - be it an external oscilator module or from the AVR oscilator.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Using a shielded twisted pair transmission line of 6" to 12 " shouldn't be an issue. More then 12" and I'd be looking at placing a line driver on each PCB that can operate at the frequency of the master CLK - be it an external oscilator module or from the AVR oscilator.

If one is going to run a "clock wire" as you described, it is very probable that adding a crystal to each would be less expensive.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

Using a shielded twisted pair transmission line of 6" to 12 " shouldn't be an issue. More then 12" and I'd be looking at placing a line driver on each PCB that can operate at the frequency of the master CLK - be it an external oscilator module or from the AVR oscilator.

If one is going to run a "clock wire" as you described, it is very probable that adding a crystal to each would be less expensive.

Lee


I agree! But the OP seems to have this requirement. He mentions something about CLK phase from controller to controller and exactly identical frequencies across the many controllers. I'm not sure why he needs this.

The only reason I can think of would be to ensure that all of the controllers were closely in synchronization to each other. There might be a slight and increasing phase difference added to each additional downstream controller in a daisy-chain clocking scheme. But if all of the controllers were reset via a master RESET, synchronization of events across controllers would be pretty much guaranteed - assuming that all of the controllers also used the same CLK start up delay and identical initialization characteristics.

If there was only 3 or 4 controllers in the system, I think I would opt for the CLK "Fan-Out " method, rather then a daisy-chain scheme. In the daisy-chain scheme, all of the controllers would be required to have power present, at minimum, if a locak CLK driver is present on each controller - else you loose the PCK signal to the down-stream controllers.

Fanning the CLK out to each controller (I.E. driving each controller directly from the CLK source) would allow all of the other controllers to stay running. But if there were a lot (50, I think?) of controllers, driving each controller CLK in parallel would get quire expensive.

Engineering... It really is all about trade-offs.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

He mentions something about CLK phase from controller to controller and exactly identical frequencies across the many controllers. I'm not sure why he needs this.

In the early years of this Forum there were periodic posts about "needing" two or more AVRs to run in lock-step from the same clock source. I've never been able to see a rational convincing reason/argument/requirement for that. Any real app with interrupt sources isn't going to stay in lock-step with its brothers forever, anyway.

I scanned the thread again and still haven't seen any "why"--probably I missed it.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Any real app with interrupt sources isn't going to stay in lock-step with its brothers forever, anyway.

That's a very good point, Lee! Ont that slipped past me, in my senility!!!

I can't think of any situations either, where multiple processors would need to run in absolute Lock-Step. But I can think of several other ways to periodically get --events-- between multiple processors synchronized, which is probably what the OP is really trying to accomplish.

Though, I might see where multiple controllers may be required to run at the exact same CLK frequency, or possibly have a predictable phase relationship between their CLK sources.

The only time I've ever considered running multiple processors within a project was to load share, but have always found other ways to get the job done - save the HD44780 LCD serial backpack.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The "ONLY" thing I can think of is a high speed communications protocol which won't tolerate any clock drift. And that's really grasping at straws for a reason.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcarl wrote:
Using a shielded twisted pair transmission line of 6" to 12 " shouldn't be an issue.
I agree a driver wouldn't be needed for those distances, for but daisy-chained devices at those distances, I'd use the parallel termination that you described in another thread with a resistor sized to the characteristic impedance of the transmission line avoid issues with signal corruption from reflections.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm still learning about AVRs, but if you really need all the uPs to run on a single clock source, clearly the fan out is preferred over the daisy chain. Without drivers I would expect board layout to be a challenge.

IF, however, one were to daisy chain, and the "shrinking duty cycle" was an issue, could you not use a 40 MHz Osc module, and put a divide by 2 flip flop in front of each uP, giving you a Master Clock, phase locked, 50 % clock, for each one? It would not matter what the duty cycle was on the incoming clock.

At 20 MHz the entire period is only 50nSec, just how accurate need these uPs be synched?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
The "ONLY" thing I can think of is a high speed communications protocol which won't tolerate any clock drift. And that's really grasping at straws for a reason.
That is about what I had in mind.

The 168s are going to communicate through SPI and we would like to get 2 Mbps with an 8 MHz clock. From the specs, to get a bit rate more than one-sixth the master's clock rate, the slave has to have a clock rate at least that of the master. I suppose there is some slop, but I couldn't find a lower bound on it. If we can't daisy-chain we'll need to use a faster clock.

A fan isn't an option, because we need a solution that works whether we have one dozen or two. The "boards" are to be identical, except for the one that connects to the outside world. Don't worry about cabling. The "boards" are going to be soldered together.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you clocking using the internal RC, or crystal?

Assuming a crystal, or other stable source, for 2Mbps you have 4CPU clocks per bit (SPIclk = Fclk/4) You should not need to have the AVR's all clocked from the same source. At this rate you are maintaining the 2 samples/phase requrement.

You can probably get it to work from the internal RC as well, if you run a calibration routine. (there are several threads on this, as well as a tutorial) But in this case, instead of using a stable external source (like a 32KHz oscillator) I would have the "master" AVR output a fixed divisor wave on one PWM channel, and then the "slave" boards calibrate against it.

Either way, for the rates you're talking about, I don't see a real need to mess with trying to daisy chain the clocks.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The 168s are going to communicate through SPI and we would like to get 2 Mbps with an 8 MHz clock.

1) What does clock fanout or daisy-chaining or synchronization or phasing have to do with SPI transfer rate?

2) AVRs will always run at "modest" clock rates--a few MHz. If you want to dump stuff fast then start with AT91SAM7 or similar with DMA. [Hmmm--the AVRX was supposed to make its appearance a year ago...]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

The 168s are going to communicate through SPI and we would like to get 2 Mbps with an 8 MHz clock.

1) What does clock fanout or daisy-chaining or synchronization or phasing have to do with SPI transfer rate?
As noted earlier, CPU frequencies and SPI transfer rates are related. In any case, it's moot now. The decision to use a higher CPU frequency has been made.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As noted earlier, CPU frequencies and SPI transfer rates are related.

Well, yah, if you want an SPI rate of n then you need an appropriate clock rate to generate (master) and recognize (slave) the SCK at that rate.

But I repeat: What does that have to do with synchronized clocks or phasing or daisy-chaining? Why is my question moot?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It wasn't about synchronization, but rather keeping clock variance to a minimum. He was worried that if the clocks varied by too much, the slave AVR's would not receive correctly, since he's running at the absolute maximum rate for SPI slave mode on the AVR (for the given clock speed).

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It wasn't about synchronization, but rather keeping clock variance to a minimum. He was worried that if the clocks varied by too much, the slave AVR's would not receive correctly, since he's running at the absolute maximum rate for SPI slave mode on the AVR (for the given clock speed).

Isn't that all Nyquist and such, and phasing shouldn't matter even at max rate?

Anyway, here is what got me confused. We started with a title of "daisy-chainging clocks", and the text asked how long a CLKO signal could be extended. Not a word of SPI or bit rates.

Next we heard that a small change in dutiy cycle "is not a good idea", and that it needed to be "precisely the same frequency" and "need to daisy-chain something". Still no mention of SPI.

Then there was discsusiion back and forth about various clock distribution isssues. Finally we learned that it was an SPI application of some sort.

And I stand by my query

Quote:
1) What does clock fanout or daisy-chaining or synchronization or phasing have to do with SPI transfer rate?
And when I ask, I get dismissed 'cause a "decision has already been made".

And sorry, glitcher, I still don't see why someone wants/needs/should go to some elaborate clock distribution scheme, much less a redistribution scheme, to do SPI. AFAIK you just make sure that your AVR is running fast enough for the SCK rate, and phasing won't matter.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Anyway, here is what got me confused. We started with a title of "daisy-chainging clocks", and the text asked how long a CLKO signal could be extended. Not a word of SPI or bit rates.
Of course not. No one willing to answer my question needed that information. It wasn't even useful. I provided that information when it seemed likely to affect the willingness of others to answer and to reduce the number of non-answer answers.
Quote:
Next we heard that a small change in dutiy cycle "is not a good idea", and that it needed to be "precisely the same frequency" and "need to daisy-chain something". Still no mention of SPI.
My apologies for not explicitly stating the obvious: A large number small and insignificant changes can add up to a large and crippling change.
Quote:
Then there was discsusiion back and forth about various clock distribution isssues. Finally we learned that it was an SPI application of some sort.
I think that the non-answer answers were venial sins at worst. Since I didn't commit them I don't feel obligated to answer for them. I don't know that anyone should.
Quote:
And I stand by my query
Quote:
1) What does clock fanout or daisy-chaining or synchronization or phasing have to do with SPI transfer rate?
I'm not sure how many ways this can be answered.
Quote:
And when I ask, I get dismissed 'cause a "decision has already been made".

And sorry, glitcher, I still don't see why someone wants/needs/should go to some elaborate clock distribution scheme, much less a redistribution scheme, to do SPI. AFAIK you just make sure that your AVR is running fast enough for the SCK rate, and phasing won't matter.

That was the decision that was made, though it required more board space. Had we needed 5 Mbps, it would not have been an option.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
And sorry, glitcher, I still don't see why someone wants/needs/should go to some elaborate clock distribution scheme, much less a redistribution scheme, to do SPI. AFAIK you just make sure that your AVR is running fast enough for the SCK rate, and phasing won't matter.

I agree, using a faster clock rate on each AVR, is the better, and more reliable solution. I was merely trying to explain to you what the question was about, and why he was looking down that path.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One more blast, then I'll just reture to "skeeve is SO much smarter than I am, that I'd better not mis-guess and go down the wrong path when responding to ambiguous posts".

Quote:

If so, how far can it be extended?

So, tell me, what answer would you be happy with (since you lambasted all my other points)? Lessee-- my answer is 1472 feet.

Quote:

How can you tell?

'Cause I did it.

Both Carl and I went down the path of "remote" given the "how far" wording. I apologize; I'm sure that Carl does as well for the board/no-board assumption.

Now, what answer would you be happy with? I'm sure that 1472 feet will get all kinds of further constraints put on it.

What--I used a driver?!? Obviously incorrect!
What, it wasn't differential?!? Obviously incorrect in my noisy environment.
What, you used shielded cable?!? Obviously too expensive.

And I'm sure that there will be others.

For an undertaking like this, how hard would it be to daisy-chain the CLKO of a few of these AVRs and check the signal at the end? But us old fogeys don't know nuttin', and should mainly be ignored.

And why the insistence on the daisy-chaining path? Even with the described stacking of the biards/modules, there is no reason why the clock couldn't be bussed, just like power and ground. Duh.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.