Embedded Systems 100

To see a table of contents, select the word "Contents" at the top right of this page. A box will appear with links to the content items on this page; select the item you'd like to read. To hide the contents, select "Hide Contents" in the top right of the Contents box.

Fundamentals of Embedded and Real-Time Systems

Introduction

Scope of the Course

This is the first course in the three-course Embedded and Real-Time Systems Programming Certificate Program. In this course, you will learn the fundamentals of computer architecture and basic hardware concepts; and will learn how to develop software on embedded devices. Special emphasis is placed on how software interacts with hardware, i.e. how a programmer tells a computer what to do at a low level. Regardless of your background in hardware and software, upon completing the course, you should be ready to advance to the second and third courses in the program.

.

Course Objectives

After you have mastered the material in this course, you should be able to

• read a short, multi-page circuit schematic consisting primarily of a microprocessor, memory, peripheral devices and other digital components, resistors, and capacitors; and write software for the microprocessor that interfaces with the components in the schematic;
• demonstrate embedded systems-specific C programming practices by writing C programs that correctly interface with hardware and exhibit efficient and appropriate use of memory;
• write a 100-instruction or longer assembly language function that interfaces with C code to perform an operation on the microprocessor (portions of the function should not be possible to do in C or C++ due to language or compiler deficiencies);
• make modifications to provided sources and use cross-development tools on a PC to build a functioning image that can be downloaded to the development board and debugged;
• write an interrupt service routine to service an on-chip or external device that communicates with the rest of the system.

Prerequisites

1. Proficiency in C or C++ is required for this course. This means that you know about and know how to use the following:

•  functions;
•  pointers;
•  structs and unions;
•  dynamic memory allocation (e.g. malloc, free);
•  basic data structures (e.g. arrays, stacks);
•  runtime library;
•  C preprocessor; and
•  comments.

We will be covering some of these topics as they relate to embedded systems. You'll get some review as we progress through the material, but if you are out of practice writing a C program, you will need to brush up on this skill.

2. You must also be familiar with the software development process and some set of development tools. You should be able to build a program, run it, and debug it.

Required Software and Hardware

• access to a computer with a browser of version 5.0 or higher
• access to e-mail
• UW Development Kit (contains the development board, other hardware, Metrowerks CodeWarrior, etc.)
• PC capable of running Metrowerks CodeWarrior (Pentium, 32 MB RAM, 90MB free HD space, CD-ROM)
• Windows 95/98/NT4/XP

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 (e.g. printer, handheld device synchronization) you will need to configure your PC to share.

Lessons, Homework, and Reading Assignments

Grading

You must earn an 80 percent average to pass this course. See the FAQ section for assignment criteria.

Cheating

Just don't do it. I don't want to have to deal with it. If I have to deal with it, the proper university authorities will be notified.

Is collaboration or getting help from others cheating? No (except on exams), but follow the Gilligan's Island rule. I had this rule while in school, and it works well.

Gilligan's Island Rule

If you get help from someone else or some other source (e.g. Internet), you must watch a half hour of Gilligan's Island (or do some other mind numbing activity) before continuing with your work. You cannot use any written notes or anything else from the help session other than what you remember in your brain.

The reasoning is that if you can derive useful information by consulting with someone else, and you can retain the information through a half hour, then you must have learned the information. Since learning the information was the goal in the first place, this isn't cheating.

Assignment FAQs

When are assignments due?

Please see the course calendar for assignment due dates.

Written assignments. Written assignments should be submitted via the E-submit tool on your syllabus.

Use only Adobe Acrobat PDF format, Postscript (PS) format, or plain text. Do not use Microsoft (Word, Excel, PowerPoint) as these applications are susceptible to the many new macro virii that emerge every day.

Note: Print files to PostScript by using any Windows provided postscript driver and print to file. With Postscript, (as with PDF files) everything is printed as intended (WYSIWYG - What You See Is What You Get).

You also may submit written assignments by e-mail, fax, or postal mail if it is more convenient.

Programming assignments. Programming assignments should be submitted via E-submit as zipped up projects with sources only (no objects, executables, S-records files, etc.). You may also need to submit some hardcopy to accompany it; in which case, follow the guidelines described for the written assignment.

What if I e-mail my programming assignment but want to change something?

If you turn in the sources for your programming assignment and you want to make changes, send me another e-mail 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.

If I can't finish the course in the specified time frame, can I have an extension?

If you incur extenuating circumstances that hinder completing your assignments by the end of the course, please contact me to discuss the possibility of an extension.

Should assignments be typewritten?

It's up to you. If you want to type out your assignments instead of faxing in handwritten ones, go ahead. I have nothing against handwritten assignments as long as I can read your writing. In either case, be sure to show your work (if the question format requires it) and be sure that your answer is obvious. I don't want to sort through a page full of chicken scratch equations to find an answer.

How long should it take me to do the assignments?

Reading assignments will take from two to three hours, and programming assignments from 10 to 20 hours. If you find yourself working considerably longer, please let me know. My goal is not to break you by loading you down with massive amounts of homework. As it's difficult for me to judge how long each assignment will take, 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 challenge you.

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 or exams), write up a description of the problem on a separate piece of paper and send it to me along with the unaltered original work. I will consider your regrade request. Note that you cannot add more information to your description, and you cannot change your original work. Your grade can go up or down, so be sure you have a legitimate request.

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, etc. 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 will display properly in Notepad. If you use a flavor of Unix, you know what this means and should be able to write a script that will process 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.

Here is an example of a well-formatted file. It's a derivation of "Cutler Normal Form." Remember that it's just an example of formatting. Each environment—be it an operating system, a company, or a customer—will have a different form. You'll probably be better off trying to fit the mold rather than attempting to do your own thing.

About the Course Developers

Richard Chinn

Richard Chinn is a Senior Software Engineer at BSQUARE Corp., where he has spent more than three years working with Windows CE on a variety of hardware platforms and devices. Most of his work has been at the operating system and driver level. Prior to working at BSQUARE, Chinn graduated from the University of Washington Department of Computer Science and Engineering with a B.S. degree. During his studies, he had an opportunity to work on the Raven Human Powered Airplane project, where he developed software for the on-board flight computer.

Mitch Ishihara

During the past 10 years, Ishihara has worked with battery management embedded systems. He currently works with companies such as Charles Industries Marine to license this technology. He was an expert advisor for UW's Electrical Engineering Embedded Microcomputer Systems class to aid students, and he tutored students in embedded systems from other colleges.

Jelena Vucetic

Dr. Jelena Vucetic has been teaching and researching in the area of business and technology management for more than ten years. She has taught students in distance learning programs, as well as traditional students, at the Masters and Undergraduate levels. Focusing largely on technology, strategic management and the relationship between business and technology, Jelena has taught at the Polytechnic University Brooklyn, NY, the George Washington University in Washington, D.C., University of Maryland University College (online), and University of Phoenix (online). Dr. Vucetic is a business and technology management consultant in the Washington, D.C. area. Her clients are primarily focused on telecommunications industry. She is also a founder of a small high-tech private company that provides products for the wireless telecommunications market. This company has been in business for more than five years, and Jelena was its President and Director of the Board during its first three years.

Dr. Vucetic has more than 15 years of industrial experience in telecommunications and computer systems, including engineering, business development, marketing, sales, operations and manufacturing. Her strong interest and background in embedded systems has been the major motivator for her to take part in the development of this course.

Dr. Vucetic’s educational background includes an MBA degree, a Ph.D. degree in Electrical Engineering, Master's in Computer Science, and a B.S. degree in Electrical Engineering.

Dr. Vucetic is also an author of four patents issued by the USPTO, as well as of around 40 professional publications.

If you need technical help, e-mail Program Support Services at dltechsupp@ese.washington.edu. You may also call (800) 543-2350; fax (206) 543-0887; or call (206) 543-0898 (TTY).