[Orborde]

Though not really worried about this, we were interested enough in this problem to actually get some hard numbers on this.

Using this as a guide, and with the help of the C18 library reference, we used the onboard timers to figure out how fast the Process_Data_From_Master_Function ran. Here's (more or less) what we did:

void Process_Data_From_Master_uP(void)
{
  unsigned long int clocks; /* Variable to record the number of clock cycles
                             that the function takes */
  /* If I remember correctly, once the "new data from master processor" flag
     is set, you then have 26.2ms to do your thing and send back data.
     Hence, timing should begin HERE. */

  /* The timer setup given in the IFI white paper is "good enough" for what
     we're doing here. It overflows every 52ms this way, but I figure that
     if this function takes that long, you have bigger problems to 
     worry about (such as the Master processor shutting you down) */
  OpenTimer1(   TIMER_INT_OFF &
                T1_16BIT_RW &
                T1_SOURCE_INT &
                T1_PS_1_8 &            // 1:8 prescaling - important for below
                T1_OSC1EN_OFF &
                T1_SYNC_EXT_OFF );

  WriteTimer1( 0x0000 ) ; /* Supposedly, zeroing the timer after calling 
                             OpenTimer1 isn't necessary, but paranoia is a
                             good thing. */

  Getdata(&rxdata);   /* Get fresh data from the master microprocessor. */

  /* Do your stuff here. Default_Routine() or whatever */

  Generate_Pwms(pwm13,pwm14,pwm15,pwm16);

  /* Read the elapsed time off the timer */
  clocks = ReadTimer1();
  /* Shut off the timer before it does something exciting, such as trigger an
     interrupt */
  CloseTimer1();

  /* Since the timer value was prescaled 1:8, multiply by 8 to get the number
     of clock cycles */
  clocks <<= 3;

  /* This printf takes a non-trivial amount of time, but oh, well. Shouldn't
     be too bad. */
  printf("LOAD: %8lu cycles, %8lu us, %2lu%% load\r",
         clocks, /* Print the raw number of cycles out */
         clocks / 10, /* Each clock cycle is 10^-7 seconds, so a divide by 10
                         will give you the time in microseconds */
         clocks * 100 / 262000    /* Again, since each clock cycle is 10^-7 sec,
                                   the 26.2ms you have translates to 262000
                                   cycles. This prints out a good "percent load"
                                   value for the function, telling you how
                                   close you are to a timeout */
        );

  /* Perhaps the printf should go after the Putdata? */
  Putdata(&txdata);             /* DO NOT CHANGE! */
}

(note: I don't have access to our actual code at the moment, so there may be bugs)

The same treatment can be applied to your autonomous code, as it uses pretty much the same loop.

My line of thinking was that what really matters is how much time it takes for you to take new data from Master and turn it around to produce output.

We haven't really tried much real measuring using this method, but we did find one interesting thing: the Generate_Pwms call takes a whopping 8% of your processing time.

If anyone else has some improvements to make to this method, I appreciate suggestions. When we get around to actually timing some functioning code, I'll post some results here.