Forum Rule: Always post complete source code & details to reproduce any issue!
Page 5 of 7 FirstFirst ... 3 4 5 6 7 LastLast
Results 101 to 125 of 172

Thread: TeensyTimerTool

  1. #101
    Senior Member
    Join Date
    Jan 2014
    Location
    London, UK
    Posts
    109
    Quote Originally Posted by luni View Post
    Checked and can confirm this. There was a bug in the GPT implementation which leads to calling the ISR two times for very fast interrupt service routines. The bug was already fixed but for some reason the fix was commented out. I updated the GitHub repo already, but if you don't want to update you can also add a "DSB" instruction at the end of your ISR.

    Code:
    void tRun(){
      state = 1 - state;
      digitalWriteFast(pin, state);  
      asm volatile("dsb"); // <---------------------------------
      return;
    }

    Alternatively you can do

    Code:
    void tRun()
    {
      digitalWriteFast(pin, !digitalReadFast(pin));  
    }
    which is a little bit less efficient than your code which makes it work as expected.

    THANKs for spotting that!
    Excellent! Im glad my tests have been useful. I will be focusing my attention on the OneShotTimer next as I am curious to see if that might suit my needs better

  2. #102
    Senior Member
    Join Date
    Jan 2014
    Location
    London, UK
    Posts
    109
    A slightly different question:

    Can we be more flexible with the frequency of the clock source? That is to ask, do all the clocks need to be a multiple of the 24MHz master clock, or could I have a 151Mhz clock, for example?

  3. #103
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    Unfortunately I don't know but I'm sure Paul or FrankB can answer this. Anyway, you can have a look yourself here https://www.pjrc.com/teensy/IMXRT1060RM_rev2.pdf You'll find the clock generation info in chap. 13-19...

  4. #104
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,878
    PLL2 is fixed to 528MHZ, the USB PLL to 480MHz. Their PFDs can be changed, but - depends what is connected to them - may influence other peripherals.
    I have no idea what is connected where... (and, in theory, it can change @runtime).

    @Luni: Would be perfect if your lib would consider that (or does it already?)

  5. #105
    Senior Member
    Join Date
    Jan 2014
    Location
    London, UK
    Posts
    109
    Quote Originally Posted by Frank B View Post
    PLL2 is fixed to 528MHZ, the USB PLL to 480MHz. Their PFDs can be changed, but - depends what is connected to them - may influence other peripherals.
    I have no idea what is connected where... (and, in theory, it can change @runtime).

    @Luni: Would be perfect if your lib would consider that (or does it already?)
    If Ive understood the document Luni linked, PLL4 and PLL5 generate pretty much any frequency, but how to use them as a clock source for interrupt generation?

  6. #106
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,878
    They can clock the timers which in turn can generate interrupts.
    If a timer is connected to one of the PFDs, it may be possible to change the PFD setting (but keep in mind that other peripherals may use the same PFD.)

  7. #107
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    ...(and, in theory, it can change @runtime).

    @Luni: Would be perfect if your lib would consider that (or does it already?)
    @Frank: I assume you mean consider the change @runtime to have a correct timer period regardless of the clock setting? No, it currently only takes the 150/24MHz switch for the GPTs and PITs into account. I'm not sure if the cost-benefit ratio of extending this is small enough to dig into it.

    @bloodline: If you found out how to change the timer clock I can have a look if there is a doable way to make that configurable. But, as Frank mentioned, changing the clock might have influence on other peripherals as well.... Generally, the 150MHz clock for the GPTs gives a 6.6ns granularity. I don't know your application but I do not understand how tweaking the clock (150-151 MHz) will solve any problem? Care to explain what you want to achieve?

  8. #108
    Senior Member
    Join Date
    Jan 2014
    Location
    London, UK
    Posts
    109
    Quote Originally Posted by luni View Post
    @bloodline: If you found out how to change the timer clock I can have a look if there is a doable way to make that configurable. But, as Frank mentioned, changing the clock might have influence on other peripherals as well.... Generally, the 150MHz clock for the GPTs gives a 6.6ns granularity. I don't know your application but I do not understand how tweaking the clock (150-151 MHz) will solve any problem? Care to explain what you want to achieve?
    I've avoided reading the technical documents until you linked to them, as these modern uCs are so complex it would take me weeks to understand how their peripherals work... I'll try and work out what registers do what...

    I like to use microcontrollers to interact with and emulate vintage computer hardware, and the systems of the '80s were very tightly bound with their system clocks. If I could have the Teensy running at a perfect multiple of the old hardware clock, it makes life much easier to get timing correct, without having to correct for drift or push the timings to the limit of the spec...

  9. #109
    Hi Luni

    The latest version (downloaded yesterday) will not compile for me without the files src/Teensy/GPT/GPTchannel.h and src/Teensy/TMR/TMRchannel.h being renamed GPTChannel.h and TMRChannel.h respectively.

    Excellent work though. Thanks

  10. #110
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    he latest version (downloaded yesterday) will not compile for me without the files src/Teensy/GPT/GPTchannel.h and src/Teensy/TMR/TMRchannel.h being renamed GPTChannel.h and TMRChannel.h respectively.
    Sorry, fixed and uploaded (v0.1.2). Looks like I finally need to install Linux somewhere to detect those issues. (Was not the first time...)

  11. #111
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    Quote Originally Posted by bloodline View Post
    I like to use microcontrollers to interact with and emulate vintage computer hardware, and the systems of the '80s were very tightly bound with their system clocks. If I could have the Teensy running at a perfect multiple of the old hardware clock, it makes life much easier to get timing correct, without having to correct for drift or push the timings to the limit of the spec...
    Got you, unfortunately I'll be quite busy the next weeks and will hardly find time to read into that...

  12. #112
    Senior Member
    Join Date
    Jan 2014
    Location
    London, UK
    Posts
    109
    Quote Originally Posted by luni View Post
    Got you, unfortunately I'll be quite busy the next weeks and will hardly find time to read into that...
    No problem! Im in the same situation.

    Teensy Timer Tool is really good already, thank you for your efforts. I look forward to any features you are able to add in future

  13. #113
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    Sorry, fixed and uploaded (v0.1.2). Looks like I finally need to install Linux somewhere to detect those issues. (Was not the first time...)
    Ha, despite being a complete Linux noob I actually managed to install the Arduino IDE and Teensyduino on the Win10 Linux Subsystem (WSL) :-).

  14. #114
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,505
    Quote Originally Posted by luni View Post
    Ha, despite being a complete Linux noob I actually managed to install the Arduino IDE and Teensyduino on the Win10 Linux Subsystem (WSL) :-).
    @luni - Interesting on the WSL! I have WSL running here - not sure of IDE install - but couldn't map the USB to actually see a Teensy. If you see that you might start a thread with shortcut to steps for install and connect. Most I've used Linux … was mostly one step then web searches to progress … repeat for more progress.

  15. #115
    Quote Originally Posted by luni View Post
    Ha, despite being a complete Linux noob I actually managed to install the Arduino IDE and Teensyduino on the Win10 Linux Subsystem (WSL) :-).
    You didn't have to install Linux, I don't mind checking for such things (there's probably only me that uses it anyway). It is nice to know you care though.

  16. #116
    Junior Member
    Join Date
    May 2019
    Posts
    9
    I would like to move to TeensyTimerTool from TeensyDelay. I tried HelloPeriodic but the longest periodic callback I can get is ~56ms. When I was using TeensyDelay, I changed the prescaler from 7 to 6. I don't understand if I need to do that with this library or where. I tried creating a userConfig.h file in the sketch directory. In that I set TMR_DEFAULT_PSC to 6, but that didn't affect the period time.

    I am using a Teensy 3.2.

  17. #117
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    The TMR_DEFFAULT_PSC setting is for the TMR timers of a Teensy 4. T3.2s use the FTM timers instead so that won't work. Unfortuantely, I simply forgot to implement this setting for the FTMs... Sorry for that. I try to add the setting for the FTMs tomorrow and post an update on GitHub.

    As a quick workaround you can give the software based TCK timers a try. Just use 'Timer t1(TCK)' in line 19 of the example (see here https://github.com/luni64/TeensyTime...riodic.ino#L19)
    The readme describes the TCK timers here https://github.com/luni64/TeensyTime...k---tick-timer They have a (theoretical) resolution of about 2ns and a max period of about 7s.

  18. #118
    Junior Member
    Join Date
    May 2019
    Posts
    9
    I am setting a OneShotTimer trigger from within the callback of a PeriodicTimer. That isn't working. Is it expected to work?

  19. #119
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    Yes, should work, can you post your code?

  20. #120
    Junior Member
    Join Date
    May 2019
    Posts
    9
    Ah. Simplifying it for the reply led me to discover the mistake I had made and now it works fine. Thank you.

  21. #121
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    Quote Originally Posted by mitchb View Post
    Ah. Simplifying it for the reply led me to discover the mistake I had made and now it works fine. Thank you.
    Perfect, let me know if you need further help

  22. #122
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    Quote Originally Posted by luni View Post
    .. I try to add the setting for the FTMs tomorrow and post an update on GitHub.
    I added the FTM_DEFAULT_PSC setting to override the auto prescaling value for the FTM timers. See here https://github.com/luni64/TeensyTimerTool#configuration for the documentation.

    You can query the TeensyTimerTool timers for their max period as shown here:

    Code:
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    
    PeriodicTimer t1(FTM0);
    PeriodicTimer t2(TCK);
    
    void setup()
    {
        while (!Serial) {}
        TeensyTimerTool::attachErrFunc(ErrorHandler(Serial));
    
        t1.begin([] { Serial.printf("ISR t1 %d\n", millis()); }, 40'000);
        t2.begin([] { Serial.printf("  ISR t2 %d\n", millis()); }, 80'000);
    
        Serial.printf("t1 (FTM) max Period: %.3fs, resolution %.4fs\n", t1.getMaxPeriod(), t1.getMaxPeriod() / 0xFFFF * 1E6);
        Serial.printf("t2 (TCK) max Period: %.3fs, resolution %.4fs\n", t2.getMaxPeriod(), t2.getMaxPeriod() / 0xFFFF'FFFF * 1E6);
    }
    
    void loop()
    {
    }
    Which prints for a T3.2 @96MHz and auto prescaler:

    Click image for larger version. 

Name:	getmaxperiod.jpg 
Views:	14 
Size:	57.0 KB 
ID:	19520
    Last edited by luni; 03-28-2020 at 09:51 AM.

  23. #123
    Quote Originally Posted by luni View Post
    I added the FTM_DEFAULT_PSC setting to override the auto prescaling value for the FTM timers. See here https://github.com/luni64/TeensyTimerTool#configuration for the documentation.

    You can query the TeensyTimerTool timers for their max period as shown here:

    Code:
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    
    PeriodicTimer t1(FTM0);
    PeriodicTimer t2(TCK);
    
    void setup()
    {
        while (!Serial) {}
        TeensyTimerTool::attachErrFunc(ErrorHandler(Serial));
    
        t1.begin([] { Serial.printf("ISR t1 %d\n", millis()); }, 40'000);
        t2.begin([] { Serial.printf("  ISR t2 %d\n", millis()); }, 80'000);
    
        Serial.printf("t1 (FTM) max Period: %.3fs, resolution %.4fs\n", t1.getMaxPeriod(), t1.getMaxPeriod() / 0xFFFF * 1E6);
        Serial.printf("t2 (TCK) max Period: %.3fs, resolution %.4fs\n", t2.getMaxPeriod(), t2.getMaxPeriod() / 0xFFFF'FFFF * 1E6);
    }
    
    void loop()
    {
    }
    Which prints for a T3.2 @96MHz and auto prescaler:

    Click image for larger version. 

Name:	getmaxperiod.jpg 
Views:	14 
Size:	57.0 KB 
ID:	19520
    I was trying same example to check it's working on Teensy 4.0 but I am getting this error.
    'FTM0' was not declared in this scope
    I updated TeensyTimerTools to 0.1.3. Any other library still missing?

  24. #124
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    The FTM timers are only available on the T3.x Boards. Here the List of supported timers: https://github.com/luni64/TeensyTime...pported-Timers

  25. #125
    Quote Originally Posted by luni View Post
    The FTM timers are only available on the T3.x Boards. Here the List of supported timers: https://github.com/luni64/TeensyTime...pported-Timers
    I see ! Sorry for this silly mistake. Now I am going thru the WIKI to understand this library in more detail.

Posting Permissions

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