What is Teensy 3.5 Default Clock?

Hi, I'm just wondering what is Teensy 3.5 default clock if we didn't do any configurations? I saw in a web (https://www.pjrc.com/teensy/prescaler.html) that its 2 MHz but this only applies to Teensy 2.0 and Teensy++ 2.0. I read the MK64FX512VMD12 ARM Cortex-M4 CPU and it mention about multiple clock and I still can't find out what its default clock and working clock speed. Please enlight me, Thank you!
 
There is a system #define of F_CPU on T_3.5 that will give the process speed.
> Serial.print( F_CPU );
Will work to display that. Likewise for the current 'BUS' speed - which is fixed and set during compile time like the F_CPU speed:
> Serial.print( F_BUS );

F_CPU will resolve to a number for use in code like:

> if ( F_CPU > 120000000 ) Serial.print( "This T_3.5 is overclocked" );
 
I see, thank you! I didn't have a Teensy 3.5 at the moment but I will try that. However I'm still curious, if we needed to find out the process speed through Serial.print, does that mean Teensy 3.5 didn't have a default clock and its speed could change from time to time?

And also since you mentioned about the bus speed, what's the difference of bus speed and cpu speed and its effect on the microcontroller? I'm sorry if I asked too much, I'm still learning about this.
 
Each ARM Teensy can have run time set at compile time in the IDE. Install the IDE and TeensyDuino and you can see what it looks like.

There are a number of clocks for different things on the ARM Teensy - the other major after F_CPU is the F_BUS which controls I/O clocking change rate. It isn't something you can do much about except be aware of - forum search my find useful details if interested - and thousand pages of manuals on the chips if a gluten for punishment.
 
I see, thank you! I didn't have a Teensy 3.5 at the moment but I will try that. However I'm still curious, if we needed to find out the process speed through Serial.print, does that mean Teensy 3.5 didn't have a default clock and its speed could change from time to time?

And also since you mentioned about the bus speed, what's the difference of bus speed and cpu speed and its effect on the microcontroller? I'm sorry if I asked too much, I'm still learning about this.

To add a little nuance to defragster's post.

When you select the Teensy 3.5, there is a drop down menu giving the various speeds. On the Teensy 3.5, the options are:
  • Normal speeds: 120MHz, 96MHz, 72MHz, 48MHz, and 24MHz;
  • Speeds where the USB connection does not work: 16MHz, 8MHz, 4MHz, and 2MHz;
  • Overclock speeds (some things may break): 144MHz and 168MHz

For the Teensy LC, 3.0, 3.1, 3.2, 3.5, and 3.6, the clock speed is set at compilation time. The chip can change it in special cases, but other things depend on the value being constant. For example to write to the EEPROM memory, the 3.6/3.5 have to have a slow clock speed. So the EEPROM functions temporarily lower the speed when doing the write, and then raising it again before returning to the user.

For the current Teensy 4.0 and the forthcoming Teensy 4.1, you can change the clock speed dynamically at runtime.

As an example, I was playing around with the 4.1 beta board that I had today, and the chip seemed a little hotter than I remembered the 4.0 being (Teensy 4.1 will use the same chip as Teensy 4.0). I got out a Teensy 4.0, and it too was slightly hot to touch. I then lowered the clock speed to 24MHz, and the chips were cooler to the touch. The internal temperature difference was about 10F or 5-6C cooler when running at the slower clock speed. I would imagine it also uses less energy.
 
To add a little nuance to defragster's post.

When you select the Teensy 3.5, there is a drop down menu giving the various speeds. On the Teensy 3.5, the options are:
  • Normal speeds: 120MHz, 96MHz, 72MHz, 48MHz, and 24MHz;
  • Speeds where the USB connection does not work: 16MHz, 8MHz, 4MHz, and 2MHz;
  • Overclock speeds (some things may break): 144MHz and 168MHz

For the Teensy LC, 3.0, 3.1, 3.2, 3.5, and 3.6, the clock speed is set at compilation time. The chip can change it in special cases, but other things depend on the value being constant. For example to write to the EEPROM memory, the 3.6/3.5 have to have a slow clock speed. So the EEPROM functions temporarily lower the speed when doing the write, and then raising it again before returning to the user.

For the current Teensy 4.0 and the forthcoming Teensy 4.1, you can change the clock speed dynamically at runtime.

As an example, I was playing around with the 4.1 beta board that I had today, and the chip seemed a little hotter than I remembered the 4.0 being (Teensy 4.1 will use the same chip as Teensy 4.0). I got out a Teensy 4.0, and it too was slightly hot to touch. I then lowered the clock speed to 24MHz, and the chips were cooler to the touch. The internal temperature difference was about 10F or 5-6C cooler when running at the slower clock speed. I would imagine it also uses less energy.

Thank you for the information! If judging by the drop down menu of the CPU speed that I chose for my Teensy 3.5, it should be 120MHz which I knew is the maximum clock speed (without overclocking). I was just baffled that if Teensy 3.5 is working on such a high speed, why is it that a data acquisition program I run on Teensy 3.5 can't reach a 1000Hz frequency sampling. Is it cause by the bus speed? I know this is getting technical but I just wanted to know if it's possible for teensy 3.5 to work as a data acquisition (that save data on SD card) with a frequency sampling of more than 1000 Hz. Since, I realized that most of my dataset can't reach 1000 Hz and only range around 900 something Hz.

Code:
#include <SoftwareSerial.h>
#include <SdFat.h>
//========================================= inisiasi
#define outputA 5 //untuk encoder - white
#define outputB 6
#define RawEMG A0
int counter = 0;
int derajat = 0;
int EMG;
int aState;
int aLastState;
long timenow = 0 ;
long timeprev = 0;
//========================================= variable
#define MaxCount 30000
float freqsampling = 10000;                      //Hz
float timesampling = (1/freqsampling)*1000;                             
int encoderPPR = 2048;                       // real ppr*2

SdFatSdio sd;
File file;

void setup() {
  pinMode (outputA, INPUT_PULLUP);
  pinMode (outputB, INPUT_PULLUP);
  Serial.begin(57600);
  if (!sd.begin()) {
    sd.initErrorHalt();
  }

  aLastState = digitalRead(outputA);
}

void doLogging(uint32_t timeStamp, int *data1, int *data2, int *data3, int nb)
{
  //================================================= init
  static uint32_t ifl = 0;
  static uint32_t count = 0;
  char filename[32];

  if (!count)
  {
    //open file
    sprintf(filename, "LAST_02-26_(1000Hz)_TRY4-%03d.csv", ifl); ifl++;
    if (!file.open(filename, O_RDWR | O_CREAT))  sd.errorHalt("open failed");

    // write header to file
    file.println("timeStamp,counter,derajat,EMG");

    // flag open file
    count = 1;
  }

  if (count > 0)
  {
    // write to file
    file.print(timeStamp);
    for (int ii = 0; ii < nb; ii++)
    { file.print(',');
      file.print(data1[ii]);
      file.print(',');
      file.print(data2[ii]);
      file.print(',');
      file.print(data3[ii]);
      
      Serial.print(counter);
      Serial.print(",");
      Serial.print(derajat);
      Serial.print(",");
      Serial.println(EMG);
    }
    file.println();
    count++;
    if (count > MaxCount) count = 0;
  }
  if (!count)
  {
    Serial.println("+++++++++++++++++++++++++SAVING DATA+++++++++++++++++++++++++++++++++++++++++++++++++++");
    file.close();
  }
}

void loop() {
  //========================================= read data
  uint32_t t0 = millis();
  EMG = analogRead (RawEMG);                       //reads EMG sensor
  //float EMG = EMG * (5.0 / 1023.0);
  aState = digitalRead(outputA);                   //reads the 'current' state of the outputA

  //========================================= do ... every "timesampling"
  timenow = millis();
  if (timenow - timeprev > timesampling) {
    timeprev = timenow;
//    Serial.print(counter);
//    Serial.print(",");
//    Serial.print(derajat);
//    Serial.print(",");
//    Serial.println(EMG);
    doLogging(t0, &counter, &derajat, &EMG, 1);    // Save data
  }

  //========================================= counter encoder to degrees
  if (aState != aLastState) {                 //if there's a shift (perubahan)
    if (digitalRead(outputB) != aState) {
      counter ++;
    } else {
      counter --;
    }
    if (counter > encoderPPR or counter < -encoderPPR)
    {
      counter = 0;
    }
  }
  derajat = counter * 360 / encoderPPR;
  aLastState = aState;
}

That is the code I used, but I'm more interested in discussing it in general because I can't really do anything about this code anymore (since I'm not doing the data acquisition at the moment).
 
Last edited:
it should be 120MHz which I knew is the maximum clock speed (without overclocking). I was just baffled that if Teensy 3.5 is working on such a high speed, why is it that a data acquisition program I run on Teensy 3.5 can't reach a 1000Hz frequency sampling

Indeed Teensy 3.5 has a default clock speed of 120 MHz, which is plenty to sample data at 1 MHz and more (let alone 1000 Hz).

The problem seems to be that for every sample, you call doLogging() which writes to the SD card.

In other words, you are attempting to do a write to card for each sample.
This is not going to work at high frequency, for a number of reasons.

You may want to write to a properly sized buffer and write the buffer to card when it's full.

A (somewhat complicated) example worth studying is the Data Logger Example:
https://github.com/PaulStoffregen/SD/blob/master/examples/Datalogger/Datalogger.ino
 
Indeed Teensy 3.5 has a default clock speed of 120 MHz, which is plenty to sample data at 1 MHz and more (let alone 1000 Hz).

The problem seems to be that for every sample, you call doLogging() which writes to the SD card.

In other words, you are attempting to do a write to card for each sample.
This is not going to work at high frequency, for a number of reasons.

You may want to write to a properly sized buffer and write the buffer to card when it's full.

A (somewhat complicated) example worth studying is the Data Logger Example:
https://github.com/PaulStoffregen/SD/blob/master/examples/Datalogger/Datalogger.ino

NOTED! Thank you! I'll be sure to learn more from there and try to take note of this for my next data acquisition programming. Thank you very much!
 
Back
Top