6 System Processes Keyboard Command Decoder CRT Display... 26

Transcription

1 Contents 1 INTRODUCTION 5 2 GLOBAL INFORMATION Process States Message Types Kernel Control Structure Process Control Block Interprocess Communication System Queues and Ordered Data Memory Map Global Functions Primitives send message receive message request memory block release memory block release processor delayed send set process priority get process priority Software Interrupts 21 5 Hardware Interrupts 22 6 System Processes Keyboard Command Decoder CRT Display User Processes Set Priority Command Wall Clock Display Null Process Test Process A Test Process B Test Process C I-processes Timer I-process UART I-process

2 9 Initialization Implementation Plan 36 2

3 List of Figures 1 RTOS Component Overview High level memory map Process states and transitions Interprocess communications Keyboard command decoder state diagram I-process states

4 List of Tables 1 Kernel control structure fields Process control block fields Message envelope fields Wall Clock Commands Initialization table format

5 1 INTRODUCTION A real time operating system is to be developed supporting pre-emption, five process priority levels, memory management, timing services and inter-process communication. The operating system core consists of a small kernel with several primitives available to all processes. Running on this kernel are two system processes, two I-processes and some test user processes. The relationships between the kernel and processes are depicted in Figure 1. Figure 1: RTOS Component Overview The system will be implemented in ANSI C, and will be compiled and debugged with GNU C utilities. 5

6 2 GLOBAL INFORMATION 2.1 Process States Processes may take on the following states: RUNNING This state indicates that the process is running, or was the last user process to run before the kernel was given the processor. READY This state indicates that the process is not blocked and is ready to execute the next instruction. Processes in this state appear in a ready queue for the scheduler. BLOCKED ON MEM Processes in this state are blocked waiting for memory to be returned to them by the operating system. Processes in this state appear in a queue. BLOCKED ON MSG The process is waiting for a message from another process. Processes in this state are not stored in any queue. 2.2 Message Types The following message types will be associated with system messages: KEYBOARD INPUT The UART creates this message type for the KCD process. The message body contains a single ascii character of keyboard input for the KCD. KCD REGISTER Processes send messages with this type to the KCD process to register themselves as KCD message handlers. The message body contains an ascii character that will be associated with the process. That is, the process will become the message handler for commands prefixed by KCD MSG Messages of this type are sent from the KCD to a registered message handler process. The message body of these messages is a null-terminated string, as inputted by a user. TEXT MSG Processes send CRT messages to the CRT process to display a character or string to the screen. The message body contains a null terminated string. The CRT can also forward these messages to the UART i-process. OTHER MSG All other process-specific messages. 2.3 Kernel Control Structure This data structure is visible to all kernel primitives. It has the fields described by Table 1. 6

7 Table 1: Kernel control structure fields. Type Name Description This is a pointer to the process that is currently PCB * Running process executing (or was executing when it called a primitive.) This is an array of ready queues. Each Queue [5] Ready queue pointers ready queue stores pointers to the PCBs of ready processes of a given priority. For example, the first ready queue corresponds to all ready processes of the highest priority. This is a queue of all processes that are Queue Blocked on memory request blocked waiting for memory. Queue that the timer interrupt process Queue delayed send queue will check. This is a priority queue with respect to delivery time. A time variable that is incremented every int System time millisecond. This is an array of pointers to the PCBs of all of the processes in the system. Since we PCB *[8] Process table know that the RTX will have exactly eight processes, this array can be of a fixed size. Furthermore, the array indices correspond to the PIDs of each process. This is an array of integers used for memory management. The meaning and use int * Memory manager table of this table is described in more detail in the memory management section of this report. 2.4 Process Control Block The Process Control Block (PCB) is essentially an internal representation of a process. It is used to support scheduling and save/restore of process state. The PCB has the fields described by Table Interprocess Communication Interprocess communication in the RTX is achieved through a simple message passing protocol, implementing an asynchronous send and blocking receive. To send a message, a process must request a memory block from a shared pool of memory locations and cast the memory to a Message Envelope structure. The process must then set the message type and message data fields, and call the send message or delay send primitives to deliver the formatted 7

8 Table 2: Process control block fields. Type Name Description This field is used by the kernel to support PCB * Next PCB pointer the queuing of PCB structs. This field will point to the next PCB in a given queue. int Process ID The unique identifier of this process. The kernel assigns this to the process at initialization. int Priority The priority of the process. enum State The state of the process. char * Stack pointer A pointer to the stack of the process. Place to save the 8 Coldfire data registers int[8] Data registers when the process is not running. Place to save the 8 Coldfire address registers when the process is not running. int[8] Address registers A queue of all messages that have been Queue Message queue sent to this process that have yet to be examined. This is a pointer to message or memory void * Generic pointer block returned by the kernel after certain system calls. This field is needed to facilitate returning data from the system primitives (since return values cannot be returned directly from ISRs.) message. It is assumed that the process will enforce its own formatting rules. A process must then call receive message to get the message, and release the memory after processing the message. The message envelope format is shown in Table 3. Table 3: Message envelope fields. Type Field name Description void* Kernel pointers Used by kernel for message queues. int Sender process ID PID of process sending the message. int Destination process ID PID of process to receive the message. int Message type Process-specific field A value indicating the time this message int Time stamp was sent, using the RTX clock. An optional value that can be used to indicate int Delivery time stamp when this message should be deliv- ered (set by the delayed send primitive.) char[64] Message data Message data for use by process. 8

9 2.6 System Queues and Ordered Data The following queues and ordered lists are used by the kernel: Ready Process Queues There are 5 FIFO ready process queues (RPQs) in the system. Each queue corresponds to ready processes of a given priority. These queues are used by the scheduler. Blocked on Memory Queue This is a FIFO priority queue of processes that are in the BLOCKED ON MEM state waiting for a free memory block. PCBs in this queue are sorted by priority. Message Queues Each PCB has a queue of unread messages received from other processes. Sorted Delay Send List This is a sorted linked list of all messages that have been scheduled to be sent in the future with the delayed send primitive. Messages in this list are sorted according to the order in which they should be delivered. Registered KCD Handler List This is a linked-list of all processes that have registered themselves as KCD message handlers. 2.7 Memory Map Figure 2 depicts the memory map of the system. Since the size of each section in the map is not known at this time, no fixed addresses have been provided in the figure. 0x OS Code... System variables/structures... Process Control Blocks... Stacks... Memory Blocks 0x Free Memory Figure 2: High level memory map. 2.8 Global Functions Context Switching functionality In case of software/hardware interrupts, a context switch will occur. sequence of all steps required for a context switch: The following is a 1. software/hardware interrupt occurs (keyboard press, TRAP, etc...) 9

10 2. exception stack frame is saved on top of the A7 stack (A7 at this point is still pointing to the top of process stack of the interrupted user process) 3. save A[0..7] and D[0..7] registers into the PCB of current process also save the value of A7 to the stack pointer field of the PCB 4. load kernel stack into A7 5. perform ISR/Primitive functionality 6. call schedule() to set current process state to ready, enqueue it into the ready priority queues at the end of it s priority list, set the highest ready process to current process, set current process state to executing and call process restore() 7. process restore() method restores the current process A[0..7] and D[0..7], restores the current process stack pointer to A7, then executes the RTI to restore the exception stack frame from the top of user process stack void schedule() This primitive is called whenever the executing process must be switched. This will happen when a hardware interrupt occurs or a software interrupt is triggered (a primitive was called). It calls the scheduler to determine which process has the highest priority to execute next and does a context switch so that the next process can execute. set current_process state to ready enqueue current_process back into priority queues current_process set to the highest priority process in the ready queue set current_process state to executing call context_switch for current_process void process restore(pcb Object* current process) restore A[0..7] and D[0..7] registers for current_process restore the process stack pointer into A7 RTI to restore the exception stack frame from the top of process stack 10

11 3 Primitives Memory Management The kernel will maintain 128-byte blocks of memory that user programs can request by calling request memory block(). The number of blocks maintained is exactly 64, and not configurable. Each of the 128-byte blocks will be preallocated in a contiguous chunk of memory, shown in the memory map diagram, Figure 2 on page 9). The kernel will maintain a memory management table that will be used to determine whether a block has been allocated or not. The table will be of size n/16 words where n is the total number of 128- byte blocks available in the system. Each bit of each word in the table indicates whether a block has been allocated. The following simple function maps flags to memory blocks: char * mem_block = first_block + (memtableidx << 5 + bit) * send message Function Header: int send message (int pid, char * message envelope) Arguments: pid integer value corresponding to the process ID of the receiving process. message envelope character pointer to the message block containing the sent message. Return Value: int value; zero if successful, error flag (non-zero) otherwise. Functional Overview: This primitive delivers a message carried in a message envelope to a destination process. Effects on Processes: Send message effects the PCB of the receiving process. All messages sent to a process via this primitive will enqueued in the receiving process PCB. The state field of the process may be changed from BLOCKED ON MSG to READY. 11

12 Effects on System: A process that is in the BLOCKED ON MSG state will not be stored in any queue explicitly. When send message is called, the pid parameter is used to lookup the destination process, so a queue is unnecessary. If the receiving process is blocked waiting for a message the invocation of this primitive will move it to the ready queue of appropriate priority. Data Structures: See the memory table for message blocks explained above. Pseudocode: int send_message ( int pid, char* message_envelope ) mask interrupts save previous process state (save stack pointers etc.) set sender process id, and destination process id fields in the message_env convert pid to destination process to target_process ptr enqueue message_env onto the msg_queue of target_process if (target_process is in blocked on received state) set target_process->state to ready move the PCB from the blocked queue to a corresponding (priority) ready queue end if call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts 3.2 receive message Function Header: char * receive message() Arguments: None. Return Value: returns a character pointer to the message envelope (message block) that was sent by another process from the FIFO queue 12

13 Functional Overview: Processes invoking this primitive may block (blocking receive). This is a blocking receive. If there is a message waiting, a pointer to the message envelope containing it will be returned to the caller. If there is no such message, the process blocks and another process is scheduled Effects on Processes: Checks the RECEIVED MSQ QUEUE in the PCB of invoking process to see if there are any messages for the process. This primitive will dequeue a message from the queue and return it to the caller if there are any messages available. If there are no messages then the invoking process will block, and the pcb state variable will change to BLOCKED ON MSG. Effects on System: If a message is not ready for the invoking process, the process will be removed from the running state and moved into a BLOCKED ON MSG state. Processes in this state are not stored in a scheduling queue (as explained above). I-process Functionality: I-Processes invoking this primitive may not block. Instead null will be returned to an invoking I-Process if no messages are available. Data Structures: See the memory table for message blocks explained above Pseudocode: char * receive_message() mask interrupts save previous process state (save stack pointers etc.) if (invoking process message queue is empty) if (invoking process is an I-process) return null else set process_pcb.state to BLOCKED_ON_MSG else pcb.received_message <- dequeued envelope from the process message queue if (invoking process is an I-process) return to I-process 13

14 else call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts 3.3 request memory block Function Header: char * request memory block() Arguments: None. Return Value: Returns a character pointer to the memory block successfully allocated to the calling process. Functional Overview: This primitive returns a pointer to a memory block to the calling process. If no memory block is available, the calling process is blocked until a memory block becomes available. If several processes are waiting for memory, the allocation of memory blocks is awarded to a blocked on memory process with the highest priority. Effects on Processes: When a memory request is made the primitive will check to see if a memory block is available. If the block is available, the received messages pointer of the PCB will be set to point to the available block (in the isr). This memory location will also be returned to the caller. If there are no memory blocks available for the process, the process state variable will be set to BLOCKED ON MEMORY REQUEST. Effects on System: If the primitive cannot locate a memory block to return to the process, then the process will be moved into a blocked memory queue. I-process Functionality: If there are no memory blocks available for the I-process, an error will be generated, as an I-process cannot block (return null). 14

15 Data Structures: See the memory table for message blocks explained above. If there is no memory available, the calling process is placed on the blocked queue. The queue is sorted by priority to ensure the highest priority process receives the next memory block that becomes available. Pseudocode: char* request_memory_block() mask interrupts save previous process state (save stack pointers etc.) find available block for each index in memory_lookup_table if (memory_lookup_table[index] has at least one zero bit flag) bitflag <- getnonzeroflag(memory_lookup_table[index]) set bitflag(memory_lookup_table[index], bitflag, 1) pcb.received_messages<- mem block corresponding to (idx,bitflag) mapping if (free block could not be found) if (I-process) pcb.received_messages<- null else set target_process->state to BLOCKED_ON_MEMORY_REQUEST move the process into BLOCKED_ON_MEMORY_REQUEST queue. call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts // if this process is preempted, next time it gets the processor, the // following line of code will execute: return (pcb->received_message) 3.4 release memory block Function Header: int release memory block ( char * memory block ) Arguments: char * memory block character pointer to the message envelope to be released 15

16 Return Value: int value; zero if successful, error flag (non-zero) otherwise. Functional Overview: This primitive returns the memory block to the RTX. If there are processes waiting for a block, one of the blocked processes at the highest priority level is unblocked. The caller of this primitive never blocks, but may be preempted. Effects on Processes: Whenever calls to this primitive result in the released memory block being assigned to a blocked process, the PCB of the blocked process will be modified. The state of the blocked process will be changed from BLOCKED ON MEMORY REQUEST to READY. Also the pcb.received message field will be set to point to the memory block. Effects on System: Whenever this primitive is invoked, the RTX will check the BLOCKED ON MEMORY- REQUEST queue. If the queue is not empty then the highest priority process will be unblocked and the memory block being released will be assigned to the previously blocked process. I-process Functionality: Invoking I-processes may not be preempted. Data Structures: memory block this data structure is returned to the operating system or passed to a blocked process. BLOCKED ON MEMORY QUEUE as discussed above, if there are processes waiting for memory, a memory block is passed to the highest priority blocked process. This process is dequeued from the BLOCKED ON MEMORY QUEUE and inserted into the appropriate ready queue READY QUEUES if a process is removed from the BLOCKED ON MEMORY QUEUE, it is placed onto this queue. Pseudocode: int release_memory_block( char* memory_block ) mask interrupts save previous process state (save stack pointers etc.) 16

17 if a process, p is in BLOCKED_ON_MEMORY_REQUEST queue set p->receive_message to memory_block move p to appropriate READY queue set p->state to READY else convert memory_block to i = (index, bit) mapping into memory table set bit flag at i to 0 if (calling process is an I-process) return to I-process else call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts return 0 if successful otherwise error 3.5 release processor Function Header: int release processor ( ) Arguments: None. Return Value: int value; zero if successful, error flag (non-zero) otherwise. Functional Overview: Control is transferred to the RTX, the calling process is voluntarily releasing the processor. The invoking process is made ready and a new process (possibly the same) is scheduled. Pseudocode: int release_processor() mask interrupts save previous process state (save stack pointers etc.) if the invoking process is an iprocess then set its state to waiting_for_interrupt call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts return 17

18 3.6 delayed send Function Header: int delayed send ( int pid, char * memory block, int delay ) Arguments: pid integer value corresponding to the process ID of the receiving process. memory block character pointer to the message envelope delay integer value in milliseconds for the elapsed delay before sending the message Return Value: int value; zero if successful, error flag (non-zero) otherwise. Functional Overview: The invoking process does not block. The message (in the memory block pointed to by the second parameter) will be sent to the destination process with the given process id after the expiration of the delay which is given in milliseconds. Data Structures: memory block message envelope will contain additional fields for the timer process ID and the delay time in the message. For all other cases these fields will be set to a predefined default value since they will be irrelevant. delayed send queue queue that the timer interrupt process will check. This is a priority queue. Pseudocode: mask interrupts save previous process state (save stack pointers etc.) envelope = request_memory_block() setfields of envelope get current time and construct absolute time for timer interrupt. Every single message has a field in the header for the absolute time that the message needs to be sent at. Enqueue it into the global delayed_send_queue call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts return 18

19 3.7 set process priority Function Header: int set process priority ( int pid, int priority ) Arguments: pid integer value corresponding to the process ID of the process to be changed. priority integer value corresponding to the new priority of the process (0 through 3.) Return Value: int value; zero if successful, error flag (non-zero) otherwise. Functional Overview: This primitive sets the priority of the process with the given process id the given value. A process may change its own priority. The priority of the null process may not be changed, and no other process may be set to the lowest priority (4). I-process Functionality: The priority of an I-Process cannot be modified or changed. This is an error that should be handled gracefully. Data Structures: PCB the PCB of the process will be altered. Specifically, the priority field will be set to a new value. Pseudocode: int set_process_priority( int pid, int priority ) mask interrupts save previous process state (save stack pointers etc.) if (priority > 3 or priority < 0) return -1; if ( currentprocessid!=null processid ) find PCB for pid and change its priority resort the ready_queue to correspond to the new priority call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts restore interrupts 19

20 3.8 get process priority Function Header: int get process priority ( int pid ) Arguments: pid integer value corresponding to the process ID of the process to be looked up. Return Value: Integer value corresponding to the priority of the looked up process (0 through 4.) Functional Overview: This primitive returns the priority of the process specified by the parameter. For an invalid process id, the primitive returns -1. Pseudocode: int get_process_priority( int pid ) mask interrupts save previous process state (save stack pointers etc.) if (pid_exists) find PCB for pid return its priority else return -1 call schedule() ( implicitly calls process_restore() ) do RTI and unmask interrupts 20

21 4 Software Interrupts The RTX will make extensive use of software interrupts (traps) to facilitate the execution of kernel primitives in supervisor mode. Whenever a user process makes a call to one of the kernel primitives, the primitive will be responsible for trapping on a predetermined kernel entry trap vector number. The code corresponding to the trapped vector will execute in kernel mode. The assembly code for this operation is: move.b #operation_code, D0 trap #kernel_trap_vector Context switching occors as outlined in section 2.8 on page 9. The ISR cannot directly return values to the calling process, and so pre-defined memory locations (ex. In the PCB of a process) will be used for this purpose. 21

22 5 Hardware Interrupts Our system will use two hardware interrupts during execution. Hardware interrupts are required for serial I/O and the system timer. Serial I/O interrupts (the UART) will handle input from the keyboard and output to the monitor. The keyboard character input will be passed on to the I-processes to handle the input instructions while the output will be received from the originating processes and passed on to the monitor. A system timer interrupt will be set up to occur every time a delay message has met its delay time. The two possibilities that will use the timer via delay message are the wall clock process and the delayed send primitive. The timer and serial interrupts will be handled by I-processes. These processes will be invoked from the interrupt handler routines in the same way that regular processes are invoked, complete with appropriate context switching and register backup. Blocking primitives that can be called from within I-processes are modified to ensure that they do not block in this case since I-processes are not allowed to block. In case of the timer interrupt, the timer count and reference register will be reset, a timer I-process will be scheduled and a context switch will be performed. Once the timer I-process is running, it can easily send the delayed message and update the delay message queue before releasing the processor. Once the hardware interrupts are handled the corresponding I-process will invoke the release processor primitive to allow other processes to execute. Interrupt handler routines and I-processes are non-interruptible so interrupts will be masked when entering the handler and the appropriate level of atomicity will be restored once the process that was preempted by the I-process is returned to execution. 22

23 6 System Processes Processes may take on any of the states defined in Section 2.1. A full state diagram is shown in Figure 3 on page 23. Figure 4 shows a complete diagram of interprocess communications in the RTX. Figure 3: Process states and transitions. 6.1 Keyboard Command Decoder The KCD process interprets characters entered by the user at the terminal. If the string matches a command registered by another system process, it sends off the command to the appropriate process that registered the command with the KCD. In addition, it fires off the input received to the CRT display process which echoes the character to the terminal, regardless of whether the character is part of a command string or not. The default priority of the KCD is 1. If the command entered is invalid it sends the CRT display process an error message to be displayed. If the character received was not preceded by a % sign then the character is sent to the CRT to be displayed without being buffered for command decoding. The messaging sequence of this process is depicted in Figure 4 on page 24. Data Structures: char(128) message buffer When % char is received, the message sequence is recorded in this buffer until a carriage return is received. At that point, the string is decoded 23

24 Figure 4: Interprocess communications. and a message sent off to the appropriate process or if it is an unregistered command then an error message is sent to the CRT process to be displayed. kcd state state The KCD state is expressed in a structure. Figure 5 shows how the KCD behaves when characters are received. Figure 5: Keyboard command decoder state diagram. 24

25 linkedlist command list this linked list contains the list of commands and process IDs registered with the KCD process. This list is traversed for decoding the command. Pseudocode: loop forever receive_message(); read message: if message is not from UART and is a command registration message enqueue it in a linked list of commands to be decoded by the KCD. The message should be formatted like this: PID command_string else if the message is from UART: read the character. send this character to the CRT if character is a %: if kcd_state is valid, then two options: 1) send the existing command to the selected process, clear the buffer and start writing a new command (set the process_id field to -1 again) or interpret this as error and send error message to the CRT and clear the buffer else if only Receiving_command is valid then clear the buffer else set kcd_state.receiving_command to true; write this character at the head of the buffer; else if character is a carriage return: if command Info is valid: write buffer to a message and send message to kcd_state.process_id set kcd_state struct to its original state clear buffer else command Info is not valid: write buffer to a message, append an error message and send message to the CRT for display. set kcd_state struct to its original state clear buffer else if receiving_command is true but process_id = -1 Walk the linked list to determine which process Id this must be sent to and set the Process_ID field; If invalid command then send error message to the CRT to be displayed. destroy message end loop 25

26 6.2 CRT Display This process responds to only one type of message, a CRT display request. In printing to the console, the process makes use of the UART I-process. Any message received is freed using the release memory block primitive. It does not require any additional data structures. It sends no messages to other processes but it can receive a message from any process. The default priority is 1. The messaging sequence of this process is shown in Figure 4 on page 24. Pseudocode loop forever msg <- receive_message() send_message(pid_of_uart_i-process, msg) *Schedule* the USART I-process by enabling USART transmitter interrupts (this is done by writing to the USART status register) end loop 26

27 7 User Processes User processes take on the same set of states defined in Section 2.1 and move between them as in Figure 3 on page Set Priority Command The purpose of the Set Priority Command Process is to allow users to change the priority of processes running in the system by using the %C control command from the KCD process. The %C command has the following integer string parameters: %C pid new priority The default priority is 2. Figure 4 depicts the interaction between the Set Priority Command Process and the other processes in the system. Pseudocode start, perform any required initialization sequences process registers itself with the KCD to receive %C commands loop forever msg <- receive_msg() if (msg is formatted correctly (i.e. has valid PID and priority)) set_priority(pid, priority) if (error) send appropriate error message to CRT end 7.2 Wall Clock Display The Wall Clock Display is responsible for displaying a system time to the CRT. This process registers itself to handle the %W commands from the KCD process listed in Table 4. The default priority is 2. %WShh:mm:ss %WT Table 4: Wall Clock Commands Sets the current wall clock time to hh:mm:ss, starts the clock running and causes the display of the of the current wall clock time to the console CRT. The display will be updated every second. Causes the display to be terminated. Figure 4 shows how the wall clock interacts with other processes. 27

28 Pseudocode start, perform any required initialization sequences process registers itself with the KCD to receive %W commands loop forever msg <- receive_msg() if (msg is formatted correctly) if (message type is S ) time <- Parse hh:mm:ss from the message send time to CRT for display put time + 1 in the message envelope call delay_send(1000, message) to wake up the clock in 1 second. end if if (message type is T ) clear CRT end if if (error) send appropriate error message to CRT end if end if end loop 7.3 Null Process This process simply enters a null loop. The null process has the lowest priority (4) and no other process shares this priority level. Pseudocode loop forever end loop Test Processes The purpose of these processes is to stress test the messaging and memory block management system. This process must register itself with the Keyboard Command Decoder as operational on the command %Z. Every time this command is sent by the user to the system, this process updates a count initialized at 0 to the Test Process B which in turn sends a message to Test Process C. Because of the 4-step messaging involved here, this is a good test of the messaging and hence memory block management system. Process IDs for the test processes are 7,8, and 9 respectively. The interprocess communication of the test processes is shown in Figure 4 on page

29 7.4 Test Process A Creates a count report for Test Process B when command received by KCD. The default priority is 3. Pseudocode send_message(kcd, message with PID and command syntax) loop forever receive a message if the message contains the %Z command then break end loop num <- 0 loop forever message = request_memory_block() set the message_type field to "count_report" set message_data[0] field to num send_message(test_process B,message with count) num = num + 1 release_processor() end loop 7.5 Test Process B Once a count report is received from Test Process A, it is immediately sent to Test Process C. The default priority level is 3. Pseudocode loop forever envelope msg = receive_message(); send_message(test_process_c_pid, msg); end loop 7.6 Test Process C After receiving a count report from Test Process B, this process sends output if count is a multiple of 20. It then waits for 10 seconds before continuing to process count reports. The default priority level is 3. Pseudocode loop forever if PCB->received_message_queue is empty then 29

30 receive a message else dequeue the first message from the local message queue end if if message_type = "count_report" then if message_data[0] mod 20 = 0 then send_message( pid of CRT display, message = "Process C") delayed_send (10 s, message_type = "wakeup10") loop forever receive_message()//dequeues the first message if message_type = "wakeup10" then break else place the message at the end of the local message queue for later processing end if end loop end if end if release_message_block() release processor() end loop 30

31 8 I-processes The PCB of an I-process has a marker indicating that it is an I-process. I-processes, unlike other processes in the OS, are not scheduled by the Kernel scheduler. I-processes scheduling is actually driven by interrupts. The I-process executes according to the state diagram in Figure 6. Figure 6: I-process states. 8.1 Timer I-process The timer I-process is started each time a hardware timer interrupt occurs. The timer I-process should handle the delivery of delayed send messages after the required time. Pseudocode #Trap h/w interrupt mask out other interrupts; increment global time queueptr = head of delayed_send_queue while (top message should be sent) remove the top message from the queue request memory_block if no memory block available (null) error end if create a message using the top_message from the delay queue send_message(top_message) reset the timer count register set timer reference register = reference of next message - reference of top_message end while release processor 31

32 8.2 UART I-process The UART I-process receives characters from the keyboard and sends characters to the CRT display. Exectution of the UART I-process begins when interrupts are generated to indicate that data is available to be read from the UART, or to indicate that the UART is free to transmit another byte of data to the screen. The CRT system process sends strings of data to to the UART I-process, indicating that the data is to be transmitted on the serial port. Each time data is forwarded to the UART from the CRT, the UART transmit interupts will be enabled by the CRT. This transmit interrupt will immediately fire, thus scheduling the UART I-process. Entire strings of data can be included in the messages send by the CRT. Since the UART can only serially transmit one character to the screen at a time, the I-process will have to buffer the string being sent, and each time the ISR runs, the next character will be written from the string. When data is read from the UART, the I-process forwards it in a message to the KCD (which in a round-about way forwards echos it back to the CRT, which, strangely enough, gives it back to the UART I-process for display). The UART I-process is also used to intercept a special hot-key used for debugging. If the key pressed is a bang (!) then the UART I-process will display the processes on each ready queue with their priority, and the processes on the blocked queue with their priorities. If there is no memory available to the UART I-process on a character input operation, the input will fail and an error notification will be generated (audible beep.) The key pressed will be lost. The interprocess communication characteristics are shown in Figure 4 on page 24. Pseudocode if (Data available interrupt - indicates input from keyboard) character <- read UART receive register if(character is hotkey! ) write debug information to debug monitor (Each queue, processes and priorities) else create message with character pressed as contents send message to KCD else (Transmit ready interrupt - indicates UART free to send next byte) if (A data transfer is already in progress from BUFFER) if (BUFFER[next]!= \0 ) write BUFFER[next] and increment next else next = 0 else message <- receive_message() 32

33 if (message is not null) BUFFER <- string in the message write BUFFER[next] and increment next else disable Transmit ready interrupts 33

34 9 Initialization At start up, RTX must perform some initialization to prepare the system for use. To make the RTX more flexible, an initialization table will be created at start up. The parameters in this initialization table will then be used to build certain important system data structures and to start system and user processes. The Initialization Table consists of the fields shown in Table 5. Table 5: Initialization table format Memory Block Size (At least 128 bytes) Num. Memory Blocks (Power of 2) System Process 0 Pid System Process 0 Priority System Process 0 Stack Size System Process 0 Type System Process 0 Initial PC (4 bytes) App Process 0 Pid App Process 0 Priority App Process 0 Stack Size App Process 0 Initial PC (4 bytes) The values of the fields in the initialization table may be set during compilation or they may be configured with a boot loader. This is an implementation detail that will be explored at a later time. In addition to building the initialization table, the following initialization steps must be performed: 1. Initialization of hardware 2. Initialization of interrupts (setting up interrupt vector table, etc.) 3. Initialization of system queues 4. Initialization of the memory management table and memory pool 5. Initialization of process PCBs 6. Set process state (ready, I-process) 34

35 7. Initialize and assign process stacks 8. Enqueue PCBs on ready process queue 9. Run the scheduling algorithm to select the most appropriate process to run. 10. Start running the process 35

36 10 Implementation Plan The RTX will be assembled and tested in a very modular manner. Design will begin from the lowest level, with small assembly language portions such as basic input and output first being compiled and tested individually. Once most low-level assembly functions have been determined to work, some of the higher level C coding will begin. The basic data structures like queues, kernel and process control blocks, memory tables, etc., will be established. The basic primitives relating to memory management and message passing, and an initialization routine will be written first. To test these primitives, we ll start off with one test process testing memory allocation. Then the scheduling and context switching functions will be written. A second test process will test the scheduling, context switching and message passing. Then the I-process for the timer and the delayed send can be written and tested. The context switching will be tested here for switching between processes due to interrupts. Once these tests pass, the rest of the primitives and system processes may be written. Then, the UART process and the related user processes may be written and tested. Initially, the context switching will not account for pre-emption. Once the non-preemptive OS is stable, we will implement pre-emption. The various parts of the system will be measured first individually to ensure that they are able to perform their required duties. The CRT display process will be examined to ensure that it properly receives and displays strings, the wall clock process will be tested to ensure that it can send the time to the CRT display process every second, etc. The primitives will be tested to ensure that they will assign and return pointers and adjust system queues and will properly interact with the kernel functions. Once each section has been measured individually and determined to be operational, the various parts will be merged and the system will be measured as a whole. Priorities will be adjusted and various inputs will be given to the system to see how it will react and ensure that it can handle all of its required tasks. These measurements will ensure that our RTX is able to handle the responsibilities of being real-time. Although this task allocation may change once implementation of the RTX begins in earnest, at present the jobs are divided as follows. Scott Brissenden will be responsible for the system hardware and some of the low-level hardware dependent functions. Initialization of hardware devices such as the keyboard and monitor and their related registers, as well as masking and unmasking of hardware interrupts will be handled by him. Astha Gupta will be responsible for the majority of the kernel functions and the system processes. She will write the functions that need to be run in supervisor mode in assembly. Oggie Nickolic will code the I-processes and Wesley Tarle will code the user and test processes. Obviously many of these tasks depend on each other and everyone will need to work together to lay the foundation of basic low-level functions and some basic primitives. Since the primitives and processes parts will likely take longer than the hardware implementation and the kernel functions, Scott and Astha will be assisting Oggie and Wes in these areas once their own respective tasks are complete. Also, the respective individuals will be responsible for testing their individual areas. As 36

37 each module gets assembled, a system integration test will be carried out. As well each individual will document his/her code and maintain ownership and responsibility of their parts. The group will use CVS to implement change control. We will develop and debug under UNIX. Periodically, when we have a stable OS we will test it on the Coldfire board to make sure we are on track. 37