Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 31 of 31

Thread: Teensyduino 1.56 Beta #2

  1. #26
    Junior Member
    Join Date
    May 2020
    Location
    South East England
    Posts
    11
    Quote Originally Posted by PaulStoffregen View Post
    I don't understand. FreqCount is still included with the installer. Its 3 examples should still be in the Examples menu.

    Not sure what timing constraint you're talking about. On each Teensy model, that library can count at fast as the external clocking of hardware timers allows.

    @Paul
    Thank you for replying to my query.

    My system consists of :
    Teensy 4.1 plus custom PC board and touchscreen.
    Windows 10 PC
    Recently installed Arduino 1.8.15 and Teensyduino 1.56-beta1
    The Library manager indicates I have FreqCount 1.3.0
    I see no FreqCount() examples.

    My application includes a frequency meter for RF purposes up to 60 MHz with a programmable gate period the user can set to any decade value between 10uSec and 10Sec. The input buffering is achieved with a high speed Schmidt trigger and some other routing. The input to the T4.1 is full amplitude and nice and clean.

    The Teensy FreqCount function works well when tested with the original sample code but gives strange results when the period between measurements is made longer than the gate period. The interval between measurements should not influence the value of the measurement.

    With a gate time of 1000 uSec and a delay of 13mSec simulating the other functions a 10MHz input displays 13,0001. (Error)

    With a gate time of 1000 uSec and a delay of 900uSec simulating the other functions a 10MHz input displays 10,000. (Correct)

    The attached code clearly shows the problem I'm experiencing, please see the comments.
    Regards,
    RichardL

    PS: I tried an alternative to delayMicroseconds() just in case that was causing a conflict; no change.

    Code:
    #include <FreqCount.h>
    long FCount;
    
    
    // Frequency measurement gate time which is 
    // user configurable between 10uS to 10Sec.
    long GateTime = 1000;     //Ex: 1000 for a 1mSec gate
    
    
    // uSec taken by several other functions, SD card buffer writes, serial, etc.
    // Typically in range 5 to 15 mSec.
    long SimTime  = 13000;    // Ex: 13000 for a 13mSec aggregate delay
    
    
    // What I see... 
    // With any input frequency between 1MHz and 25MHz. Broadly:
    //    If SimTime > GateTime the value of FCount is in error and looks
    //    like the gate period is controlled by SimTime. 
    
    
    //    If GateTime > SimTime FCount value is OK.
    
    
    void setup() {
      Serial.begin(57600);
      FreqCount.begin(GateTime);  // Gate time is in uSec
    }
    void loop() {
      delayMicroseconds(SimTime); // Simulates lots of other things happening.
      // MyDelay(13);
      if (FreqCount.available()) {
        FCount = FreqCount.read();
        Serial.println(FCount);
       }
    }
    
    
    void MyDelay(long WaitTime){
      unsigned long ExitTime = millis() + WaitTime;
        while (millis() < ExitTime){};
      }

  2. #27
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,241
    Complete aside:
    your MyDelay isn't safe from wraparound, code it like this:
    Code:
    void MyDelay(unsigned long WaitTime){
      unsigned long StartTime = millis();
      while (millis() - StartTime < WaitTime)  // safe at wraparound due to the subtraction.
      {}
    }

  3. #28
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    415
    Quote Originally Posted by MarkT View Post
    Complete aside:
    your MyDelay isn't safe from wraparound, code it like this:
    Code:
    void MyDelay(unsigned long WaitTime){
      unsigned long StartTime = millis();
      while (millis() - StartTime < WaitTime)  // safe at wraparound due to the subtraction.
      {}
    }
    I can't see how that is safe. By way of example lets assume that millis starts at 0, goes to 100 then wraps round to 0 again. I know it doesn't but this is to demonstrate the problem with your code above.
    OK, continuing.
    Let's assume that at the time of entry to the routine that millis is 90 and the long wait time is 30. The spreadsheet below shows what happens.
    There is NO exit from the routine.
    Code:
    Millis	StartTime WaitTime (millis-StartTime) (millis-startTime) <WaitTime
    90	90	  30	        0	              TRUE
    91	90	  30	        1	TRUE
    92	90	  30	        2	TRUE
    93	90  	  30	        3	TRUE
    94	90	  30	        4	TRUE
    95	90	  30	        5	TRUE
    96	90	  30	        6	TRUE
    97	90	  30	        7	TRUE
    98	90	  30	        8	TRUE
    99	90	  30	        9	TRUE
    100	90	  30	       10	TRUE
    0	90	  30	      -90 	TRUE
    1	90	  30	      -89	TRUE
    2	90	  30	      -88	TRUE
    3	90	  30	      -87	TRUE
    4	90	  30	      -86	TRUE
    5	90	  30	-85	TRUE
    6	90	  30	-84	TRUE
    7	90	  30	-83	TRUE
    8	90	  30	-82	TRUE
    9	90	  30	-81	TRUE
    10	90	  30	-80	TRUE
    11	90	  30	-79	TRUE
    12	90	  30	-78	TRUE
    13	90	  30	-77	TRUE
    14	90	  30	-76	TRUE
    15	90	  30	-75	TRUE
    16	90	  30	-74	TRUE
    17	90	  30	-73	TRUE
    18	90	  30	-72	TRUE
    19	90	  30	-71	TRUE
    20	90	  30	-70	TRUE
    21	90	  30	-69	TRUE
    22	90	  30	-68	TRUE
    23	90	  30	-67	TRUE
    24	90	  30	-66	TRUE
    25	90	  30	-65	TRUE
    26	90	  30	-64	TRUE
    27	90	  30	-63	TRUE
    28	90	  30	-62	TRUE
    29	90	  30	-61	TRUE
    30	90	  30	-60	TRUE
    31	90	  30	-59	TRUE
    32	90	  30	-58	TRUE
    33	90	  30	-57	TRUE
    34	90	  30	-56	TRUE
    35	90	  30	-55	TRUE
    36	90	  30	-54	TRUE
    37	90	  30	-53	TRUE
    38	90	  30	-52	TRUE
    39	90	  30	-51	TRUE
    40	90	  30	-50	TRUE
    41	90	  30	-49	TRUE
    42	90	  30	-48	TRUE
    43	90	  30	-47	TRUE
    44	90	  30	-46	TRUE
    45	90	  30	-45	TRUE
    46	90	  30	-44	TRUE
    47	90	  30	-43	TRUE
    48	90	  30	-42	TRUE
    49	90	  30	-41	TRUE
    50	90	  30	-40	TRUE
    51	90	  30	-39	TRUE
    52	90	  30	-38	TRUE
    53	90	  30	-37	TRUE
    54	90	  30	-36	TRUE
    55	90	  30	-35	TRUE
    56	90	  30	-34	TRUE
    57	90	  30	-33	TRUE
    58	90	  30	-32	TRUE
    59	90	  30	-31	TRUE
    60	90	  30	-30	TRUE
    61	90	  30	-29	TRUE
    62	90	  30	-28	TRUE
    63	90	  30	-27	TRUE
    64	90	  30	-26	TRUE
    65	90	  30	-25	TRUE
    66	90	  30	-24	TRUE
    67	90	  30	-23	TRUE
    68	90	  30	-22	TRUE
    69	90	  30	-21	TRUE
    70	90	  30	-20	TRUE
    71	90	  30	-19	TRUE
    72	90	  30	-18	TRUE
    73	90	  30	-17	TRUE
    74	90	  30	-16	TRUE
    75	90	  30	-15	TRUE
    76	90	  30	-14	TRUE
    77	90	  30	-13	TRUE
    78	90	  30	-12	TRUE
    79	90	  30	-11	TRUE
    80	90	  30	-10	TRUE
    81	90	  30	-9	TRUE
    82	90	  30	-8	TRUE
    83	90	  30	-7	TRUE
    84	90	  30	-6	TRUE
    85	90	  30	-5	TRUE
    86	90	  30	-4	TRUE
    87	90	  30	-3	TRUE
    88	90	  30	-2	TRUE
    89	90	  30	-1	TRUE
    90	90	  30	0	TRUE
    Oh, I gave up trying to format the output, but I am sure you can see what happens.

  4. #29
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,308
    Quote Originally Posted by BriComp View Post
    I can't see how that is safe. By way of example lets assume that millis starts at 0, goes to 100 then wraps round to 0 again. I know it doesn't
    And exactly this is your understanding problem. The trick is the unsigned arithmetic.

  5. #30
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,241
    Quote Originally Posted by BriComp View Post
    I can't see how that is safe. By way of example lets assume that millis starts at 0, goes to 100 then wraps round to 0 again.
    integer variables in C are modular, so you need to do the subtraction modulo the relevant power of two. For instance with uint32_t:
    Code:
    millis      start       millis-start
    0xFFFFFFF0  0xFFFFFFF0  0x00000000
    0xFFFFFFFF  0xFFFFFFF0  0x0000000F
    0x00000000  0xFFFFFFF0  0x00000010
    Carry/borrow bits are simply discarded, so the operations are modulo 2^32

  6. #31
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    415
    Ok, Got it. I had to write a small sketch to prove it to myself.
    You learn something new each day. Thanks.

Posting Permissions

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