3.x Availability vs. 4.x and Power Consumption

tkreyche

New member
I've read the announcements on Twitter, Sparkfun etc. about lack of availability of 3.x and suggestions to use 4.x hardware instead.

3.5 is perfect for many of my battery powered projects especially exposing most of the pins. I just don't see how this can readily be replaced with 4.x version regardless of cost, due to increased power consumption. Not to mention overkill for my apps. So I'm reluctantly looking at Sparkfun Artemis, with doubts about their software support vs the superb Teensyduino.

There are some old threads about lowering clock speed to conserver power but I don't see anything recent. What's weird is that every site selling 4.x quotes the "dynamically speed changes" feature but I don't see any solid info about how to do this and what kind of power savings can be experienced.

Did I miss something?

Thanks, Tom
 
I found these two old posts, one of which you were on but I don't see anything conclusive. And what about the advertised "dynamic speed changes" ? There should be more info with an active effort to persuade people to move to 4.x. Ideally comparing a typical 3.x config vs 4.x with some power numbers. A perfect comparison may not be possible there should be something to work with.

https://forum.pjrc.com/threads/5745...onsumption-compared-to-3x?p=214313#post214313
https://forum.pjrc.com/threads/57444-How-to-change-clock-speed-on-Teensy-4-0
 
I found these two old posts, one of which you were on but I don't see anything conclusive. And what about the advertised "dynamic speed changes" ? There should be more info with an active effort to persuade people to move to 4.x

https://forum.pjrc.com/threads/5745...onsumption-compared-to-3x?p=214313#post214313
https://forum.pjrc.com/threads/57444-How-to-change-clock-speed-on-Teensy-4-0

Third post in the second link you gave :) This shows how to set the speed @ runtime. Note, you can't go slower than 24MHz if you need USB.

There are threads about power consumption, too. But don't expect too much savings... you don't buy a Ferrari and expect it needs less than a Smart when driving slowly.
 
In other words, the 4.x is not a great replacement for a 3.x in a battery powered application, especially when power conservation is a major consideration.
 
Ideally comparing a typical 3.x config vs 4.x with some power numbers. A perfect comparison may not be possible there should be something to work with.

Something like this maybe?

Teensy_3vs4_powerdraw.png
 
Anyway, clock speed does not tell the whole story: 4.x are faster than 3.x even at the same clock speed (arch improvements). So you may actually "downclock 4x more" and get the same speed when running real world code, vs. 3.x.
 
4.x quotes the "dynamically speed changes" feature but I don't see any solid info about how to do this and what kind of power savings can be experienced.

Dynamic speed change was a feature I *really* wanted to implement on Teensy 4. There was much talk of it during beta testing which lasted for most of 2019. A lot of work went into core library functions like delay(), millis(), micros() to automatically work even if the CPU speed changes. But a usable dynamic clock speed feature ran into a technical challenge and 2 realities of software development.

The technical hurdle is a lack of glitchless mux for the peripheral clock. NXP gave us those for the main clock. Details can be found in the reference manual. Check out Figure 14-5 on page 1031. Also look at "Divider change handshake" on page 1032. The main problem is we don't have that sort of hardware for IPG_CLK. So if we're running at 600 MHz and we want to drop down to 150 MHz, and keep the peripheral clock stable at 150 MHz, how to properly accomplish that isn't clear. For all the stuff without the glitchless mux and special handshake, all we get in NXP's documentation are things like "To update the PODF value without gating the output clock off will cause unpredictable results such as no clock output".

The software realities are #1: the beta test dragged on for most of 2019. Many planned software features had to be cut or scaled back, otherwise we probably never would have released Teensy 4.0. Dynamic clock was one of those features. Then #2: the pandemic hit in early 2020, just as we were getting Teensy 4.1 into production. PJRC software development basically stalled until mid-2021. I still haven't caught up to a pretty incredible backlog. Dynamic clock change and better support for power saving hardware are still on the wish list, but the honest truth is so many other more important features also need attention, so it's pretty unlikely much work (at least by PJRC) will happen anytime soon on dynamic clock change.

Also to be realistic on the technical side (if number of programming hours in every day weren't an issue), without the handshake protocol on the PODF divider (CBCDR) for IPG_CLK or a glitchless mux to safely switch it to something else while reconfiguring, I'm afraid there may never be a really satisfying and easy to use dynamic clock change. NXP simply didn't put that hardware into the chip for IPG_CLK. So anything we do is probably going to have significant limitations and may require special effort to use, like shutting off all PWM and most timer usage during clock changes. It's also going to be quite difficult to develop and fully test, because a lot of things depend on IPG_CLK.

So today, and for the foreseeable future, the only well supported clock speed configuration is the Tools > CPU Speed menu, which ultimately just controls the number passed to the set_arm_clock() function in clockspeed.c. If you want to experiment with controlling the clock, that function is the place to start.
 
Thanks, everyone for the responses.

The rationale for not pushing further work on dynamic clock change makes perfect sense. The source of confusion is that many sites selling Teensy got a little overamped about promoting the feature.

TeensyBat looks like a poster child for harnessing the power of 4.1 - I'm planning to order a kit and will be curious to see if "up to 48 hrs" of use can be achieved with a 8Ah battery.

Next I'll look into whether 4.1 is a good fit for my more pedestrian data logging type apps.

...Tom
 
I have two clock projects using a Teensy 4.1, and both switch clock speed between 72 MHz and 600 MHz.
The first updates six separate LCD displays as shown here: https://youtu.be/qk0BrwT1yQQ
The Teensy runs at 72 MHz until it has to update a display, then it switches to 600 MHz until the display completes the update. With colon flashes it's only updating once a second, for about 10ms per LCD panel update. At first I used DMA to update the display but I ran into problems. Switching back to synchronous non-DMA updates fixed the problem. There is a GPS unit connected to Serial1. I have not noticed any problem with changing the clock speed and receiving serial data.
The second updates multiplexed Nixie tubes 64-times a second, as shown here: https://youtu.be/IULOLc3xpc0
The Teensy runs at 72 MHz until it has to update the display. The micros() function is called in loop(), and if it's time to update the display the cpu clock is raised to 600 Mhz. When the update finishes the cpu clock is lowered to 72 Mhz. An update has four states, Even Anode for ~10ms, all off for 200us, Odd Anode for ~5ms, all off for 200us. The drivers for the Nixie are connected to individual Teensy pins, I'm not using serial-to-parallel converters so I don't have to clock anything out. As soon as all the digitalwritefast() calls have completed the clock speed is lowered. There is a GPS unit connected to Serial1 and I have not noticed any problems with changing the clock speed and receiving serial data.

The only problem I saw was with async DMA transfers to the LCD panels. Keeping the clock at 600 Mhz until the DMA completed did not fix the problem. The problem didn't show up right away either, it took several hours of running before displays were only partially updated. Switching back to synchronous updates cleared up the problem and I haven't seen a glitch since.
 
Back
Top