EE 285/CS 241: Embedded Systems Workshop

Autumn Quarter, 2016
TuTh 10:30-11:50, 320-107, Packard 053
Instructor: Philip Levis
  • Office hours: Thu. 12:30-2:00, Gates 409
  • TA: Shane Leonard
  • Office hours: TBD, Packard 053

  • Example template for project presentations

    CS241 is a project-centric course intended for students building embedded systems. A student's grade is determined by assessment of their final project and contribution to it. Students work in groups on projects, with group size to be determined. Students who have embedded systems in their research or other activities (e.g., a control system, a UAV system, a sensing platform, a medical device) may scope a part of their system as their course project, although demonstrating the new aspects attributable to CS241 will be expected. Other projects should focus on systems that addresses a non-frivolous need, such as some form of societal good or art. Examples include:

    • Hose/spigot attachment that detects and measures water use in real-time and reports it wirelessly
    • Crash avoidance system for bicycles
    • Long-lived floating water pollution sensor for river sampling
    • High-altitutude weather balloon controller
    • Controller for a large LED display
    • Detecting baby movement with ultrasound/RF
    • Childseat warning system
    • Seizure detector that texts parents if their child has one
    • Inexpensive, networked, stitched gigapixel cameras
    • Teaching and demonstration systems suitable for mass deployment
    • Inexpensive, intelligent and networked irrigation controllers
    • Passive power draw sensing for large appliances

    The class is limited to 20 students. If it is significantly oversubscribed, we'll select a subset of the proposals in the second week of class and those students can remain in the course. The final report is an Instructable that tells someone how to repeat the work (the work must be all open source).

    Student projects will determine what material the course covers: topics will be determined by the needs of the enrolled students. Examples of topics that might be covered include:

    • Interrupts and concurrent programming
    • Deterministic timing and synchronization
    • State-based programming models
    • Filters, frequency response, and high-frequency signals
    • Low power operation
    • Clock domains and resource management
    • Flash storage
    • Wireless protocols and protocol design
    • Microcontrollers, microprocessors, and tradeoffs
    • Energy harvesting and storage
    • Architecture and low-level systems
    • Sensors, actuators, and peripherals
    • Bus protocols and tradeoffs
    • ADC and DAC circuits
    • Operating systems
    • Security, privacy, and cryptography
    • Part selection, hardware/software tradeoffs
    • System design, PCB design

    The prerequisite for the course is CS107 (or equivalent), that is, comfort with C. It is intended to be accessible to engineering students broadly from the entire school, including both undergraduates and graduate students. The course would count as a general CS elective or as under the c. list of courses of the CS master degree with permission of the instructor (the project must involve a significant software systems effort). The course meets twice a week for 2-hour lab sessions in Gates 325. Instruction will be informal if the topic is relevant to only a few students and more formal if broadly useful.

    The educational goals of the course are students learn how to design, build, and test embedded systems from hardware to software. It will use the Raspberry Pi, BeagleBone Black, nRF51822 (an SoC with an ARM Cortex M0 and a Bluetooth Low Energy radio), the Intel Edison, and the Firestorm platform from UC Berkeley (an ARM Cortex M4 with 802.15.4 and BLE) as starting platforms, but will encompass additional ones as appropriate.

    The overall educational goal of the course is to teach and mentor students how to build robust, easy-to-debug embedded systems. Embedded systems are difficult and foreign to both hardware and software engineers because they incorporate both, and so it can be difficult to reason about different components will affect hardware or software complexity and the tradeoffs between them.


    Week Assignment
    9/26 Thursday 9/29: present one slide on a project idea
    10/3 Tuesday 10/4: project groups/proposals
    10/10 Thursday 10/13: parts ordered, first milestone
    10/17 Tuesday 10/18: 5m class presentation
    10/31 Tuesday 11/1: interim report 1
    11/14 Tuesday 11/15: interim report 2
    11/21 Thanksgiving
    12/5 Tuesday 12/6: draft final report
    12/12 Wednesday 12/14 @12:15: Final presentations/reports