Teensy 4.1 counter example not working

[sethgi]

Hello,

I'm brand new to the Teensy platform, and I'm trying to use a Teensy 4.1 to sample from a 16bit ADC.

I'm currently trying to make sure my code which samples data is fast enough to run at the desired rate (around 600KHz).

For testing, I have mimicked the setup recommended in this post and the corresponding video: https://forum.pjrc.com/threads/48101-PMT-pulse-counting-using-Teensy-3-2

Physical setup is not very important here, all that matters is when I try to compile the sample code in that thread, I get this error:

 error: 'IRQ_PORTA' was not declared in this scope

I'm working in Ubuntu 18.04 with arduino 1.8.13 and teensyduino 1.53. Other code is working just fine.

I suspect I'm either missing an include of some sort or not linking properly, this is a difference in version (since the sample code was for a 3.x board), or something totally different since I'm completely new to the platform.

Any ideas?

Thanks!
-Seth

EDIT: I now realize that I have this thread a very misleading name... sorry.

 

[defragster]

Teensy 3.x has a different architecture and that IRQ doesn't exist in the T_4.x hardware design.

That code will need edited.

On the T_4.x's 1062 processor as prepared on entry to setup() all pin IRQ's - regardless of port - go through a single interrupt :: IRQ_GPIO6789

Hopefully that is the needed answer. Will be interesting when working to see what the result and code are.

 

[sethgi]

Ah perfect! Thanks!

I changed IRQ_PORTA to IRQ_GPIO6789 and ran the same rough test procedure as in that post and video. It's worth noting that I'm a student so my hardware is a bit crappier, and I'm using a relatively cheap combo signal generator/counter. However, I doubt that's a significant source of error.

Without setting the priority: At 0.9MHz, all is well. At 1MHz, I start dropping counts. About 5ppm.

With priority set: 1.8MHz is totally fine, but I start having issues at 1.9.

That's interestingly a bit worse than what was reported on the 3.6. I wonder if that's my setup, or something else. I'd be curious if others tried to run the same test what they get.

Again, I'm also super new to the platform so I could be doing something wrong.



Code (99% copy-pasted):

volatile unsigned long count=0;
unsigned long prior_count=0;

void pulse() {
  count = count + 1;
}

void setup() {
  pinMode(0, INPUT_PULLDOWN);
  attachInterrupt(digitalPinToInterrupt(0), pulse, RISING);
//  NVIC_SET_PRIORITY(IRQ_GPIO6789, 0);
}

void loop() {
  unsigned long new_count = count;
  if (new_count != prior_count) {
    Serial.println(new_count);
    prior_count = new_count;
    delay(10); // print at reasonable speed
  }
}

 

[defragster]

That was quick.

Those results being less than T_3.6 aren't beyond belief due to the change going along with the note in post #2.

That is the four ports in IRQ_GPIO6789 - 6,7,8,9 are shoe horned into a single interrupt entry point. Then there is code to decide which port triggered and then which pin on the port.

On startup the I/O is in a slower mode, but each goes through a unique port IRQ. When moved to faster I/O mode - it takes them to that shared IRQ with added overhead to discern the active pin.

There may be other issues as well with the design change going to a 600 MHz MCU with so much more packed in.