Forum Rule: Always post complete source code & details to reproduce any issue!
Page 8 of 9 FirstFirst ... 6 7 8 9 LastLast
Results 176 to 200 of 213

Thread: TeensyTimerTool

  1. #176
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    So that you can #define the YIELD_TYPE before you include the library.
    This pattern only works if you can make sure that all translation units have the define before including the header. The TeensyTimerTool supports project scope config files instead. See here https://github.com/luni64/TeensyTime.../Configuration for instructions

  2. #177
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    85
    Ok, thanks, i will have a look.

  3. #178
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    110
    Quote Originally Posted by luni View Post
    This is due to the new yield code in the beta. I'll fix that the next days. If you need an urgent solution and if you do not need SerialEvents or the EventResponder you can set the yield type to YIELD_OPTIMIZED. See here: https://github.com/luni64/TeensyTime...yield-settings for instructions.
    Thank you.
    I'm not in hurry with this. It was just a feedback.
    Manu

  4. #179
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    Fixed by using the EventResponder to tick the software timers in YIELD_STANDARD mode. This is slightly less efficient than the old version but there always is YIELD_OPTIMIZED mode if you need high efficiency of the software timers. (See here https://forum.pjrc.com/threads/60333...l=1#post243706 for an explanation of the new yield strategy)

    @Manu: would be great if you could give it a quick try (v0.1.10)

  5. #180
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    110
    Hello Luni,

    Thank you for this quick fix. I just downloaded the last release (v0.1.10) and it compile without error. Unfortunately my last project which use Teensy 4.x is at it very beginning and, while I know I'll use TeensyTimerTool, I haven't any current code which use it.
    Anyway, I tested the new release with a teensy 3.2 project and it operate very well.

    Thank you,
    Manu

  6. #181
    @luni:
    What is correct way if I want to stop timer for time being?

    Code:
      myTimer.begin(TimerFunction,10'000); // 10ms
    This used to init timer.

    I tried this to stop this timer but not working out. what is correct way to stop this timer?
    Code:
    myTimer.end(); //Timer Ends here.

  7. #182
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,157
    I have not played with this for awhile, but my guess would be to do: myTimer.stop();

    Which is defined in baseTimer... But again just a guess.

  8. #183
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    Which is defined in baseTimer... But again just a guess.
    Valid guess, but actually this currently is only implemented for the TCK timers. The others silently ignore it. I'm currently working on filling in some missing functionality... As a workaround you can meanwhile simply call begin with a nullpointer as callback. This will effectively stop the timer.

  9. #184
    Quote Originally Posted by luni View Post
    Valid guess, but actually this currently is only implemented for the TCK timers. The others silently ignore it. I'm currently working on filling in some missing functionality... As a workaround you can meanwhile simply call begin with a nullpointer as callback. This will effectively stop the timer.
    Thanks luni,
    Code:
    myTimer.begin([]{int (*pfun) (void) = NULL;},10'000); // 10ms
    worked out.

  10. #185
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    Yes that works, but your code is a bit complicated. You probably noticed that passing a nullptr as function argument compiles but doesn't work since the library catches this as error. So, instead of passing a nullptr you need to pass an empty function:

    Code:
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    
    void empty() {}  // empty function
    
    PeriodicTimer t1;
    
    void setup()
    {
        pinMode(13, OUTPUT);
    
        t1.begin([] { digitalWriteFast(13, !digitalReadFast(13)); }, 75'000); //Blink
        delay(3000);
        t1.begin(empty, 50'000); //stop timer
    }
    
    void loop()
    {
    }
    Or if you prefer lambdas you can define the empty function inline:

    Code:
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    
    PeriodicTimer t1;
    
    void setup()
    {
        pinMode(13, OUTPUT);
    
        t1.begin([] { digitalWriteFast(13, !digitalReadFast(13)); }, 75'000); //Blink
        delay(3000);
        t1.begin([]{}, 50'000); //stop timer
    }
    
    void loop(){}

  11. #186
    Yes,
    I tried with empty function as well. That code I shared also worked. Got it I think the one you suggested looks better.

  12. #187
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    Quote Originally Posted by HallMark View Post
    @luni:
    What is correct way if I want to stop timer for time being?
    ...
    I just added the missing start/stop functionality for the TCK, TMR(QUAD), GPT and PIT timers to the TeensyTimerTool v0.1.11. See here for details and download https://github.com/luni64/TeensyTimerTool/releases

    Quick usage example:
    Code:
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    
    PeriodicTimer t1;
    
    void setup()
    {
        while (!Serial) {}
        TeensyTimerTool::attachErrFunc(ErrorHandler(Serial)); // optional, print errors on Serial
        pinMode(13, OUTPUT);
    
        t1.begin([] { digitalToggleFast(13); }, 50'000); //Blink
    
        delay(2000);  // stop timer after 2s
        t1.stop();
    
        delay(2000);  // restart after 2s
        t1.start();
    }
    
    void loop()
    {
    }
    Now working on a possibility to chain the TMR timers to get 16 / 32 / 48 and 64 bit wide timers.

  13. #188
    Quote Originally Posted by luni View Post
    I just added the missing start/stop functionality for the TCK, TMR(QUAD), GPT and PIT timers to the TeensyTimerTool v0.1.11. See here for details and download https://github.com/luni64/TeensyTimerTool/releases
    Great ! I just realize I am using too old version for this lib. I am using 0.1.7 version. Updating now and going to test this out.

  14. #189
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    IIRC you are using the FTM timers. Forgot to add them in v0.1.11, just pushed v0.1.12 which should work for the FTMs as well

  15. #190
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    110

    Imcompatibility with ILI9341_T3

    Hello Luni

    I found an incompatibility between TeensyTimerTool and Paul's ILI9341_t3.

    When one want to use both libraries in the same sketch, compiler can't complete and throw errors.

    Here is a sample of code that illustrate this :

    Code:
    #include "SPI.h"
    #include "ILI9341_t3.h"
    #include "XPT2046_Touchscreen.h"
    // #include "CAN_T3.h"
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    #define RefreshScreenPeriod 100   // 100 millisecondes
    
    PeriodicTimer AfficherInfo(TCK);
    
    
    void timerRefreshScreen() {
      Serial.println("timer Tick");
    }
    
    
    void setup() {
      Serial.begin (115200);
      while ((!Serial) && (millis() < 750));
      AfficherInfo.begin(timerRefreshScreen, RefreshScreenPeriod * 1000);
    
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
    
    }
    If you comment the "#include "ILI9341_t3.h" it compile. If not, it don't compile.

    Thank you.
    Manu

  16. #191
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    Which board are you using?

  17. #192
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    110
    teensy 3.2

  18. #193
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    It looks like ILI9341_t3 defines a macro "swap" which clashes with standard c++ headers (<functional> in this case). You can work around by including the ILI9341_t3.h after TeensyTimerTool.h. I can not test if it really works but at least it compiles then.

  19. #194
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    110
    Thank you,

    I'll try and let you know

  20. #195
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    I opened a corresponding issue in the ILI9341_t3 repo https://github.com/PaulStoffregen/ILI9341_t3/issues/62

  21. #196
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    110
    I confirm that including TeensyTimerTool before other libraries work.

    However, I think there is a bug with FTM timers and Teensy 3.2 (72Mhz - compile as Faster).
    When I use this as a periodic timer for 100ms, the result is a timer around 57 to 60ms.

    Using the exact same code, but with TCK timer give a robust 100ms without a miss or deviation.

    I tested this with a simple

    Code:
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    #define RefreshScreenPeriod 100   // 100 millisecondes
    
    PeriodicTimer AfficherInfo(FTM0);
    
    
    void timerRefreshScreen() {
      Serial.println(millis());
    }
    
    
    void setup() {
      Serial.begin (115200);
      while ((!Serial) && (millis() < 750));
      AfficherInfo.begin(timerRefreshScreen, RefreshScreenPeriod * 1000);
    
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
    
    }

  22. #197
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    I confirm that including TeensyTimerTool before other libraries work.
    Good, maybe the maintainers of the ILI lib are willing to fix the issue. On the other hand, the workaround is quite simple...

    However, I think there is a bug with FTM timers and Teensy 3.2 (72Mhz - compile as Faster).
    When I use this as a periodic timer for 100ms, the result is a timer around 57 to 60ms.
    No, this is to be expected. The FTMs are 16bit timers and, at standard settings will overflow at about 56ms. TeensyTimerTool detects this, issues a warning and sets the period to the max possible value. You can either check the return value of "begin" or, more easy, activate the built in error handler by adding this line to your setup()

    Code:
    TeensyTimerTool::attachErrFunc(ErrorHandler(Serial));
    The library will then print any error to Serial (or whichever stream object you pass to the ErrorHandler constructor). This is quite useful during development. Here the output of your sketch with activated error handler:

    Code:
    W-100: Period overflow, set to maximum
    421
    465
    509
    552
    596
    640
    683
    727
    771
    814
    858
    See here https://github.com/luni64/TeensyTime...Error-Handling for a documentation of the error handling capabilities of the library.


    If you need longer periods than the standard ~50ms you can change the prescaler of the FTM timer in the config file. See here https://github.com/luni64/TeensyTime.../Configuration for a documentation of this feature.

  23. #198
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    110
    Thank you for this explanation.

  24. #199
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,157
    Quote Originally Posted by luni View Post
    I opened a corresponding issue in the ILI9341_t3 repo https://github.com/PaulStoffregen/ILI9341_t3/issues/62
    Obviously any of us can create a PR to fix this... So I went ahead and did it:
    https://github.com/PaulStoffregen/ILI9341_t3/pull/63

  25. #200
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    997
    Quote Originally Posted by KurtE View Post
    Obviously any of us can create a PR to fix this... So I went ahead and did it:
    https://github.com/PaulStoffregen/ILI9341_t3/pull/63
    Thanks a lot Kurt! I didn't want to create this PR since I can only check if the change compiles but have no means of testing the functionality.

Posting Permissions

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