previously, TR pulses were processed by tele_tick which gets triggered by a 10ms timer, which resulted in the actual pulse length being off by up to 9ms. this PR introduces dedicated timers for each TR output to improve the accuracy. as there are only 4 trigger outputs, i don't think adding 4 timers should make any impact.
additionally, i fixed a bug i discovered where killing delays would not restore TR outputs that had a pulse in progress.
How should this be manually tested?
i tested this with a scope and confirmed that the pulse time matches the one set with TR.TIME. also confirmed TR pulses work in general - triggering different outputs, changing the pulse time while a pulse is in progress, killing delays.
What does this PR do?
previously, TR pulses were processed by
tele_tickwhich gets triggered by a 10ms timer, which resulted in the actual pulse length being off by up to 9ms. this PR introduces dedicated timers for each TR output to improve the accuracy. as there are only 4 trigger outputs, i don't think adding 4 timers should make any impact.additionally, i fixed a bug i discovered where killing delays would not restore TR outputs that had a pulse in progress.
How should this be manually tested?
i tested this with a scope and confirmed that the pulse time matches the one set with
TR.TIME. also confirmed TR pulses work in general - triggering different outputs, changing the pulse time while a pulse is in progress, killing delays.I have,
CHANGELOG.mdandwhats_new.mdhelp_mode.c(if applicable)make formaton each commit