Sorry, I was busy yesterday and didn't find time to answer. The reason why it hang was one change you did in Timer.cpp which I forgot to undo. Specifically, you assigned TeensyTimer Tool timers to TimerA, TimerB.... The library then tried to call the VirtualTimer Methods on them which can't work of course. I fixed that, cleaned up timer.h and added a while(!Serial) to the setup(). Looks like it works now.
Here the relevant code in timer.cpp:
Code:
....
#elif defined(TEENSYDUINO)
#include "Teensy4X/Timer.h"
Timer TimerA(1); // use the timer numbers to select which timer you want to create in timer.h
Timer TimerB(2);
Timer TimerC(3);
#endif
And here a super simple example how to use intervalTimers instead of the AVR timers. I'll prepare an example using the TCK - Software timers. They probably are good enough for the rather long (56µs) signals.
Code:
#pragma once
#include "../VirtualTimer.h"
#include <Arduino.h>
class Timer : public VirtualTimer
{
public:
Timer(int timer_num) {}
void initialize()
{
if (timer != nullptr) stop();
timer = new IntervalTimer();
}
void setPeriod(unsigned long mu)
{
microseconds = mu;
}
void start()
{
timer->begin(isrCallback, microseconds);
}
void stop()
{
if (timer != nullptr)
{
timer->end(); //this will release the timer, I assume that the lib doesn't call start after stop without initializing.
delete timer;
timer = nullptr; // If so -> start would error. In case the lib wants to stop/start something more elaborate needs to be done here
}
}
void attachInterrupt(void (*isr)())
{
isrCallback = isr;
}
void detachInterrupt()
{
stop();
isrCallback = nullptr;
}
private:
uint32_t microseconds;
IntervalTimer* timer = nullptr;
void (*isrCallback)();
};
extern Timer TimerA;
extern Timer TimerB;
extern Timer TimerC;
extern Timer TimerD;
Here the generated signals on pin 3 and 12
Output on Serial:
Code:
DCC++ EX v3.0.3<iDCC-EX V-3.0.3 / TEENSY / STANDARD_MOTOR_SHIELD G-9db6d36>
LCD1:Ready
I sent you a pull request, but since you changed stuff back, my copy was a bit out of sync and you will have merge conflicts. If you want to try my code, simplest probably is to clone the code from my fork:
https://github.com/luni64/CommandStation-EX
Looks like there is a serial interface to control the trains. Is this "human typable" for tests with SerMon?
Reply With Quote
Originally Posted by mjs513
Please no need to apologize for being busy yesterday, things still need to get done 