Will too many interupts will cause the red-light-of-death?
-------------------------------------------------------
It is possible, but is just as easily avoided.
One of the other common misconceptions is that having too high of an interrupt load will starve off user code from executing and result in the red-light-of-death. This is true of the standard IFI code framework but not true of either MBLAB/WPILIB or EasyC environments. Why? Because in these frameworks the Getdata/Putdata calls are performed at interrupt level and not at user level... so as long an one interrupt service routine doesn't take forever to run, the appropriate get/put data will occur and prevent bad things from happening by doing all this in the background. Its also why the main loops look kinda of funky in that they loop forever and don't care how long they take to run. But I'll tackle that one in another reply.
Code:
<within the system clock routine, do...>
if (statusflag.NEW_SPI_DATA != 0)
{
Getdata(&rxdata);
Putdata(&txdata);
}
The high level priority interrupt in the IFI user processor is using the serial SPI bus between the master and itself for exchanging data. This is done by having a double buffer used by the interrupt service routine. The serial transfer of incoming/outgoing data is done simultaneously (read info on the SPI, Section 19.0 in the DS39646B). The Getdata/Putdata just read the new data into the rxdata which the rest of the user code then references for current OI info and writes the current txdata structure that the user has been filling with information to the "open"/next buffer that will be sent once the current buffer has been exchanged with the master processor. The code is available in ifi_library.c in the default IFI project (its not in the list of source files by default, but is in the source directory).
Anyway, doing these operations in the background at interrupt time frees the user code from having to worry about taking too long between updates causing the red-light-of-death.