# Micro-Satellite Systems Design, Integration, and Flight
## 3 ChipSat RTOS and RF Development
### Switching to a Code-Based RTOS Structure  
Code Composer Studio (CCS), a Texas Instruments coding platform that uses C++, was used to program the TI launchpads.  
Writing RF code without an operating system (OS) or scheduler was not feasible because it depends on a sequential order of code execution. It would have been impossible to give tasks the appropriate priority. For instance, if you had two tasks, stabilize and transmit, you would need to stabilize first before transmitting. Without an OS or scheduler, you would have to place one task above the other in the code sequence. But if these tasks run at different times, sharing resources becomes complex. Therefore, an OS, or  
Figure 11: (**a**) Configuring the PacketTX in SmartRF Studio 7. (**b**) Configuring the PacketRX in SmartRF Studio 7.  
scheduler, is needed. The OS, or scheduler, assigns a priority to each task and schedules them accordingly. A common type of OS or scheduler is the real-time OS, or RTOS. In CCS, the RTOS is called TI-RTOS. The TI-RTOS scheduler has four main levels of priority. If a higher-priority operation is scheduled during any operation, the OS or scheduler will pause the current operation and switch to the higher-priority one. The highest level of priority is the hardware interrupts (hwis). The priority among the hardware interrupts is determined by the semiconductor used. When a hwi finishes executing, the scheduler will resume the next highest hwi.  
If there are no more hwis, the scheduler will move to the next level: software interrupts (swis). The swis execute in a similar way. However, the priority is set in the software. There are 32 different levels of priority available.  
If there are no hwis and swis, the scheduler moves to the task thread. The task thread is where the normal tasks are performed. Normal tasks would include acquiring GPS data, IMU data, or RF tasks. There are also 32 levels of priority in the task thread.  
The lowest level is the idle mode. The idle mode only happens when there are no interruptions or tasks. In this mode, there is no priority level, and low-level background computation is performed. The idle mode is used to keep track of time, run low-priority background programs, and check for hwis, swis, or tasks. Mainly, the idle mode is used to save energy. Figure 12 below shows a summary of the scheduler priority levels.  
The task mode also has its own scheduler. The internal scheduler lets programs run at the same time but limits resources or time-sets for data collection. A semaphore is used to manage tasks properly. The semaphore keeps track of how many tasks are performed using a resource, controls the use of the resource, and keeps a queue. There are two types of semaphores: a binary semaphore and a counting semaphore. The binary semaphore only lets one task run at once. When the binary semaphore is equal to 1, the resource is free. After a task takes the resource, a semaphore pend is posted. The pend subtracts one from the semaphore, making it zero, and blocks the channel. When the task finishes using the resource, a semaphore post is posted. The post restores the semaphore count, making the resource available again. The ChipSat uses a counting semaphore. The counting semaphore works like the binary semaphore, but it allows for \(n\) different tasks to access a resource at once. The semaphore is initialized at \(n\). Tasks can post and pend to the semaphore in the same way as in a binary semaphore, but when the semaphore is less than 1, the resource is blocked. See the flowchart below in Figure 13. The counting semaphore allows for a task to time out. A message is then sent to timeout bypass to skip the next task in the queue. The timeout bypass is shown by the dotted line in Figure 13.  
The following APIs are for posting and pending to a semaphore in the TI-RTOS kernel. See Figure 14 below.  
Figure 12: TI-RTOS kernel priority levels. Image Credit: TI [34].  
The RTOS structure enables smooth transitions between sensors and actuators on the ChipSat.