Why is F_CPU_ACTUAL still absent on Teensy 3.x?

AlainD

Well-known member
Hi

Probably a stupid question:

Given that Teensy 4.x is out some time and needs F_CPU_ACTUAL.

Why is F_CPU_ACTUAL absent on the Teensy 3.x?

It could be a const with the F_CPU value or even just a #define based on F_CPU.
I thought that const values are stored in program memory and I suppose that 4 bytes aren't a problem there.

Alain
 
Just a reminder.

I can (and will) add it myself on some places, it will be the same as F_CPU. It's seems a bit awkward to me to do it inside user code.
 
Just a reminder.

I can (and will) add it myself on some places, it will be the same as F_CPU. It's seems a bit awkward to me to do it inside user code.

cores\Teensy4\clockspeed.c contains the link below to an explanation by Paul as to why T4.x has the 32-bit variable F_CPU_ACTUAL. T3.x does not need F_CPU_ACTUAL, but if you want to add one for your own programs, you can do that.

https://forum.pjrc.com/threads/57236?p=212642&viewfull=1#post212642
 
cores\Teensy4\clockspeed.c contains the link below to an explanation by Paul as to why T4.x has the 32-bit variable F_CPU_ACTUAL. T3.x does not need F_CPU_ACTUAL, but if you want to add one for your own programs, you can do that.

https://forum.pjrc.com/threads/57236?p=212642&viewfull=1#post212642

I know that the 3.x doesn't need one. But it makes programming for both harder and less easy to read. The easiest method is off course to use F_CPU also on T4.x.
 
I know that the 3.x doesn't need one. But it makes programming for both harder and less easy to read. The easiest method is off course to use F_CPU also on T4.x.
Yes, and Paul explains why it’s necessary. Don’t know what else can be said. F_CPU must be a macro,
 
Generally speaking, public APIs get ported. So when delayNanoseconds() and digitalToggle() were added relatively recently, they were implemented across all Teensy models, even back to Teensy 2.0.

F_CPU_ACTUAL is not considered a public API. That's why it hasn't been implemented on Teensy 2 or 3, and probably won't be.
 
Generally speaking, public APIs get ported. So when delayNanoseconds() and digitalToggle() were added relatively recently, they were implemented across all Teensy models, even back to Teensy 2.0.

F_CPU_ACTUAL is not considered a public API. That's why it hasn't been implemented on Teensy 2 or 3, and probably won't be.

Paul

Is there some way to see what "things" are public API and what NOT?
Is there a public API way to read the actual CPU speed?

I suppose that "ARM_DWT_CYCCNT Cycle counter" is also considered non public and the same question: is there a public API way to read it?


I also think it's very useful to inform people on the forum when they suggest non public API things.

Alain who lost quite some hours with using non public stuff.
 
Is there some way to see what "things" are public API and what NOT? Is there a public API way to read the actual CPU speed?

I'm not sure whether public API means Arduino API, but here is a link to that. It does not include the macro F_CPU or any function to read actual CPU speed. It appears that many Arduino-compatible boards have this macro, but some do not. If you need your code to be cross-platform, even if that only means T3.x and T4.x, you're going to need some conditional blocks that use the platform macros to compile in the correct code for the current platform. You'll see this throughout the many libraries that support both T3.x and T4.x.

https://www.arduino.cc/reference/en/
 
I'm not sure whether public API means Arduino API, but here is a link to that. It does not include the macro F_CPU or any function to read actual CPU speed. It appears that many Arduino-compatible boards have this macro, but some do not. If you need your code to be cross-platform, even if that only means T3.x and T4.x, you're going to need some conditional blocks that use the platform macros to compile in the correct code for the current platform. You'll see this throughout the many libraries that support both T3.x and T4.x.

https://www.arduino.cc/reference/en/

The fact that those variables or defines or functions are non public is of more concern. They could change with each release. Even worse, those are quite often used on the forum, without any warning.
BTW. I prefer functions ;-)

For highResolution timing, windows has 2 functions for it:

bool QueryPerformanceFrequency(&Frequency);
bool QueryPerformanceCounter(&StartingTime);

I remember that those are most of the time CPU counters, but it doesn't has to.

The first is the frequency of the "tick", the second nr of ticks.
 
The fact that those variables or defines or functions are non public is of more concern. They could change with each release. Even worse, those are quite often used on the forum, without any warning.

If something is listed on the Arduino reference page, it won't change without warning. Even if it's not listed, anything relatively fundamental won't change without warning or discussion. If you have followed Teensy, you'll appreciate that Paul is exceptionally diligent about avoiding breaking changes, and if that does occur, it would be noted in the release notes for that version of TeensyDuino. For timing, Arduino has millis() and micros(), which are standard functions.
 
The situation with public APIs is less than ideal. Many useful things can only really be accomplished by hard-coding low level stuff.

But more importantly, the conditions today are far from good for considering new APIs or expanding existing ones. We're in the middle of a global semiconductor shortage and many other supply chain disruptions. For products like Teensy, today the vast majority of available engineering time is going into managing supply chain problems.

APIs are not like software implementation, where bugs can be fixed later. Once an API is officially published and people write code which depends upon it, any change becomes quite difficult. Poorly considered APIs often result in a lot of bloat or poor quality workarounds to maintain backwards compatibility.

But new APIs are possible. Over the years, Teensy has added many APIs beyond Arduino's baseline. And in the future, more are likely. Near the top of my wish list is the generic function/member/lambda callback class for non-blocking I/O we've discuss a few times this year. But right now, with component shortages and work ongoing to revise PCBs for alternate parts, the sort of very careful consideration just isn't feasible

You are of course welcome to discuss ideas for APIs. I probably will save well considered proposals. Just please do so with the realistic expectation that little or no new API changes are likely to happen until you see Teensy continuously in stock at all major distributors.

But long term, yes, we do need more complete API coverage. The entire Arduino ecosystem has long needed this.
 
...
APIs are not like software implementation, where bugs can be fixed later. Once an API is officially published and people write code which depends upon it, any change becomes quite difficult. Poorly considered APIs often result in a lot of bloat or poor quality workarounds to maintain backwards compatibility.

...

But long term, yes, we do need more complete API coverage. The entire Arduino ecosystem has long needed this.

To be clear:

I was in the understanding that F_CPU_ACTUAL was part of an "official API", otherwise I wouldn't spend time on it.
I'm not a fan (to say the least) to make variables public, even if const. I prefer helper functions.
Unfortunately the arduino system is not always that "clean".

I can follow #defines to notice the availability of certain functions, it can make the resulting code base smaller and avoiding "complex" workarounds if certain functions are not available (for whatever reason.)
 
Last edited:
Back
Top