I had a look at your test case and, since I don't want to mess with python, I adapted the code to print the measured periods and pulsewidths directly into a serial monitor.
#pragma once
#include <Arduino.h>...
Best is to provide a minimal and complete example showing the effect.
Starting/stopping/triggering the timers of course needs some time. But once a periodic (hardware) timer runs, it should be quite stable. As...
Please try EncoderTool v3.2.0 and TeensyTimerTool v1.3.0. They should work together in the old and the new IDE.
And no, it does not accelerate things if you post the same complaint on each and every channel after I...
Of course they shouldn't but I stumbled over such an issue a couple of weeks ago, fixed it and obviously forgot to push it to github. Unfortunately I'm currently not at my desk and have no access to my computer with the...
Actually, I don't use IDE2 currently (using VisualTeensy and/or PlatformIO). I'll install it later today and see what is going wrong.
Edit: are you using the TimerTool and the EncoderTool in the same project?
Here some addtional input.
In loop you are printing without any delay which will generate overrun issues on the serial monitor. Add some delay to your loop 1ms should be good.
You are pulling up your switch to...
Of course you could always hook into any ISR by manipulating the vector table. Here an example (T4.0) showing how to intercept the systick ISR which is called every millisecond. The intercepting code simply increments a...
I tested it this morning and also found that the problem relates to trigger a second interrupt while the first ISR is running. The processor will store the request (which is a feature) and calls the ISR immediately...
Last time I checked, I could fix it by moving the definiton of _write from print.cpp to mk20dx128.c. See here for details: https://forum.pjrc.com/threads/65469-EncoderTool-Problems?p=264073&viewfull=1#post264073
In...
You can try to change
pinMode(INTERRUPT_PIN, INPUT);
to
pinMode(INTERRUPT_PIN, INPUT_PULLDOWN);
This is supposed to enable some hysteresis on the pin which should also remove multiple interrupts caused...
If you want to try you can change the code in /src/TimerModules/TMR/TMRChannel.h (line 52ff) from this:
errorCode TMRChannel::start()
{
regs->CNTR = 0x0000;
regs->CSCTRL &= ~TMR_CSCTRL_TCF1;
...
As joeqasquariello mentioned it is difficult to advice without any timing requirements. Here a quick test sketch (calling the first ISR manually) and some measurments. The code generates a 2kHz trigger signal on pin13...
I can reproduce this behaviour. As mentioned by others above, it looks like your display libraries are doing things to pin 12.
Since the encoder library is setting up its pins in the constructor the setup might get...
IIRC the accuracy of the 32kHz crystal is about 20ppm. If that is still acceptable, you can try the TimerTool. Besides other Hardware timers it also supports the RTC as timing source.
E.g. the following code...
Actually 32kHz is not very fast for a T4.1. You can connect the clkout signal to a Teensy pin and attach a pin interrupt. In the ISR I'd simply increment a 32bit variable and use this as timestamp.
Something like...
The timer flag ist part of the timer peripheral. It takes some time until the change propagates to the peripheral. For very short ISRs the flag is not yet reset at the end and the ISR is called twice. The DSB Waits...
This looks like a hardware issue. Did you measure the output voltage on A/B? Make sure that it isn't higher than 5V for T3.1, T3.5 and not higher than 3.3V for T3.6 or T4.x. You will destroy your controller if you...
I meanwhile had a closer look at your code. The reason why it doesn't work seems to be that you set the Joystick to manualSend mode in setup(). In this case you should place a Joystick.send_now after all your...
I can't help you with the Joystick stuff but I can show you how to tackle the encoder part of the problem:
#include "Arduino.h"
#include "EncoderTool.h"
using namespace EncoderTool;
Encoder e1;