UCR CS 122A: Intermediate Embedded and Real-Time Systems, Fall 2006

Other CS122A Offerings
Course Moodle Page

Overview

Embedded systems include almost any computing system other than traditional computers. Examples include cell phones, set-top boxes, medical devices, alarm systems, automotive systems, portable music players, etc. Embedded systems is one of the fastest growing areas in computing, having high impact on people's lives, and with tremendous potential for innovative new products.

In addition to the catalog subjects below, we'll focus on several concepts that go beyond any one course's subject matter, including:

Tradeoffs
Thinking models, not languages
Teamwork and communication
Applications and their implications

Past student evaluations of this course regularly highlight two key points: Students work hard (but not unreasonably so), and learn a LOT of useful and interesting material (they later often send email indicating the material was key to their getting a good job). Catalog description : CS 122A. Intermediate Embedded and Real-Time Systems (5) Lecture, 3 hours; laboratory, 6 hours. Prerequisite(s): CS 012, CS 120B/EE 120B. Covers software and hardware design of embedded computing systems. Topics include hardware and software codesign, advanced programming paradigms including state machines and concurrent processes, real-time programming and operating systems, basic control systems, and modern chip and design technologies. Laboratories involve use of microcontrollers, embedded microprocessors, programmable logic and advanced simulation, and debug environments.

Basic information

Instructor and office hours : Frank Vahid (Email: vahid, AT cs.ucr.edu) Office hours: To be announced in class
Office: Engineering Building Unit 2, TBA

Teaching Assistants: David Sheldon (Email: rmannion, AT cs.ucr.edu)
Scott Sirowy (Email: ssirowy, AT cs.ucr.edu)

Lecture : Tue & Thu, 2:10-3:30 in SPR 2339 (Inside view)

Labs : Mon & Wed 6:10 pm to 9:00 pm in ENGR2 136)
Lab attendance is mandatory. You are expected to stay in the lab for the entire lab session, working on material related to this course. Part of your lab grade is based on attendance and participation.

Books:

Required: "C and the 8051 -- 3rd edition" (Note: do not get an earlier edition; they are very different), Thomas Schultz, ISBN 1-58961-237-X, Pagefree Publishing Inc, 2004. www.CAndThe8051.com
Recommended: A reasonable introductory book on VHDL. We may provide handouts on VHDL too, but if you want a complete book, I recommend: "VHDL : A Starter's Guide (2nd Edition)", Sudhakar Yalamanchili, ISBN 0131457357, Prentice Hall, 2004.
Recommended: A basic C programming book. A good C book is The C Programming Language, Second Edition, Kernighan and Ritchie, Prentice Hall, ISBN 0-13-110362-8, OR any other basic C programming book.
I will also be handing out numerous articles for you to read, dealing with various embedded system applications, as well as with implications of embedded systems on humans and society. My favorite resources include:
Economist (Nice technology coverage, especially their Technology Quarterly section)
Discover (Excellent discussion of science and related technology)
How Stuff Works (Awesome description of how science and technology items work)
Embedded Systems Programming Magazine

Course grading: The grading will be based on the combination of two components: 43 pts: Lab component 38 pts: excercises, assignments and any lab quizzes
5 pts: attendance, participation, and presentations
57 pts: Lecture component 17 pts: Homeworks/quizzes/in-class-exercises/participation
20 pts: Midterm
20 pts: Final
Letter grades are assigned according to the usual 90/80/70/60 rule: 90% and above corresponds to an A, 80% and above to a B, 70% and above to a C, 60% and above to a D, and less than 60% to an F. +/- grades will be given. Curving may be done on individual items only if it helps the class; never if it hurts the class. You are not competing against one another -- you can all earn As (and that has happened in the past), so work together and help each other to succeed.

To ensure minimum competency in both principles and practice, students must pass the lab component and the lecture component individually, meaning 60% or more of the points of each, in order to pass the course.

General course features and policies

Study groups : Engineering is a social discipline, requiring good people skills. Furthermore, working with others enhances learning. Therefore, we STRONGLY encourage collaborating on the homeworks, and studying together. Although students should not submit identical homeworks, very similar homeworks are O.K. -- under no circumstances will we consider similar homework submissions as cheating -- even if two submissions are identical (though we will deduct points for identical solutions). So work together without fear. Furthermore, we will give 10% extra credit on any homework submission in which you studied with a group of at least two other CS122 students for at least one hour -- the student names and the time spent together must be noted on the homework, and all must match. Note: we're trusting that you will be honest about this, and not just write down each other's names to get the extra credit.
Helping others : Helping others enhances one's own learning, and also, well, helps others (remember, you can all get As). Thus, we encourage you to help others in the lab if you have the time. You should not write code for others nor show your code to others. But helping find bugs, teaching how to debug, and helping to explain concepts, are fine. Students that we have found to be particularly helpful to others may receive a small amount of extra credit lab points, given in the middle of the quarter and at the end of the quarter (but ideally you should not do this just for the extra credit!).
Regrade policy: corrections must be submitted in writing and within one week of the distribution of the graded material. Grade-database errors should also be pointed out within one week of posting.
Academic dishonesty: please don't cheat, O.K.? Copying code for the labs from any source (current students, past students, textbooks, web, etc.) is not allowed unless explicitly authorized. Team-coding (you write function A, I'll write function B) is not allowed unless explicitly authorized. Report cheating anonymously at: https://www.cs.ucr.edu/cheating/.
Success in computer science courses requires time. A typical student needs to spend about 15-18 hours per week on this course (including lecture and lab).
This course is the third in an upper-division sequence (with 120A and 120B preceding); thus, the course is designed for mature students with good study habits. We'll cover a wide variety of subjects in lectures, with students expected to study those subjects extensively outside lecture. You should come to lecture prepared not to just listen, but to think and to participate. It's a lot of work, but you'll learn a lot and hopefully have fun too. Past students have told us that they've gotten jobs specifically because of skills learned in the 122A/122B courses -- so it's worth the effort!

Lab guidelines

Students are required to stay the full three hours of lab session every week. You'll have in-lab exercises, presentations, discussions, and possibly exams. Work ahead or on extra course-related material, and/or provide appropriate help to others, if you finish early.
During lab discussion time, students should move away from their computers to the whiteboard.
Prepare for lab before arriving. Bring relevant reference books to lab.
All persons in lab during scheduled lab time must be formally registered in that section. No unregistered people in the lab are allowed.
Do not bring your bike/scooter/etc. into the lab.

Lab presentations

Each day (starting the first week of lab) will include three 4-minute presentations at the beginning of the lab. Choose a recent article from a source of embedded systems information. No two people should present the same article. Talks should be almost exactly 4 minutes (questions will be held until afterwards), so plan carefully. The number of presentations per student depends on the number of students we have, but all should give the same number, and you can't give your next presentation until all students have finished their current one. Your talk should justify why you chose that article (why do you think it's interesting?)