Forum Rule: Always post complete source code & details to reproduce any issue!
Page 7 of 10 FirstFirst ... 5 6 7 8 9 ... LastLast
Results 151 to 175 of 241

Thread: TeensyTimerTool

  1. #151
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,691
    Quote Originally Posted by luni View Post
    Thanks for spotting this, updated the config documentation. I'll add the ARDUINO_TEENSY41 #define in a later version (need to spot all the relevant places frist)
    Cool. Any current place with _teensy40 should map to also _teensy41 as all the current 4.0 pins are unchanged using the same 1062. Going forward some _teensy41 specific additions may work as it seems few new pins will be added when the board gets two more "edge inches".

  2. #152
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    Thanks, very useful to me that lib. Just integrated into my project.

  3. #153
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,882
    Quote Originally Posted by defragster View Post
    Cool. Any current place with _teensy40 should map to also _teensy41 as all the current 4.0 pins are unchanged using the same 1062. Going forward some _teensy41 specific additions may work as it seems few new pins will be added when the board gets two more "edge inches".
    Just to be clear, all of the normal pins (0-23 external pins) are the same. The first 2 sets of solder pads in the Teensy 4.0 (pads 24-33) do map into the new pins on the outer rows on the Teensy 4.1. However, the pads for the SD card (34-39 in Teensy 4.0) got relocated to pins 42-47 in the Teensy 4.1.

  4. #154
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    Just to be clear, all of the normal pins (0-23 external pins) are the same. The first 2 sets of solder pads (pads 24-33) do map into the new pins on the outer rows. But the pads for the SD card (34-39 in Teensy 4.0) got relocated to pins 42-47 in the Teensy 4.1.
    Confused. Does that mean the printout of the referenced script is not correct for the T4.1? Didn't have a chance to test it with a 4.1 but defragster did generate some data using the script with a 4.1. Here a link to the (maybe wrong?) table https://github.com/luni64/TeensyTime...shes#teensy-41

  5. #155
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    Thanks, very useful to me that lib. Just integrated into my project.
    Glad you like it. Let me know if something is not working as expected. The code base is relatively new, so there still might be some bugs...

  6. #156
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    I just needed a periodic timer with callback and this fits and works perfectly.

  7. #157
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,882
    Quote Originally Posted by luni View Post
    Confused. Does that mean the printout of the referenced script is not correct for the T4.1? Didn't have a chance to test it with a 4.1 but defragster did generate some data using the script with a 4.1. Here a link to the (maybe wrong?) table https://github.com/luni64/TeensyTime...shes#teensy-41
    No, the print out is correct. What I was pointing out that pin #34 and above on the Teensy 4.1 are different pins on the Teensy 4.0.

    On the Teensy 4.1, pin #34 connects to GPIO7_29, and does not have PWM capability. Pin 34 is the second to the last pin on the outside row of pins on the left side (with the USB port facing up).

    On the Teensy 4.0, pin #34 connects to GPIO8_15, and uses the FLEX_PWM1 timer for PWM. On the Teensy 4.0, pin #34 is the first solder pad underneath the Teensy 4.0 on the left side in the first row of solder pads of the Teensy 4.0. That row of solder pads is made for bringing out a micro-SD card reader. On some of the breakout boards for the Teensy 4.0, these pins are brought out so that you could connect your own micro-SD card reader.

    The reason for this is that Teensy 4.1 added 20 more external pins, growing the length of the PCB from 1.4" to 2.4". Of those 20 extra pins, there is a 3.3v and ground pin. Then there are 9 pins on one side, and 9 pins on the other. Paul numbered these pins sequentially. Pins 24-32 on the right side are the same pins that are provided in solder pads in the Teensy 4.0. There is also pin 33 on the left side that is a pin brought out with a solder pad in the Teensy 4.0. This leaves 8 more pins, that on the Teensy 4.1 are numbered pin 34-41.

    In addition to the 48 pins on the edges, the Teensy 4.1 has a micro-SD card reader, similar to the Teensy 3.5/3.6. On the Teensy 4.1, the micro-SD card reader pins uses pins 42-47 for the micro-SD reader.

    Other Teensies have similar pin naming challenges. On the Teensy 3.1, and 3.2 the analog pin in the back row that provides digital to analog conversion (i.e. DAC, it can be used for mono sound output) is pin A14. On the Teensy LC, the DAC pin in the same place is A12, not A14. On the Teensy 3.5 and 3.6, A14 is a normal analog input and digital pin that is on the left end of the Teensy, and the two DAC pins are A21/A22. The Teensy 4.0 does not have an A14 pin, and it also does not have a DAC pin at all. The Teensy 4.1 does have an A14 pin, and it is on the left side. Like the Teensy 4.0, there is no DAC pin.

  8. #158
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    Quote Originally Posted by mstiller View Post
    I just needed a periodic timer with callback and this fits and works perfectly.
    Just noticed that it might not be work exactly perfectly all the time. But i think the issue is, the periodic timer and callback gets called from an interrupt and i modify a shared datastructure in the callback.

    What would be the preferred way to protect this datastructure using teensyduino?

    - disable irqs around the non-callback modifications
    - some kind of mutex? what are available?

    Any suggestions are appreciated.

  9. #159
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    Disabling interrupts when accessing the data structure will certainly work. Maybe the Tick Timers are an option for you? They use the cycle counter for timing and their callbacks don't run in an interrupt context which might remove some complexity...

    BTW: I was also looking for mutexes some weeks ago but didn't find something usable. In case you have more luck I'd be very interested.

  10. #160
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    I used this one:

    https://forum.pjrc.com/threads/24737...ighlight=mutex

    But it did not solve the problems. Maybe i used it wrong, that's possible.

  11. #161
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    You can always check by disabling interrupts when you access the structure. If this doesn't remove the problem it probably is related to something else.

    Thanks for the link, I'll give that a try.

  12. #162
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    I now disabled interrupts around the structure access and so far it looks ok.

  13. #163
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,691
    One thing put into use in Teensy4 micros() code is here : github.com/PaulStoffregen/cores/blob/master/teensy4/delay.c#L67

    Putting this around a block of code will repeat if any interrupt occurs during execution:
    Code:
    #include "arm_math.h"	// micros() synchronization
    uint32_t systick_safe_read;	 // micros() synchronization
    // … systick_safe_read is just a ref var of no consequence
    uint32_t micros(void)
    {
    	uint32_t smc, scc;
    	do {
    		__LDREXW(&systick_safe_read);
    		smc = systick_millis_count;
    		scc = systick_cycle_count;
    	} while ( __STREXW(1, &systick_safe_read));
    // ...
    It works in the case of micros() as all the needed data is just copied to local vars - but must be an updated value if the systick _isr() updates that so the two values are in sync.

    ARM support for this is in the T_3.x and T_4.x MCU's - not sure if I checked the T_LC.

    To get a 'current/atomic' copy of the "shared datastructure" for local use this would work without stopping interrupts. Any interrupt would just cause the copy to repeat. Any data changes like "count++" in that block would also repeat so it may not work for this case if not 'read only'.
    Last edited by defragster; 05-03-2020 at 09:01 PM.

  14. #164
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    ldrex/strex is a good idea, will try. Thanks.

  15. #165
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    That's a nice pattern indeed. Let us know if it works. @defragster: might be something for the WIKI :-)

    Edit: Here some info from ARM how to use it to implement a simple lock http://infocenter.arm.com/help/index.../BIHEJCHB.html (...but I'm not sure if that wouldn't lead to a deadlock if used in an ISR)

  16. #166
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    Actually it looks like i fixed the issue by disabling irqs in the "read/write sd card" section.

  17. #167
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,691
    Just added to p#163 code : #include "arm_math.h" // micros() synchronization

    From the linked github - it is needed to compile.

    The micros() was working close to 40 cycles on average - Paul added the 'asm' and a refinement to prevent 'overflow increment' and that completes in more like 36-38 cycles now.

    Seemed to be effective and indeed a useful pattern without much overhead or bad side effects. interrupts never stopped and only if _isr fires is the code re-runs.

    Funny the linked "4.19. Semaphores and Mutual Exclusives (Mutex) " uses the same pattern. It seems to be the only generally usable one:
    Code:
    Example 7. Simple code for getting a lock
    void get_lock(volatile int *Lock_Variable)
    { // Note: __LDREXW and __STREXW are CMSIS functions
    int status = 0;
    do {
    while (__LDREXW(&Lock_Variable) != 0); // Wait until
    // Lock_Variable is free
    status = __STREXW(1, &Lock_Variable); // Try to set
    // Lock_Variable
    } while (status!=0); //retry until lock successfully
    __DMB();		// Do not start any other memory access
    // until memory barrier is completed
    return;
    }
    Indeed that would keep it safe for change across interrupts - but if locked out would need care not to deadlock. A counter in the loop() could break if failing to get the semaphore were handled.
    Code:
    int get_lock(volatile int *Lock_Variable)
    { // Note: __LDREXW and __STREXW are CMSIS functions
    int status = 0, cnt=0;
    do {
    while (__LDREXW(&Lock_Variable) != 0); // Wait until Lock_Variable is free
    status = __STREXW(1, &Lock_Variable); // Try to set
    if ( ++cnt > 5 ) status = -1;
    // Lock_Variable
    } while (status!=0); //retry until lock successfully
    __DMB();		// Do not start any other memory access
    // until memory barrier is completed
    return status;
    }
    The cnt of retry could be tracked - would a timeout on first while( Lock_Variable ); allow a graceful fail?

  18. #168
    Junior Member
    Join Date
    May 2019
    Posts
    9
    With a Teens 3.2, I am trying to use the new ability to set FTM_DEFAULT_PSC in userConfig.h to change the FTM timer prescaler. But when I run the code you provided to print the max period and resolution, there is no change when I change FTM_DEFAULT_PSC.

    Second question: Is it possible to set the prescaler for the FTM0, FTM1 and FTM2 timers to different values?

  19. #169
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    I'll have a look later today. The second one is a bit tricky but should be possible with some changes in the lib.

  20. #170
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    I implemented the possibility to choose the prescaler for each FTM timer in the config file

    Here the updated config section with some prescaler settings:
    Code:
    ...
    //--------------------------------------------------------------------------------------------
    // Default settings for various timers
    
    // TMR (QUAD)
        constexpr int TMR_DEFAULT_PSC = PSC_128;  // Allowed prescaling values: PSC_1, PSC_2, PSC_4 ... PSC_128, clock = 150MHz
    
    // FTM
        constexpr int FTM_DEFAULT_PSC[] =         // Allowed prescaling values: PSC_AUTO, PSC_1, PSC_2, PSC_4 ... PSC_128, clock = FBUS
        {                                         // (PSC_AUTO adjusts prescaler to get roughly 2 timer ticks per Ás)
            /*FTM0*/ PSC_AUTO,
            /*FTM1*/ PSC_1,
            /*FTM2*/ PSC_64,
            /*FTM3*/ PSC_128
        };
    ...
    Here some test code (Teensy 3.6)

    Code:
    #include "TeensyTimerTool.h"
    using namespace TeensyTimerTool;
    
    OneShotTimer t1(FTM0), t2(FTM1), t3(FTM2), t4(FTM3);
    
    void setup()
    {
        while (!Serial) {}
        attachErrFunc(ErrorHandler(Serial));
    
        t1.begin([] {}); // do nothing. We need to "begin" the timers to print the periods below
        t2.begin([] {});
        t3.begin([] {});
        t4.begin([] {});
    
        Serial.printf("max period: %0.5f s (FTM0)\n", t1.getMaxPeriod(), 5);
        Serial.printf("max period: %0.5f s (FTM1)\n", t2.getMaxPeriod(), 5);
        Serial.printf("max period: %0.5f s (FTM2)\n", t3.getMaxPeriod(), 5);
        Serial.printf("max period: %0.5f s (FTM3)\n", t4.getMaxPeriod(), 5);
    
        t1.trigger(1'000'000); // this will generate an overflow warning
    }
    
    void loop()
    {
    }
    And here the output:

    Code:
    max period: 0.03495 s (FTM0)
    max period: 0.00109 s (FTM1)
    max period: 0.06990 s (FTM2)
    max period: 0.13981 s (FTM3)
    W-100: Period overflow, set to maximum

    In case you are using the Arduino builder, using the user config file needs some preparation first. See here: https://github.com/luni64/TeensyTime.../Configuration (Project Scope Settings) for instructions. For PlatformIO and VisualTeensy it should run out of the box. -> To avoid confusion it might be best do test the new setting by writing them into defaultConfig.h first and if that works test the userConfig.h functionality.

    I'll wait for your feedback before merging this into master.

    EDIT: the code is in branch feature/ftmPrescale

  21. #171
    Junior Member
    Join Date
    May 2019
    Posts
    9
    Quote Originally Posted by luni View Post
    I implemented the possibility to choose the prescaler for each FTM timer in the config file
    It works great. And the problem I asked about was due to using userConfig.h with the Arduino IDE. It works fine in PlatformIO. Thank you.

  22. #172
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    Perfect, merged into master (v0.1.9) and documented in the WIKI

    Thanks for the input

  23. #173
    Senior Member
    Join Date
    Jan 2015
    Location
    France
    Posts
    131
    Hello Luni,

    I've just tried arduino 1.8.13, teensyduino 1.53b1 and TeensytimerTool v1.0.9. From an old project that work well with 1.8.12/1.5.2, with the new environment I have an error when I try to compile =>

    Code:
    D:\Mes documents\Arduino\libraries\TeensyTimerTool\src\Teensy\TCK\TCK.cpp: In function 'void yield()':
    D:\Mes documents\Arduino\libraries\TeensyTimerTool\src\Teensy\TCK\TCK.cpp:72:67: error: 'processSerialEvents' is not a member of 'HardwareSerial'
                     if (HardwareSerial::serial_event_handlers_active) HardwareSerial::processSerialEvents();
    This is with Teensy 4.0 board.

    When using Teensy 3.2 all is OK.

    Thank you,
    Manu

  24. #174
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,210
    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.

  25. #175
    Member
    Join Date
    Apr 2020
    Location
    Germany, NRW
    Posts
    86
    Hi Luni,

    i think the lib could benefit from a

    Code:
    #ifndef YIELD_TYPE
    #define YIELD_TYPE YIELD_STANDARD
    #endif
    So that you can #define the YIELD_TYPE before you include the library.

Posting Permissions

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