Teensy 3.5 FREQMEASUREMULTI timer clock rate?

[Condor Pasa]

Hello,
I hacked Paul's example code to measure 4ea frequencies (motor speeds) and it works great! My question is about freq5 below. It's measuring a pulse width with
a Teensy 3.5 at 120MHz but the read from freq5 below is at a 60MHz rate. Am I missing something?
Shouldn't it be reading is at a 120MHz instead of 60MHz? It also works great assuming it runs at 60MHz.


freq1.begin(5);
freq2.begin(6);
freq3.begin(9);
freq4.begin(10);
freq5.begin(20,FREQMEASUREMULTI_MARK_ONLY);


while (!SD.begin(chipSelect)) {}
}






//**************************************************************
//**************************************************************
//*********************** LOOP FUNCTION **********************
//**************************************************************
//**************************************************************
void loop() {

//********************************
//Step 01 Measure frequency's
//********************************
if (freq1.available()) {
sum1 = sum1 + freq1.read();
count1 = count1 + 1;
}
if (freq2.available()) {
sum2 = sum2 + freq2.read();
count2 = count2 + 1;
}
if (freq3.available()) {
sum3 = sum3 + freq3.read();
count3 = count3 + 1;
}
if (freq4.available()) {
sum4 = sum4 + freq4.read();
count4 = count4 + 1;
}
if (freq5.available()) {
sum5 = sum5 + freq5.read();
count5 = count5 + 1;
// CH7 = freq5.read();
}

 

[PaulStoffregen]

It's measuring a pulse width with
a Teensy 3.5 at 120MHz but the read from freq5 below is at a 60MHz rate. Am I missing something?
Shouldn't it be reading is at a 120MHz instead of 60MHz? It also works great assuming it runs at 60MHz.

The timers and most other peripherals run from F_BUS, not F_CPU.

 

[Theremingenieur]

Studying the Teensy's reference manual, you'd discover that most peripherals, among them the FTM modules, are not clocked with the CPU clock, but with the so called Bus clock. The latter is generated by integer division of the CPU clock and may not exceed 60MHz (says the reference manual). Thats why you have the following relationships in the Teensy 3.x world:
F_CPU(MHz) - F_BUS(Mhz)
24 ------------ 24
48 ------------ 48
72 ------------ 36
96 ------------ 48
120 ----------- 60
144 ----------- 48
180 ----------- 60
192 ----------- 48

Several forum members have shown that it is possible to run most peripherals with a higher bus clock. A Teensy 3.2 @96MHz will not die if you run the bus also at 96MHz. But I ignore if anybody has already tried to push the F_BUS beyond 100MHz... In ever case, you can hack the boards.txt file to obtain higher bus clocks, but at your own risk! Other internal hardware like the I2S module(s) are not so graceful.

 

[PaulStoffregen]

While the chip's design is a Freescale (now NXP) proprietary secret, it's not hard to guess roughly how they design it. The ARM processor part comes from ARM Ltd as a tightly optimized layout. Most of the rest of the chip is peripherals designed by Freescale using HDL language (VHLD or Verilog).

Compared to software, the periperals would be akin to compiler generated code that's had some optimization done, but the focus is mainly on keeping the design flexible and reusable for other chips. The ARM processor portion can be considered like hand-crafted assembly, very tightly optimized.

Or if you think of PCB layout, even with just a quick glance it's easy to spot the difference between layout from an autorouter versus meticulously human routed design.

That doesn't necessarily mean you shouldn't try to overclock the peripherals. Frank and others have done so with quite a bit of success. But if you're wondering why some parts of the chip run slower than others, even though they're just digital logic made from the same transistors, keep the differing design process in mind.

 

[Condor Pasa]

Thank you Paul and Theremingenieur.

Another lesson from the masters.
Your posts are very important and there reach is unknown to the community...

I did not know there was a Teensy reference manual.