luni
Senior Member

Cool, did you try reading as well? That was much slower than writing on the 1050.

Did you use those tightly coupled GPIO registers the rt1060 has? They claim to get 150MHz using the new registers. See chapter 3.2.2 in this document https://www.nxp.com/docs/en/application-note/AN12240.pdf

By showing me your machine you somehow hit my sweet spot :-) Had a look at some videos showing those machines in action and think that I understand the principle now. At least for the headstock rocking. The structure in...

I had a closer look at your web page and the machines. This is really interesting. If you can wait for the "change position on the fly" feature this might be exactly what you need for this.

Ok, lets answer that one by one Using an encoder instead of a pot to read in the target speed should be straight forward but generating an example is a good idea indeed. I'll upload something on the weekend. ...

Thanks a lot, I'll have a closer look tomorrow

They look great, do you have a schematic?

You are right, it is always a good idea to tie unused inputs to gnd. The board was just a quick test board it worked OK without the gnd connections but I don't recommend that.

Sorry, this is not a good definition since it gets larger than 100% for large loads. Switched back to my old definition Load = 100% * (1.0 - cyclesWithoutInterrupts / cyclesWithInterrupts) , and printed the raw...

Thats right, I calculated the load relative to the time with interrupts, it makes more sense to calculate relative to the time without interrupts. Load = 100% * ( cyclesWithInterrupts / cyclesWithoutInterrupts -...

Here the results for 200kHz interrupt frequency Generated load for T3.6 @180MHz, empty ISR 1 Timer 3% 4 Timers 12% Generated load for T4.0 empty ISR (PR347) 1 Timer 11.8 % (was 18% with old version) 4 Timers...

Borrowed one from work. The following pictures show a simple sequence of digitalWriteFast(HIGH) and digitalWriteFast(LOW),The different measured cycle times obviously do not influence the output frequency. Also there...

Hm, seems to be a Nerd-Processor, highly intelligent inside but reluctant to communicate with the outside world :-)

If the writing to peripherals is really buffered, the buffer needs to be full eventually and the required cycles for a write will get larger. Tested this by doing a growing number of consecutive writes and timed it....

This gets even more weird. First call takes about 120 cycles, repeated calls only 50 cycles. Can it be that there is some caching/buffering active there? -> Writing would be quick (at least from the cycle counter point...

Just opened mine :-) Thanks for fixing this. TeensyStep would have suffered significantly with the slow IntervalTimer...

Great, this brings it down to 2.9% @200kHz Interrupt frequency. Which is better now than the T3.6 (3.8%)

I personally think that a large MAX_PERIOD is not as important as a efficient interrupt handler. For 150MHz MAX_PERIOD would still be some 28s. If you tell me what to change I'll test it.

Looks like more things are unexpectedly slow on the T4 start = ARM_DWT_CYCCNT; digitalWriteFast(LED_BUILTIN,!digitalReadFast(LED_BUILTIN)); end = ARM_DWT_CYCCNT; Serial.println(end - start); takes 119...

Sketch comes from here: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195443&viewfull=1#post195443

Yes, that was solved "with dsb". I originally thought that the observed double interrupts (in my experimental code) might also be the reason for the slow IntervalTimer (calling the ISR twice). However, it turned out...

I don't really know. Maybe it has something to do with the fact that RT10XX have a shared interrupt for all PITs. On the other hand, the "ISR-distribution" code is so small that I can not imagine that it really slows it...

I also changed startup.c according to #1156 and re-run my IntervalTimer performance test from #830. I still get some 18.5% load @200kHz interrupt frequency (3.8% for a T3.6). So, at least for the IntervalTimer I do not...

Sorry for the late response, I was busy with another project on the weekend. You are right, there was a bug in the development branch. I hope I fixed it, can you give it a try (Branch: develop)? Here the code which...

I didn't test your code yet but there are some things to note: First block in loop: Instead of the delay(2000) after the stopAsync you should wait until the motor really stopped (e.g. place a...

Reason is that TeensyStep doesn't provide a method to pass in two arrays of steppers. I assume that your 4 motorSets are supposed to run independently? If so you need to setup a dedicated controller for each set. I.e....

There is a known silly bug in stepcontrol.h line 8. constexpr int MaxMotors = 10; You need to change MaxMotors to n+1 if you need n motors. I.e. set it to 11 if you need up to 10 motors. To do a quick test of...

Really? Using a "precious" 32bit timer/counter for micros? That would definitely eliminate the timer for any other general use. Just thought of using them for TeensyStep instead of the slow T4 Intervall-timers....

With DSB I can go down to a LDVAL of 4 (~2MHz). Polling seems to be slightly slower but whats worse: Polling does not seem to work for all timings. E.g. LDVAL = 5 leads to a double interrupt every 5th ISR call. LDVAL=6...

Perfect, that fixes it. for (int i = 0; i < 4; i++) { if (IMXRT_PIT_CHANNELS.TFLG == 1) // if channel TFLG is set, delete it and generate pulse on pin i { IMXRT_PIT_CHANNELS.TFLG = 1; ...

At the end of the ISR?

I did some more tests on the low performance of the IntervalTimer and found something strange. It looks like the ISR is called two two times in a row. To dig further into this I did a minimal example showing the...

Did another check and plotted LDVAL against the measured period of the timer The T4 "saturates" at about LDVAL=30, i.e. about 1.2 µs -> 830kHz. The T3.6 goes down to about LDVAL = 10, i.e. about 0.5 µs -> 2MHz.

Had a look at the generated code. Due to the printf it optimizes the second loop slightly different from the first loop (probably since it needs dummy outside of the loop for the printf). I copied the printf from below...

Can you post the code you used for that?

That was done with -O3 (fastest). Did check with -O2 (faster) first and found basically the same (T3.6 much better than T4, didn't note the numbers). The compiler can not ignore dummy++ since dummy is volatile. Direct...

I did a quick check of the IntervalTimer performance. Unfortunately results do not look very good :-/ I estimated the processor load by measuring the number of cycles a simple loop takes with the IntervalTimer...

Would it be possible to have the channel member of the IntervalTimer protected instead of private? The old "cast to IRQ_Number" trick doesn't work anymore since the T4 only has one IRQ for all channels.

Nothing changed timer wise. I.e., 1 PIT + 2FTM channels per motor controller. Up to 10 motors per controller.

Here a quick video demonstrating the new speed override feature of TeensyStep. It first accelerates a disk with 4 holes to 1500 rpm and then synchronizes the speed and position of a second motor to the disk by adjusting...

Are you sure that you need a stepper library for speeds below 1s? You won't need acceleration for that low speeds so you can just do something like: ... while(notAtTarget) { digitalWriteFast(stepPin,HIGH) ...

Ups, found it. I had a slightly newer version locally. It correctly includes <cmath> instead of <math.h>. This avoids conflicts with macros defined in wiring.h. Just uploaded the newest version which should fix it.

Which Arduino / Teensyduino version do you use? Compiles here without problem for Arduino 1.8.5 and Teensyduino 1.44. (Of course you need to add to the code from #47, but it looks like you did that. Do you have...

I could implement that for one motor per controller but not for a group of synced motors. I'll try to do that after the final release of the current version. However, for your application (antenna following rocket?)...

See here for the new version with speed override: https://forum.pjrc.com/threads/43491-New-Stepper-Motor-Library?p=193806&viewfull=1#post193806

I finally uploaded a first test version of the new rotational controller https://github.com/luni64/TeensyStep/tree/develop_newRotate . It allows to change the speed of the attached steppers on the fly. While speed is...

Plus you have the libraries from the "Arduino repository". I currently download them directly from the net into the project :-) IMO: this always makes sense since it will keep projects independent from possibly...

Let me explain the constraints: Currently each controller uses its own PIT timer. Since there are only 4 PITs you are limited to 4 controllers. Each controller is able to move up to 10 (this can be increased easily)...

The platform detection was only in develop. Master should be fine.

Disabled the platform detection, should work again in master and development branches.

Sorry, was in a rush this morning. I did some experiments trying to use VisualTeensy to support all boards Arduino supports (via Arduino Builder). Therefore I scanned the Arduino15 folder which contains installed...

AccelStepper requires you to call stepper.run() as often as possible, at least much more often than the step frequency. Due to the delay(5000) in your loop the stepper.run() methods are called only every 5s which will...

I separated the GUI (project VisualTeensy) from the logic (vtCore.dll). vtCore.dll parses board.txt and generates makefiles, vscode.json etc.). Since vtCore doesn't contain a GUI it can easily be built platform...

@turbok: I did a quick workaround and uploaded it to GitHub: https://github.com/luni64/VisualTeensy/releases/tag/0.9.1. Can you give that a try? (please follow the instructions on GitHub). As soon as I find some time,...

Sorry for that, I didn't have much time the last weeks to work on VisualTeensy. Will be difficult to fix it today but I can have a look tomorrow...