Best Timer Approach for PLL N and A Counters

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

Hi Guys,

 

I'm planning to use an Arduino Nano (ATMega328P) in combination with a PLL and Dual-modulus Prescaler IC to create a PLL operating at ~35MHz.  The prescaler knocks the output frequency down to a more manageable ~500KHz and I'm planning to do the N and A counting using the Nano.  For those unfamiliar with the technique, the general idea is that the dual-modulus prescaler divides by two numbers (in my case 64 and 65 based on an IC pin value setting) providing a more flexible overall division.

So, the idea is that the prescaler will generate pulses (at around 500KHz) that I will clock through pin T0 on the Nano.  My N = 4 and my A = 20.  For N pulses I will set the prescaler pin to have it divide by 64, then for A pulses I will toggle the prescaler pin to cause it to divide by 65.  After N + A pulses through T0 I will toggle some Nano output pin to achieve a final frequency of ~125KHz.  I hope this isn't too confusing for anyone new to all this!

 

Anyway, that's the background - now to the question.  Can anyone advise me as to the most efficient way to count and toggle the pins.  Looking at the datasheet (and reading various sources), it seems that I could use some kind of CTC approach.  Maybe I could set my "TOP" to 4 then in an interrupt I could flip the prescaler pin and reset TOP to 20, then when 20 is reached I could toggle my output pin to achieve 125KHz.  My worry is that this interrupt based approach won't be fast enough.  I looked at the more hardware based "Fast" PWM approach, but I couldn't see a way to fip the prescaler pin in the middle of the count (i.e., after N=4 pulses).  Any ideas?

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

What else does the mpu need to do between the clock changes?

You could set the two compare registers up with 4 and 20 and then just spin wait on which ever one you need to watch, no interrupts needed, just watch the match flags.

if the mpu is not doing anything else.

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

If you want something you've never had...

...you must be willing to do something you've never done!

Lets go Brandon!

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

ki0bk wrote:

What else does the mpu need to do between the clock changes?

You could set the two compare registers up with 4 and 20 and then just spin wait on which ever one you need to watch, no interrupts needed, just watch the match flags.

if the mpu is not doing anything else.

Eventually, the uC will need to allow the PLL output frequency to change.  It'll do this by altering the A count in response to some input, most likely using a rotary encoder.  It may also need to display the current frequency setting.

If I understand what you're suggesting correctly, I think you're saying that I test the two compare flags in the main loop.  Do I have that correct?  Well, that most likely won't work for me.

 

From what I've read so far, it seems the best options are interrupt or hardware based (or some combination of the two).  I suppose you could see this as two independent counters both clocked to T0.  One counts to N and flips an output (M/M+1 prescaler pin), the other counts to A + N, flips two outputs (M/M+1 prescaler pin and 125KHz output pin) and resets both counters back to zero.

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

What PLL chip or other parts are you using?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Are you sure about the 125kHz?  If I'm understanding your description properly it sounds like your "output" frequency would be more like 12.5kHz.

Letting the smoke out since 1978

 

 

 

 

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

digitalDan wrote:

Are you sure about the 125kHz?  If I'm understanding your description properly it sounds like your "output" frequency would be more like 12.5kHz.

Gah! You're right! I've made a few errors in how all this will work.  Let me gather my thoughts and I'll come back.  I'm pretty sure there will still be a counter question, but the operation sequence will be different.