Propeller C language: Why rc_time max = 249,987?

Comments

• JasonDorie Posts: 1,930

  2016-04-15 18:54

  This is the code in the simple libs:

  long rc_time(int pin, int state)              // rcTime function definition
  {
    long tDecay;                                // Declare tDecay variable
    int ctr = ((8 + ((!state & 1) * 4)) << 26); // POS detector counter setup
    ctr += pin;                                 // Add pin to setup
    long tf = st_timeout;                       // Set up timeout - *** this line sets the maximum ***
    long t = CNT;                               // Mark current time
    if(CTRA == 0)                               // If CTRA unused
    {
      CTRA = ctr;                               // Configure CTRA
      FRQA = 1;                                 // FRQA increments PHSA by 1
      input(pin);                               // Set I/O pin to input
      PHSA = 0;                                 // Clear PHSA
      // Wait for decay or timeout
      while((input(pin) == state) && (CNT - t <= tf));
      CTRA = 0;                                 // Stop the counter module
      tDecay = PHSA/st_iodt;                    // Copy result to tDecay
    }
    return tDecay;
  }
  
  /**
   * @brief Clock ticks in a time increment used by pulse_in, pulse_out, and rc_time.
   * Default value is the number of system clock ticks in 1/4 s = CLKFREQ/4.
   */
  extern int st_timeout;
  

  
  It looks like there's an st_timeout value that's part of the simple libs, and that is what's setting the maximum time. Because of the way RCtime works, if you had nothing connected at all, the decay would take (more or less) forever, so it has to be bounded somewhere. How long it takes in practice depends on your specific R/C circuit values, so having a timeout value that can be changed might be useful.
  
  249987 is really close to 250,000 so my guess is that they're returning the answer in microseconds, and that would be 1/4 second.
  
  Also, the Prop typically uses 32 bit ints, so values in the range of +/-2,147,000,000 ish.
  
• John Kauffman Posts: 653

  2016-04-15 23:10

  Thanks, Jason. I appreciate your observation that it could be changed in the strange case that I could not keep an RC under that time limit.