Low-level library and timer assistance -- TeensyStep library ???

epicycloid

Well-known member
We're currently dead in the water without T3.x's and no working T4.x library. Can anyone help us over the hurdle?


TL;DR

Is there anyone here who might be able to investigate / re-visit the low-level timer changes from T3.x to T4.x to re-implement the original TeensyStep library, *not* the incomplete TeensyStep4 library, on the T4.x?

Can anyone step in and pick up where @luni left off, and get the original TeensyStep library working again on T4.x, even if not at the performance level anyone would expect on the T4.x platform?


The rest of the story...

TeensyStep was a fantastic stepper library, that was unfortunately broken by the low-level timer architectural changes going from T3.x to T4.x.

@luni / luni64 on GitHub / Lutz Niggl is a brilliant guy, but other demands have pulled him away from working on or updating the TeensyStep library.

That said, he was part of identifying the issues in the early T4 beta, and he did take a stab at a completely different programming model, and introduced his partially re-architected TeensyStep4. Unfortunately it isn't finished, has numerous open issues, and is provided with the warning, "Please note: This library is very experimental and no support can be given at the moment." He hasn't edited or updated it in a while now.

TeensyStep on GitHub -- https://github.com/luni64/TeensyStep
TeensyStep4 on GitHub -- https://github.com/luni64/TeensyStep4

The trifecta of the pandemic, chip shortage and EoL of the T3.x all collided to leave our project dead in the water with no path forward. We have a complicated, coordinated motion project, in use by quite a few people, but with no way to move forward now that T3.x's have been discontinued, and a "replacement" T4.x library that isn't fully functional.

Our project, currently with about 40,000 lines of code, is working perfectly with TeensyStep, controlling multiple coordinated stepper motors, with a Nextion touchscreen for the UI.

We have added a controller and stepper motors to a specialized woodturning lathe, known as a rose engine. The project hatched about 15 years ago, and has evolved into a complex and robust system, capable of cutting a wide array of patterns. Examples of pre-controller work, and the lathe that serves as the underlying platform can be read about here: https://www.rogueturner.com/ewExternalFiles/Its small world.pdf and https://www.rogueturner.com/ewExternalFiles/RoseEngine.pdf. Additional articles here: https://www.rogueturner.com/ornamental-obsessions.html

The current project is posted on GitHub here: https://github.com/elfren/RoseEngine_SpindleAndAxis, and documented here: https://mdfre2.colvintools.com

@luni replied to "Is TeensyStep4 an update of TeensyStep or a whole different library?" in the GitHub issues thread here:
https://github.com/luni64/TeensyStep4/issues/4 and lays out a number of issues and why he isn't moving forward with the old model on the newer chips.

An attempted port of our project to the TeensyStep4 library has stalled when we hit various issues. Two of our open issues have yet to be acknowledged here: https://github.com/luni64/TeensyStep4/issues

The architectural changes that were made with the low-level timers in the move from the T3.x's MK64FX512VMD12 / MK66FX1M0VMD18 Cortex-M4F to the IMXRT1062DVJ6 Cortex-M7 of the T4.1, while above my pay grade, is what @luni wrote required a redesign of the entire library.

@luni describes the issue with the peripherals, including PIT timers, running on a separate bus from, and not synchronizing with the ARM core here: https://github.com/luni64/TeensyStep/issues/56

@luni and @defragster discussed here: https://forum.pjrc.com/index.php?threads/teensy-4-intervaltimer-max-speed.57959/#post-218577 and reference an earlier T4 beta thread with input from @Frank B, @KurtE, @manitou, @PaulStoffregen and others here: https://forum.pjrc.com/index.php?threads/teensy-4-0-first-beta-test.54711/page-48. Most of that is w-a-y above my pay grade, I'm just a lurker when I start reading their posts and discussions. But it was clear there was an identified timer and bus issue early on.

Is there anyone here willing pick up the torch and help update the original library to allow us move forward on the T4.x's?

TIA -- epicycloid & @Elf
 
I'm currently working on a project which will include some steppers. Thus, chances are good that I need to get TeensyStep working with a T4 anyway. I can't promise anything but I'll try. As you already mentioned: don't expect better performance compared to a T3.5/6 but for normal applications it should be fast enough.

@epicycloid: Do you have a deadline? And, since I was in Greece for a couple of days last summer: You might like this ;-)
1743528235579.png
 
I see that Luni just responded, but I'll post this anyway...

I ran the test program from 2019 that showed the problem with 4 x IntervalTimer (PIT), and got the same result as in the thread.

f:100.0 kHz Load: 41.7 (w/o interrupts: 6500008 with interrupts 11151196)
f: 50.0 kHz Load: 17.1 (w/o interrupts: 6500008 with interrupts 7838228)
f: 25.0 kHz Load: 8.5 (w/o interrupts: 6500008 with interrupts 7105345)
f: 12.5 kHz Load: 4.3 (w/o interrupts: 6500008 with interrupts 6792574)
f: 6.2 kHz Load: 2.1 (w/o interrupts: 6500008 with interrupts 6641502)
f: 3.1 kHz Load: 1.1 (w/o interrupts: 6500008 with interrupts 6571087)
f: 1.6 kHz Load: 0.5 (w/o interrupts: 6500008 with interrupts 6535767)

Then I modified the program to use TeensyTimerTool and 4 x PeriodicTimer (TMR1), and got 3-4 times faster. Is use of QuadTimer a solution?

f:100.0 kHz Load: 12.0 (w/o interrupts: 6500010 with interrupts 7385069)
f: 50.0 kHz Load: 6.0 (w/o interrupts: 6500010 with interrupts 6916715)
f: 25.0 kHz Load: 3.1 (w/o interrupts: 6500010 with interrupts 6706815)
f: 12.5 kHz Load: 1.5 (w/o interrupts: 6500010 with interrupts 6602343)
f: 6.2 kHz Load: 0.8 (w/o interrupts: 6500010 with interrupts 6550821)
f: 3.1 kHz Load: 0.4 (w/o interrupts: 6500010 with interrupts 6525032)
f: 1.6 kHz Load: 0.2 (w/o interrupts: 6500010 with interrupts 6512418)
 
The Quads are only 16bit which will limit the minmal possible steprate. Adjusting the prescaler on the fly would help but I'm afraid that this will open another can of worms. I'll stick with the PITs for the main timer and use the TMRs instead of the FTMs for the pulse generation. Lets see how this works out performance wise.
 
I'm currently working on a project which will include some steppers. Thus, chances are good that I need to get TeensyStep working with a T4 anyway. I can't promise anything but I'll try. As you already mentioned: don't expect better performance compared to a T3.5/6 but for normal applications it should be fast enough.

@epicycloid: Do you have a deadline? And, since I was in Greece for a couple of days last summer: You might like this ;-)
View attachment 37237
@luni -- It is so good to know you are alive and have come up for air! First trip back to Greece since 1983? ;) Nice"Greek Key" pattern, as we call it in ornamental tuning.

Deadline? Not per se, but we are truly dead in the water in terms of anyone building a new controller, or as T3.x's die, there is no way to move forward.

One user in our group, whose T3 died, bravely tried the T4.1 "beta" port of our system, and eventually gave up. Too many issues with TeensyStep4, and the "rose" function not able to work at all. I mailed him one of the last T3.5's I had in my personal stash, and he was able to get back up and running, and produced this box... the sinusoidal infill is the "rose" pattern, while "rocking" mechanically with a 5-lobe rosette. Thought you might like to see a current example of work...

Tom-RoseRock2.jpg
Tom-RoseRock1.jpg


As I think you know, we are less concerned about overall speed, but maintaining the same programming model would be incredibly valuable for us.

If you can get the "original" TeensyStep up and working on the T4 we would all be eternally grateful!! And I can't tell you how nice it is to "hear" your voice again.

--epicycloid
 
The Quads are only 16bit which will limit the minmal possible steprate. Adjusting the prescaler on the fly would help but I'm afraid that this will open another can of worms. I'll stick with the PITs for the main timer and use the TMRs instead of the FTMs for the pulse generation. Lets see how this works out performance wise.

Hi @luni, I would be interested in following along as you do this, just to learn more about the timers, or if there is something I can do to help, let me know.

QuadTimers are cascadable, though, so with 2 x QTMR you could have 4 x 32-bit timers, without the limitation of only one interrupt, right? Also, I don't know how much you've used FlexPWM, but it's pretty easy to operate with interrupts and duty cycle update on every cycle. I've done that up to 10 kHz for a motor control, and I'm pretty sure 100 kHz would work, too, but I don't know enough about how you use PIT and FTM in signal generation to know whether that helps.
 
Back
Top