Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 12 of 12

Thread: Why is F_CPU_ACTUAL still absent on Teensy 3.x?

  1. #1
    Senior Member
    Join Date
    Dec 2016
    Location
    EU
    Posts
    216

    Why is F_CPU_ACTUAL still absent on Teensy 3.x?

    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

  2. #2
    Senior Member
    Join Date
    Dec 2016
    Location
    EU
    Posts
    216
    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.

  3. #3
    Quote Originally Posted by AlainD View Post
    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...l=1#post212642

  4. #4
    Senior Member
    Join Date
    Dec 2016
    Location
    EU
    Posts
    216
    Quote Originally Posted by joepasquariello View Post
    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...l=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.

  5. #5
    Quote Originally Posted by AlainD View Post
    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,

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,348
    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.

  7. #7
    Senior Member
    Join Date
    Dec 2016
    Location
    EU
    Posts
    216
    Quote Originally Posted by PaulStoffregen View Post
    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.

  8. #8
    Quote Originally Posted by AlainD View Post
    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/

  9. #9
    Senior Member
    Join Date
    Dec 2016
    Location
    EU
    Posts
    216
    Quote Originally Posted by joepasquariello View Post
    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.

  10. #10
    Quote Originally Posted by AlainD View Post
    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.

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,348
    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.

  12. #12
    Senior Member
    Join Date
    Dec 2016
    Location
    EU
    Posts
    216
    Quote Originally Posted by PaulStoffregen View Post
    ...
    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 by AlainD; 11-30-2022 at 08:30 PM. Reason: error

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •