Main / CoursesESProject

SFSU - Engr 844 - Embedded Systems

Course Project
Instructor: Seapahn Megerian
Spring 2013

Goal:

Master a modern embedded system through first-hand exploration, design, implementation, and testing.

Overview:

As discussed in class, embedded systems exist all around us and come in a wide variety of shapes and flavors. In this project, your goal is to explore at least one aspect of such a system in great detail through actual design, implementation, testing, and use. Since the types of applications will drive the kind of hardware and software architectures you will require, and in turn the type of architecture you choose will drive the classes of applications you can tackle, the initial phase of selecting a specific topic will require research and possibly several brain-storming sessions among the team members to reach a consensus. Of course initial specifications and design choices can always be changed later but given the very limited time frame for this project, you should take great care early on to avoid costly "re-design" steps.

Types of projects (in order of preference):

  1. Actual hardware: Clearly the most preferred type of project is one that utilizes actual hardware with real implementation of a system that addresses a real application (in other words, build a system that does something useful). Since it is very unlikely that you have the resources or the time to design a system from scratch, it is probably a good idea to explore your many existing options in embedded micro-processor or micro-controller development boards (fortunately such hardware can be obtained fairly cheaply these days -- especially compared to text-book costs!) You will be presented with a number of choices in class though of course you are free to explore other options.
  2. Emulated hardware: Using hardware emulators is also acceptable in many circumstances though less desirable since they can hide many complexities that an engineer can face when dealing with actual hardware. Nevertheless, this is a viable option to consider. Examples here include emulators targeted for cellular phone and PDA application development. Note that you are still expected to have a firm grasp of the actual hardware and the underlying architecture. You should not be relying on the emulator to abstract away the real essence of the project which is the embedded system itself.
  3. Simulated hardware: Consult with the instructor if you are planning to undertake such a project. See the notes below.
  4. Survey paper: In very rare circumstances, a survey paper may be used to satisfy the project requirement of this course. However, please be advised that significant depth and breath will be expected on a topic of embedded processors so again, you are required to consult with the instructor before undertaking such an effort.

Project Logistics

  • Teams of size 2-3 students (may change)
  • Initial project proposal due on 2/26/2013
  • Initial presentations on 3/05/2013 (5% of total grade)
  • Final presentations and demos (20% of total grade)
  • Final report (30% of total grade)
    • Will be in the form of a project website
    • More on the details later

Notes:

Please remember that the goal of the project is to explore an embedded system. Often it is easy to get carried away with grand ideas, exotic applications, and ambitious undertakings. But you should constantly ask yourself these questions:

  1. What is the architecture of our system?
  2. What is the programming model? (yes, it should be programmable!)
  3. What class of applications does it address?
  4. What specific applications are we going to address?
  5. What are the design constraints?
  6. How will things be implemented?
  7. Who is the team leader? (yes, you have to chose a leader)
  8. How are we splitting the tasks among team members?
  9. How will we test it?
  10. What is our backup plan if things don't work as we assumed?
  11. Do we have a detailed schedule and how far are we behind?
  12. If we are not behind, are we sure we really know what we are doing? :)

Most important of all, try to have fun with this project. You should realize you have a rare opportunity to build something here that you can show off as "your own" for years to come. It may be the central topic of future job interviews or just something to be proud of. So don't just make something that works ... make something that you will want to show off to everyone!

Preliminary Proposal Guidelines - Due 2/26 before lecture (email)

You are required to submit a short proposal (about 1 or 2 pages) in PDF format, with the following sections:

  • Project title
  • Team members (identify the leader)
  • Introduction
    • Briefly describe your application and the problem you are trying to solve.
    • Discuss some related works if applicable
  • Architecture
    • Describe the processor, board, and platform you plan to use
    • List any additional components such as sensors, actuators, etc
  • Software
    • What software components will be needed?
    • What do you think you will develop?
    • Do you plan to use existing libraries or packages?
  • Final Deliverables
    • What do you plan to show off at the end?

Preliminary Project Presentation

Plan for a 10 minute presentation in class. Due to time constraints, it's a good idea to only have 1 person talk about the project but all team members should be present if possible. There is no specific format required but you should try to answer the following questions:

  • Who are you and what is your team called?
  • What are you planning to do and why?
  • How are you going to make it happen?
  • What do you plan to implement?
  • What do you plan to show off at the end of the course?

Although your project can change later (this is not a binding proposal), you should think carefully now in order to avoid too many re-design steps later. Also, plan your presentation time wisely!

Project Grading Criteria

  • Preliminary proposal
    • Was it on time?
    • 10% : Followed basic instructions?
    • 45% : Quality of proposal
    • 45% : Quality of presentation
  • Final Project Presentation
    • 10% - Organization and time management
    • 45% - Quality of presentation
    • 45% - Demos (less weight for the earlier week -- can also be part of final submission)
  • 10% - Basics
    • Report turned in on time
    • Followed submit instructions on the class webpage
    • Working link to a working project website by the deadline
  • 30% - Completeness
    • Intro, motivation, and related work
    • Architecture section
    • MicroArchitecture
    • Software design
    • Testing and evaluation
    • Demos
  • 60% - Complexity and novelty
    • How does it rank with other projects in class (and the past)
    • Did you master your hardware and software platforms?
      • Did you push the limits of what can be done with what you have?
      • Were there any difficult engineering of implementation challenges?
    • Did you accomplish what you set out to accomplish?
    • Incorporated instructor suggestions or hints effectively? If not, why not?
    • Does it solve a useful problem? Is it sufficiently motivated and polished as a product?
    • Is it something you can brag about now?