90 likes | 115 Views
PAX OS Team. Nick Mattei Deepthi Boyanapally Koppala Raghuveer Shadab Ambat. Objectives. To implement an API for message handling between user level tasks and the custom PAXCAN interface, as well as, assist all teams with integration of system code into a defined Micro C OS II environment.
E N D
PAX OS Team • Nick Mattei • Deepthi Boyanapally • Koppala Raghuveer • Shadab Ambat UK Aerial Robotics Team University of Kentucky
Objectives • To implement an API for message handling between user level tasks and the custom PAXCAN interface, as well as, assist all teams with integration of system code into a defined Micro C OS II environment UK Aerial Robotics Team University of Kentucky
Requirements • Code must be extremely robust and fault tolerant. • Code must operate within the timing constraints necessary to ensure proper in-flight operation. • OS must be configured for smallest possible memory size so as not to hinder user space coding ability. UK Aerial Robotics Team University of Kentucky
Design UK Aerial Robotics Team University of Kentucky
Design UINT8 send_msg ( CAN_ID_TYPE can_id , PAYLOAD_TYPE payload ); // Passes a CAN message and it's ID to the router layer to be stuffed into the D' input queue. UINT8 reg_msg ( CAN_ID_TYPE can_id ); // Tells the IDEAnix router layer to grab incoming messages with can_id off the bus and to place them into the tasks incoming queue. UINT8 unreg_msg ( CAN_ID_TYPE can_id ); // De-allocates space in hardware for this can_id and stops messages of this type from being placed into the tasks' incoming buffer. // Special can_id of 0x0800 clears ALL allocations. (CAN IDs are only 11 bits, 0x0800 is the 12th bit.) UINT8 get_msg ( CAN_ID_TYPE *can_id_ptr, PAYLOAD_TYPE *payload_ptr ); // Places the first can_id and payload in the pipe/queue/buffer into the memory space refered to by the pointers. UINT8 check_msg ( void ); // Returns 1 if there is any data waiting in the pipe/queue/buffer, else, 0. UK Aerial Robotics Team University of Kentucky
Design • Micro C OS-II is a low-cost, priority-based, real time kernel. Useable for safety critical embedded systems including aviation • Support for per-processor multitasking. • Support for real-time functionality including mutexes, semaphores, inter-task messaging and independent task stack space. • Flexible with freely distributed source code makes it a good choice for our systems. UK Aerial Robotics Team University of Kentucky
Design • Micro-C OS-II is configured generally and on a per-processor basis. • Use of ISR’s, Queue’s and Semaphores are necessary for every group. • General configuration includes initialization for onboard components and initial stack sizes for user tasks. UK Aerial Robotics Team University of Kentucky
Risks • Software failure could lead to complete loss of the plane. • Failure of the MicroC OS configuration or the CAN communication protocol implementation constitutes a single point of failure for the entire plane. • Standard Real-Time OS hazards including data sharing and task starvation UK Aerial Robotics Team University of Kentucky
Status • User Level Messaging System: • Functions are implemented • Mux and DeMux tasks are in alpha stages and need a little more work • General OS Configuration: • General implementation up on the wiki • More specific needs will be addressed per-processor(per-group) as groups begin to finish their code base and integrate into system. UK Aerial Robotics Team University of Kentucky