Time available between NEW_SPI_DATA and Putdata

[ericand]

It is well documented that we need to send data back to the master microprocessor every 26.2 ms and that the data from the master is signaled by the setting of the NEW_SPI_DATA flag.

I would like to know how much time is available between the time the NEW_SPI_DATA flag is set and the Putdata is called, before the Master flags a code error.

The default code says:

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

Default_Routine(); /* Optional. See below. */

/* Add your own code here. */

Putdata(&txdata); /* DO NOT CHANGE! */

But there is no indication of how much time can be taken prior to calling Putdata().

My concern is that NEW_SPI_DATA may become active imidiately following the check for NEW_SPI_DATA. This means that one fast loop execution time may pass before we notice that it is set. Thus we may have more or less time to execute in Process_Data_From_Master_uP() before we are too late to call Putdata().

I think that this is related to our robot seeing intermittant code error conditions. I think that knowing exactly how much time we take (maximum) in our fast and slow loops, we can do a better job of time management and avoid the code error.

[steven114]

I'd say some testing might be in order. I've heard people say it's between a quarter and half a second, maybe more, but I can't vouch for that personally. I'd say that if you're taking more than 26.2ms then you probably need to rethink your design - I'd assume that this means you'd start dropping data packets all over the place. Probably not something you want to do.

[ericand]

Originally Posted by steven114

I'd say some testing might be in order. I've heard people say it's between a quarter and half a second, maybe more, but I can't vouch for that personally. I'd say that if you're taking more than 26.2ms then you probably need to rethink your design - I'd assume that this means you'd start dropping data packets all over the place. Probably not something you want to do.

I'm thinking it is much smaller than that. At most I would expect it to be 26.2ms. What I fear is that the master processor is setting the NEW_SPI
flag every 26.2 ms and assuming that the response will follow the setting
of NEW_SPI by some amount much less than 26.2 ms.

As you say, some testing is in order. We have an interrupt driven clock that we will use to get some numbers for the loop timings. We'll probably use the dashboard to capture the data.

I may need to check to see if we can do something like write the data to the eeprom even if we have been disabled by a code error. That brings up another question,
Can the processor detect when it is disabled by experiencing a code error?

[Eldarion]

Originally Posted by ericand

I'm thinking it is much smaller than that. At most I would expect it to be 26.2ms. What I fear is that the master processor is setting the NEW_SPI
flag every 26.2 ms and assuming that the response will follow the setting
of NEW_SPI by some amount much less than 26.2 ms.

As you say, some testing is in order. We have an interrupt driven clock that we will use to get some numbers for the loop timings. We'll probably use the dashboard to capture the data.

I may need to check to see if we can do something like write the data to the eeprom even if we have been disabled by a code error. That brings up another question,
Can the processor detect when it is disabled by experiencing a code error?

In my testing, it has consistently been half of a second.
An easy way to do this test would be to put a while(1) loop in the main program loop, hit the reset button and see how long it takes before the BLROD comes on.

Good luck!