Min output cycle time for Teensy 3.2 & 3.5

Status
Not open for further replies.

paynterf

Well-known member
Hi,

I'm thinking of using a Teensy for a I2C sniffer, and am experimenting to see how fast I can loop through a small program to toggle a single output line (Teensy Blink without the delay). On my O'Scope it appears it takes about 7 uSec (~150KHz) for a complete cycle, which is way too slow for even 100KHz I2C bus speed. So, I switched to a T3.5, and got an almost identical result. Is there something I'm missing here - maybe a CPU speed setting?

Here's the code I'm running:

HTML:
const int LED_PIN = 13;


void setup()
{
	Serial.begin(115200);
	while (!Serial && millis() < 13000);
	Serial.print("Teensy Online @ millis=");
	Serial.println(millis());
	Serial.println("Starting Teensy");

	pinMode(LED_BUILTIN, OUTPUT);

	//12/17/19 for I2C sniffer testing
	pinMode(2, INPUT);
	pinMode(3, INPUT);

  /* add setup code here */

}

void loop()
{
	bool status = digitalRead(LED_BUILTIN);
	digitalWrite(LED_BUILTIN, !status);
	//delay(1250);
	//Serial.println("blink");

  /* add main program code here */

}
 

Paul,

Thanks for the links to the other threads - that explains a lot. However, I'm still a bit confused, as the same "Blink" code on the venerable UNO runs at 93KHz with a clock that's over 4 times slower than the T3.2 (16MHz vs 72MHz) and over 7 times slower than a T3.5. Just based on clock speeds I'd expect a T3.2 to loop at 360KHz vs the actual 150, and the 3.5 to loop at 540KHz vs the same 150.

Are Teensy uC's doing that much more behind the scenes?

Frank
 
One reason is, the Teensy tests all it's serial interfaces in every loop. It has a few :D more than a UNO. In addion there is even more code..
Another reason is, it has way more pins and they are numbered differently compared to uno. So there is additional code that translates all pin-numbers to ports and pins.

So, to get a fair comparison, use Pauls' code.

But I don't understand why you want to measure that. It makes no sense. A square wave can be generated much better in hardware. With SPI for example (very easy). And it will be way faster.
 
Frank B,

Thanks for the additional information. If you had read the OP, you would have seen that the square wave generation experiment was just that - an experiment to see how fast I could loop through a simple set of instructions, to see if the T3.x was fast enough to serve as an I2C 'sniffer' for a low-speed I2C channel (or alternatively, how slow would I have to go on my target I2C bus in order for a T3.x to keep up.

Now that I know that I'll need to manage the 'behind-the-scenes' activity, I can make some progress. For my intended 'sniffer' project, I'll only need to read two pins (no outputs required) and output results via the USB serial port. Can anyone point me to what minimum 'housekeeping' functions I need for that?

TIA,

Frank
 
Well, it looks like "simple instructions" in your code, but behind the scenes it's not that simple.. :)
For best speed, use direct port access or digitalReadFast/WriteFast() with a constant pin-number - in a while - loop
 
manitou,

Hey, thanks! I did (or thought I did) a pretty thorough Google search for 'I2C Sniffer', but somehow missed this one ;-)

Frank
 
Status
Not open for further replies.
Back
Top