This section provides a high level overview of using the priorities on many of the objects in the library.
The SIM interrupt priorities are set as follows:
NOTE: when SCI was priority 7, I got the following error
CPU32Bug> Exception: Unexpected PC=0008BDC2, SR=2700 Format/Vector=0110 CPU32Bug>I assume priority 7 being non maskable may have caused other problems.
Also note, these priorities can cause unexpected results if they are not set correct or you do not program defensively. For instance, a nasty bug was traced back to the priority of SCI being set to 4 whereas the PIT was set as 6 before. When sending data it really doesn't matter if you wait before sending more data, but if you are receiving data, then if you have to wait 5 ms for the oSchedule to finish, then certainly another character will arrive before the last character is retrieved thus generating a SCI internal overflow condition. By putting the SCI priority higher than the PIT, the SCI will interrupt the PIT thus ensuring valid throughput. Note that both the oSchedule and uC/OS-II use the PIT to generate interrupts; thus, these interrupts should be lower (higher priority) than all other time critical I/O interrupts.
I will certainly keep this in mind, if I return to trying SPI or other system generating interrupts--in fact, I should probably disable the PIT during the download to ensure no interference, also because some PIT routines may assume a constant periodic behavior.
Many objects in the library use the TPU. These include the oPWM, oServo, oDCmotor, oEncoder, oDI1_TPU, oSonarDV, and oCompassDV. With so many uses of the TPU, it is important that the TPU is not burdened unnecessarily. This is especially true if you're like me and like using all those I/O pins for simply DIP switches and the like. To enable proper use of the TPU, a priority method was added to objects that use the TPU. The two exceptions are the oSonarDV and the oCompassDV which disable the TPU between readings; these two while reading are, of course, HIGH_PRIORITY. All other objects should have the priority set with the priority method. Usually this should be done right before operation of the object.
For a thorough understanding of TPU priorities refer to the TPU Users Manual, but in short, from a pool of seven time slots, high priority receive four, middle receive two and low receives only one time slot. The details are beyond scope here, but from what I perceive it is best to have your uses prioritized and assign either low, middle, or high priority to each use and spread the objects among the priorities. Technically, if you have 4 middle priorities and 1 low priority and they all request access, then the 1 low priority will get services before the two middle priority (assuming the high priority slots are also in use); thus, you must be aware of the distribution of priorities can affect performance.
Here was the TPU priorities on use in M3 before OOMRM II 0.2;
| Channels in Use | Use | priority | #time slices |
| 1 | speaker (PWM) | MIDDLE_PRIORITY | 2 |
| 2 | channels - dcmotor pins B toggling. (PWM) | MIDDLE_PRIORITY | 4 |
| 1 | keypad (UART) | HIGH_PRIORITY | 4 |
| 2 | eb500 (UART) | HIGH_PRIORITY | 8 |
| 4 | 2 quad encoders (encoder) | HIGH_PRIORITY | 32 |
After redistributing the priorities, the following is now used:
| Channels in Use | Use | priority | #time slices |
| 1 | speaker (PWM) | LOW_PRIORITY | 1 |
| 2 | dcmotor pins B toggling.(PWM) | LOW_PRIORITY | 2 |
| 1 | keypad (UART) | MIDDLE_PRIORITY | 2 |
| 4 | 2 quad encoders (encoder) | MIDDLE_PRIORITY | 8 |
| 2 | eb500 (UART) | HIGH_PRIORITY | 8 |
Note that in the before scenario, since the encoders, eb500, keypad are all high priority, they would in essence round robin in the high time slices. In the "after" scenario, the eb500 UART is almost guaranteed to get a time slice each cycle. With so many channels, only one or two can really be allocated high priority and still be guaranteed a time slice each cycle. Thus, it is best to stick with the practice of having only one or two high frequency devices allocated to the high priorities. Obviously, with most channels high priority it simply becomes a round robin and who gets the time slice is more random.
Previously, all the high priority comm. channels are allocated HMHLHMH If all channels requested service before with 6 high priorities: E1,M1,E2,E3,E4,M1,E5, E6,M2,U1,U2, , Then usarts would wait a complete 1 1/2 cycles before processing. In New: U1,E1,U2,E2,..now receiving uarts should get the first time slices; moreover, it should get 2 in one slice if it needs it.
Although, nice theory, it still was not my problem with the bluetooth UART reliability problem. Conclusion: It apparently had no affect :(
Setup interrupts on TPU as follows:
#ifndef DOS
asm(".global uart_int;uart_int:link %a6,#0");
asm("moveml %a6-%d0,-(%a7)");
asm("jsr uart_handler");
asm("moveml (%a7)+,%d0-%a6");
asm("unlk %a6;rte");
#endif