EMBSYS 105

Programming with Embedded and Real-Time Operating Systems

Course Introduction

Scope of the Course

This course, Programming with Embedded Systems and Real-Time Operating Systems, is the second course in the Embedded and Real-Time Systems Programming certificate program. A project-oriented course, it is designed to leverage and extend the knowledge of embedded systems you gained in the first course.

In this course, you will develop the basic skills required to successfully design, implement, and test the software portion of an embedded system. The course focuses on the operating system features that enhance the development of embedded and real-time systems, and on software engineering issues unique to the development of embedded and real-time systems. A substantial portion of the effort required to succeed in this course is based on programming of the UW development system.

Prerequisites

1. successful completion of Embedded Systems 100, Fundamentals of Embedded and Real-time Systems
2. proficiency in C programming
3. basic assembly language programming ability (68K/Coldfire preferred)
4. basic knowledge of system architecture and concepts
   • general understanding of embedded system memory maps
   • ability to use hexadecimal math operations
5. basic digital system hardware knowledge
   • general familiarity with the hardware components of the UW development kit
6. general knowledge of the UW development kit software tools
7. system design, development and testing skills
   • ability to design, implement, cross-compile/assemble, download, and debug a program using the UW development kit
   • ability to implement, download, and debug polling and simple interrupt routines using the UW development kit

Technology Requirements and Skills

In addition to the technology requirements and skills noted in the Online Student Handbook, for this course you will need:

• UW development kit (contains the development board, other hardware, Metrowerks CodeWarrior, etc.)
• PC capable of running Metrowerks CodeWarrior (CD-ROM)
• Windows

The PC will also need at least one serial port (DB-9) and a parallel port. If your PC doesn't have one of these ports, you won't be able to complete the programming assignments. If you're using these ports for other devices (for example, a printer, a handheld device synchronization) you will need to configure your PC to share ports.

Learning Objectives

When you have successfully completed Embedded Systems 105, you will be able to

• create and review systems requirement documents for embedded systems;
• review and analyze software and hardware partitioning;
• port a basic real-time operating system to the UW reference platform;
• design and implement a small multi-tasked embedded project; and;
• use multiple interprocess communications methods.

Course Structure

The course consists of

• eight online lessons;
• four assignments;
• a programming project;
• online group discussions; and
• a final exam.

Each of the eight lessons explores a series of related topics, most of which are introduced through examples and follow-up discussion. Each lesson has been designed to give you the information required to meet or exceed the exit competencies of the course and to prepare you for the course projects.

In the assignments for the first course in the Embedded Systems program (EMBSYS 100), you typically were given shells of programs that required you to fill in the missing piece. In this course, however, the projects are broader; for most assignments, you will start from an earlier stage. This approach requires more independent thought and up-front planning on your part. Thus, it is important that you communicate in the discussion forums with other students and with your instructor to avoid traveling down too many false roads when you undertake your projects—though even these false roads are useful learning experiences.

Outline of Lessons

Lesson One

• Embedded systems overview (review)
• Differences between embedded systems and general systems
• Requirements documents as they apply to embedded systems

Assignment 1

• Create document outline for embedded development

Lesson Two

• What is an operating system?
• Basic requirements for an embedded operating system
• Approaches to supporting operating system functions within an embedded project
• Scheduling without an operating system present
• Minimum features of operating systems
• Threading features of MicroC/OS-II
• Scheduling with an operating system

Assignment 2

• Begin porting MicroC/OS-II to the UW reference platform

Lesson Three

• Data sharing issues and solutions to protect data review
• Semaphores and semaphore deadlocks
• Priority inversion and inheritance

Assignment 3

• Continue porting MicroC/OS-II

Lesson Four

• Interrupts and exceptions from an operating system point of view
• ColdFire 5206e exceptions review
• Supervisor/User modes of operation
• ColdFire 5206e privileged instructions review
• Recursion and reentrancy review

Assignment 4

• After port is complete, design generic interrupt dispatch code for dispatching shared interrupts

Lesson Five

• IPC mechanisms supplied by operating systems
• MicroC/OS-II mechanisms review
• Introduce special issues with memory allocation in embedded systems
• Review: MicroC/OS-II memory allocation APIs

Assignment 5

• Continue with Assignment 4

Lesson Six

• Designing multi-tasking embedded systems
• Problem analysis from different view points: functional, data flow, event, and object
• Interface definitions, interface control documents
• A pragmatic look at what a thread is and what it is not
• Setting thread priorities
• Overview of design for test

Assignment 6

• Introduction to project

Lesson Seven

• Device driver models—overview
• Simple character model
• Complex driver model: Windows NT—overview
• Device specific driver models
• MicroC/OS-II driver model add-on code review

Assignment 7

• Continue project, add WaveNull driver use to project

Lesson Eight

• Introduction to real-time operating systems
• Evaluation of timing constraints
• Discussion of reliability, availability, and throughput
• Discussion of hard deadlines
• Special issues in real-time systems
• Error propagation and fault injection
• Failure and hazard rates
• Single point of failure
• Fault types
• Fault tolerant and gracefully de systems
• Fault detection
• Redundancy

Assignment 8

• Complete class project

Lesson Nine

• Final exam preparation

Grading

You will earn grade in this course. You will be graded on assignments one through four, your class project, the final exam, and your participation in the discussion forum. Grades will be weighted as follows:

Assignments 1–4	30%
Class Project	30%
Final Exam	30%
Participation in online discussion forums	10%

Criteria for Grading Programming Assignments

Programming assignments will be graded based on the following criteria. Descriptions of each criterion follow the table. The percentage breakdown is approximate, as it depends on the particular assignment.

Criteria	%
Correctness	35%
Implementation and Robustness	30%
Testing and Identification of Problems	25%
Style	10%

Correctness essentially means your solution runs and exhibits basic functionality. It's ready for a demo, but could use some tweaks. In relation to the saying, "First make it run, then make it right, then make it fast," this is the "make it run" stage.

Implementation and robustness refers to how you implemented the solution. Did you make good use of memory? Did you cover the corner cases? How easy is it to break your code? Basically, the solution runs, but is it right and fast?

Testing and identification of problems refers to how well you tested your solution and how clearly you identified problems in the solution. By problems, I mean tricky interactions in the system that you need to watch out for and that someone coming along later to maintain your code may need to watch out for.

Style refers to how well your solution reads. Are the comments clear and descriptive? Does the code document itself?

Criteria for Participation in Online Discussion Forums

You should strive to make a serious contribution to each discussion. If you are unable to contribute to one or two discussions, your grade will not suffer. However, if you add nothing to over half the discussions, your grade will suffer significantly.

Assignment FAQs

1. How should assignments be turned in?
   Written assignments should be submitted through the E-Submit tool on your syllabus as Microsoft Word DOC files or text files.
   
   Programming assignments also should be submitted through the E-Submit tool as zipped projects with sources only (no objects, executables, S-records files, and so on.).
2. When are assignments due?
   Assignments are due on the dates listed on the course calendar. (Assignments may be turned in early, but no extra credit will be given.)
3. What if I turn in my assignment after the due date?
   Late assignments will not be accepted unless permission is granted by your instructor. Upon permission, assignments will be accepted up to one week after the due date; however, they will be considered late and your instructor may not grade or comment on them. Instead, late assignments will be marked "pass" or "fail" based on the completeness of the work.
4. What if I submit my programming assignment but want to change something?
   If you turn in the sources for your programming assignment and want to make changes, resubmit your assignment with your new version, and indicate that it's a new version. Try to minimize the number of times you do this. Turn in your assignments when you're ready—you don't get extra points for being early.
5. If I can't finish the course in the specified time frame, can I have an extension?
   Your enrollment period begins the day you register. If you have extenuating circumstances that hinder completing your course by the expiration date, you may ask me for one extension, provided you have (1) satisfactorily completed at least two-thirds of the course assignments before making the request, (2) submitted the request to me before your original registration expires, and (3) demonstrated extenuating circumstances. You may extend your original enrollment only once. See your Student Handbook for more information on a request for extension.
6. Can assignments be handwritten?
   No. Please use a word processor.
7. How long should it take me to do the assignments?
   Reading assignments should take from one to two hours, and programming assignments from five to 20 hours. If you find yourself working considerably longer, please let me know. My goal is not to break you by loading you with massive amounts of homework. I can only judge approximately the length of time each assignment will take; therefore, I rely on feedback from you.
   
   Similarly, if you're breezing through the assignments and start to get bored, let me know. I'll try to send you some supplemental material to keep you entertained.
8. What if I think a mistake was made when my work was graded?
   If you think that a mistake was made in grading your work (assignments, project, or final exam), write a description of the problem and send it to it to me. I will look at my electronic copy of your original assignment and consider your regrade request. Your grade can go up or down, so be sure you have a legitimate request.
9. Is there a coding convention for the programming assignments?
   Yes and no. I'm not going to be real particular about how you format your code and name your variables. As long as your code is readable, I'll be happy. To ensure your code is readable, you should follow these rules at a minimum.
   • Never use tabs.
   • Be consistent in your indentation (four spaces per unit of indentation is recommended) and placement of braces.
   • Try not to go beyond 80 columns on a given row.
   • Use comment blocks at the beginning of each file. Include your name and the assignment as well as a description of what's in the file. If you'd like to describe how everything works, do it in one of the main files.
   • Use comments throughout the file to describe functions, structures, code flow, and so on. This will help you develop a clearer picture of what you're doing. It will also help me figure out what you're trying to do.
   • Use a DOS/Windows editor or ensure your end-of-line characters display properly in Notepad. If you use a flavor of Unix, you know what this means, and you should be able to write a script that processes your files before turning them in.
     
     A good litmus test is to open your file in Notepad. If it looks good, you're set. If it looks weird, you should go back and do some formatting.

About the Course Developer

Paul has extensive experience in the embedded programming industry. He is president and co-founder of Codetelligence, Inc. (www.codetelligence.com) and was the founder and president of BlueWater Systems, Inc. As president, he was highly instrumental in growing the company from a one-man shop to world-wide recognition as the leading Windows device driver tools and consulting company. BlueWater Systems was successfully sold to BSQUARE, Corp. (NASDAQ:BSQR) at the height of the dot-com era. Paul held a number of senior positions at BSQUARE including Chief Technologist for Products and Director of Platform Technology.

Paul's career has included positions with Hughes Aircraft Company, as member of the technical staff and software supervisor, as well as software manager for FLIR Systems. In addition, Paul has consulted with many key technology companies including: Microsoft, Intel, Rockwell International, Compaq, and Hewlett Packard. He has a Bachelor of Science in Systems Analysis from the University of Miami.

Paul holds a number of patents in the embedded systems area.

Paul is a part-time instructor at the University of Washington, where he developed and teaches the Embedded Programming and Real-Time Operating Systems course, an integral part of the Embedded and Real-Time Systems Programming Certificate.