Trying to get my head around clock-dividers from a development point of view. Perhaps I am trying to “trip my own legs” (make it more complicated than it should be), as I would like the divider to react in the same way whether the input is a trigger or a symmetric square-signal.

Clock-dividers for even divisions at exponents of 2 (2, 4, 8 …) are very easy to implement. A full clock-cycle consists of a “high” and “low”-phase (e.g. written as “10”). Hence a “/2” divider should toggle its high/low-state each time the module receives the base-clock input (e.g. detected as a “clock” going high using a dsp::SchmittTrigger). Likewise a “/4” divider should toggle its high/low-state each 2nd time the module receives a clock-input (or each time the “/2” toggles to high). So whether such a module is fed an input-clock in form of a square-waveform or each “clock” is a 1 ms trigger, the module would work, as it simply have to “count” the number of times the input goes high (hence using a dsp::SchmittTrigger). For that matter the input could be a manual push button, as it simply have to “count” the number of “going-high” signals.

```
Clock/1: 101010101010 (1=High, 0=Low)
Clock/2: 110011001100
Clock/4: 111100001111
```

But for any other division (e.g. “/3”) I can’t see how to do it simply “counting” the number of input-clocks. As I see it, the only way to implement a “/3” divider (or any other odd-divider) is to measure “the time” (number of cycles) between 2 successive incoming clock-signals? A full clock consists of a high-phase and a low-phase, hence the base/input-clock could be seen as “10”. A “/2” division could then be seen as “1100”, so as written above, simply toggle between high/low each time the input-clock goes high. But a “/3” division if seen as “111000” should stay high 3 times as long as the base clock is high (as long as the input is a symmetric square). So to also support input’s as triggers, first measure “the time” (number of cycles) between receiving two input-clocks, so we have “the time” of a full clock cycle. Then divide this by 2, in order to know “the time” of the high/low-phases. Finally multiply this by 3, so we know for how long time our “/3” should be high (and naturally it have to be low as much time afterwards) ?

In stead of measuring “the time” of a full (high/low) clock-cycle, you could measure the time the base/input clock is high (half a clock-cycle). But in that case it would only work as long as the base/input clock is a symmetric square-waveform, hence it would not work if feeding the input-clock with trigger-signals, and I can’t see that this would work with a manual push-button, as it is no longer about the “count” (number of times input is “going high”) but is all about timing?

Am I totally wrong? or is there a another/better approach than “keeping track of time” (between successive clock-inputs), hence needs to have received two input-clocks before being able to calculate the correct timing for odd divisions?

I’m guessing the same method (time between 2 base-clock) would have to be used if you want to have a module that can multiply clocks. E.g. to output a “*2” clock (double the frequency of the incoming base-clock), you need to have received 2 input-clocks before you know “the time” a base-clock takes, as the “*2” should take half the time?