Link Search Menu Expand Document
CSCI 1600, Fall 2026

Course Policies and Expectations

Table of contents

  1. Contacting the course staff
  2. Course Objectives
  3. Book and materials
  4. Assessments
  5. Capstone
  6. Community
    1. My own commitment to you
    2. Your commitment to one another
  7. Accessibility and Accommodations
  8. Class Recording
  9. Academic Integrity/Collaboration Policy
    1. Use of outside sources (including generative AI tools)

Contacting the course staff

For extension and accommodation requests, contact Milda only (per University and department policy, TAs do not handle extension or accommodation requests). Milda is also happy to help with issues that you are not comfortable bringing to a TA. I will not think less of you for asking for help/grace when you need it, and the sooner you reach out, the more options I will have for helping you.

To get a faster response to general course questions, please use EdSTEM to communicate with the staff as a whole. For matters that warrant e-mail, use cs1600tas@lists.brown.edu. Unless asked to, please refrain from emailing individual TAs – you will get a much faster response if you contact all of us.

Course Objectives

  • Recognize the purpose of embedded and real-time software

  • Understand the resource constraints specific to embedded software systems

  • Engineer complex systems that may be connected to multiple sensors and actuators working together

  • Conceptualize how code is loaded and executed on an embedded microcontroller at the architecture level

  • Apply principles of software engineering to developing embedded systems, including specific practices for safety-critical systems

  • Use models of embedded systems to verify properties of the systems

  • Recognize the societal impacts of designing and writing embedded software

  • Engineer an embedded system project developed in collaboration with others, by applying principles learned in the course

Book and materials

There is no official “reading schedule” on the syllabus, but some homeworks will feature readings from Introduction to Embedded Systems by Lee and Seshia (available for free online) Principles of Cyber-Physical Systems by Alur (available for free online through the Brown libraries), or other sources (pdfs of which will be made available when appropriate).

Required hardware: Arduino Uno R4 WiFi and an electronics kit (both available at the bookstore). Note that an Arduino other than the R4 Uno will not work for some of the labs. See the course homepage for information on the electronics kit.

Assessments

This table scrolls to the side! The rightmost column is “Late policy.”

Assignment type Purpose When due Type of grading Collaboration Weight Notes Late policy
Homework Low-stakes way to interact with course with questions that: preview lecture topics so that you can come to class prepared with deeper questions; review and reflect on recent course topics; guide independent research/reading prior to class discussion Most Wednesdays and Fridays at 1pm Good-effort completion Individual 5% One dropped Only with Dean’s note or similar
Class discussion Demonstrate learning from homework and learn from classmates Recorded every lecture Good-effort participation Group discussion encouraged! 10% Not counted until Sep 16. Can miss 3 classes without penalty Mostly handled by “miss 6” policy; documented extenuating circumstances should be discussed with instructor
Lab foundation In-depth learning of concepts necessary for in-person lab. Requires additional reading, understanding stencil code/circuits, pre-computation, etc. Most Mondays at 1pm (even for Tuesday lab students) Automatically graded on correctness; resubmission allowed Individual, good-faith collaboration allowed     Only with Dean’s note or similar
In-class lab Hands-on learning of embedded concepts by building circuits, writing code, and answering conceptual questions from TAs Checked off Monday/Tuesday during lab Checked off according to rubric With partner; good-faith collaboration with other groups allowed 60% (7.5% per lab), with each lab roughly: 20% foundation/40% in class/10% deep dive/15% concept quiz/15% whiteboard check (rubric published for each lab) Must complete all labs (including deep dive, concept quiz, and whiteboard check) to get A in course and 6/8 labs to pass course Any tasks not finished during lab time can be checked off in hours during the following week. Any checkoffs later than that should be arranged with instructor
Lab deep dive Go beyond lab tasks by deeply exploring embedded concepts that connect to the theme of the lab. Low-stakes grading that prepares you for higher-stakes assessments (concept quiz and whiteboard check). Similar in format (and due date) to homeworks, but longer and available for a full week Mondays at 1pm (with next prelab) Good-effort completion Individual     Only with Dean’s note or similar
Concept quiz Assess individual understanding of fundamental embedded concepts from each lab. 10 mins at the end of lecture after each lab (dates posted below) Graded for correctness Strictly individual   SAS students will be contacted with extra-time arrangements Made up with instructor permission only
Whiteboard check Assess individual understanding of concepts explored in lab deep dive during an in-person conversation with course staff 20 minutes four times a semester; scheduled after labs 2, 4, 6, and 8 Done in-person with TA or instructor. Results in discussion notes and a whiteboard deliverable that are graded according to rubric. Strictly individual     Postponed with instructor permission only
Project Demonstrate understanding of the embedded software engineering process (including hardware/software design, implementation, and verification in collaboration with others) by delivering a large-scale final product. Multiple due dates during the semester Good-effort completion and according to rubric. Mostly group; some individual components 25% More information on each part of the project will be posted as class progresses  

Concept quiz dates: (generall the Monday after a lab): 9/21, 9/28, 10/5, 10/19, 10/26, 11/9, 11/16, 11/30

Capstone

This course can be used as a capstone course. You must contribute an individual add-on to the capstone project that brings in knowledge of some other field of CS (for example, some students in the past have developed apps that control/customize some part of their project). After receiving feedback on group project proposals, I will send out a form on Ed asking for your capstone project proposal. For the abstract submitted to the department and to me, please provide an summary of the add-on (what you set out to create, why it was a technical challenge, major design decisions made) and why it demonstrates knowledge of CS within and outside of embedded systems. I’m happy to meet to discuss ideas for your capstone projects.

Community

My own commitment to you

Hardware becomes obsolete, programming tools get introduced, pedagogical best practices evolve, and we revise the course every year in order to keep up with these changes. There may be hiccups along the way, and my intention is to build trust with you so that we can communicate about these hiccups and smooth them out. As such, I will actively be asking for and following up on your feedback about the course (with the intent of demonstrating to you that your feedback is valuable). The policies in this document are subject to change based on our discussions, and will be communicated clearly ahead of time. I will ask for feedback periodically during class, in reflection questions in the lab writeups, and through the anonymous feedback form.

Your commitment to one another

Engineering, including software engineering for embedded and real-time systems, involves working with people to create artifacts that will be used by people. As we will see in this course, it is vital to be conscientious of how we work with others and how the things we build will impact others and society as a whole.

This course has a major participation and collaboration component. My goal is to foster a welcoming and inclusive environment, where your identities and experiences are honored. If you do not feel like this is the case at any point in the course, please let the course staff know.

I am always open to inspecting my own biases or changing the course content/format to better suit students’ needs. If you have concerns, again, please reach out to me personally or submit anonymous feedback. You can also come to the TAs, or contact the department’s student advocates. Department staff and faculty resources include Lauren Clarke (department manager), Kathi Fisler (the director of undergraduate studies), and Roberto Tamassia (department chair).

Accessibility and Accommodations

Brown University is committed to full inclusion of all students. Please inform me early in the term if you may require accommodations or modification of any of course procedures. You may speak with me after class, during office hours, or by appointment. If you need accommodations around online learning or in classroom accommodations, please be sure to reach out to Student Accessibility Services (SAS) for their assistance (seas@brown.edu, 401-863-9588). Undergraduates in need of short-term academic advice or support can contact an academic dean in the College by emailing college@brown.edu. Graduate students may contact one of the deans in the Graduate School by emailing graduate_school@brown.edu.

I also want to acknowledge the very real role stress and mental health play in students’ lives. I will make reasonable accommodations if you contact me for extensions or other mental health needs, and I also encourage you to reach out to CAPS as a university resource. At the department level, you can contact your student health and wellness advocates.

Class Recording

The lecture portion of the class will be recorded automatically using lecture capture. These recordings will be made available to students registered in the class. Feeding the course recordings into any AI tool is forbidden.

Academic Integrity/Collaboration Policy

This class encourages collaboration and cooperation, but also expects that you submit your own work for individual assessments. The distinction between individual assessments and group work is outlined in the table in the Assessments section above. For assignments with a mix of group and individual components (such as the final project writeup), the distinction and expectations will be made clear in the assignment handout.

Use of outside sources (including generative AI tools)

Code/hardware: The homeworks for this course require you to write no code, and the coding component of labs is limited to what we think you can reasonably produce in a 3-hour block while also building circuits and discussing course concepts, so using outside sources (including AI tools) for this code isn’t very practical (i.e., it should go without saying that you shouldn’t do it). You are allowed to use or draw inspiration from software libraries, circuits/hardware tutorials, etc for the final project, as long as you attribute your sources. You are not allowed to simply copy a project someone else has done. You can use AI tools to help you write your project code, but you must make sure the code matches the written artifacts you produce and that you can fully explain your project’s software architecture in your demo.

Non-lab in-person components: No outside notes/tools are permitted for the concept quizzes. Notes are allowed (and encouraged) for whiteboard checks and in-class activities, but generative AI tools are stricly forbidden during whiteboard checks.

Writen components: The work you turn in should be written by you. If you use outside sources, please cite them.

Studying: The line between using one to truly help you further your own learning vs. having it do your work (and, more importantly, thinking) for you is a thin one, it’s often easy to trick yourself into thinking you know where it is. If you do use AI tools to help you think through course concepts before creating written work, calibrate the level of support you ask for to that of a TA (asking for the definition of a term or asking you to quiz you on material is fine; asking it to generate work for you to turn in is disallowed). A word of caution: LLMs do not have the full context of our class, and may introduce additional background that is external to the learning goals of the course, or just uses vocabulary with a different convention to the one I’ve decided adopt for class. Your instructor and TAs are often the best resource for asking about course concepts!

Finally, make sure you can stand behind your work. The easiest way I’ve found to confirm suspected AI use is to ask a student “what did you mean by the [jargon phrase] you wrote here?” Last year, I graded a final project report where all of the design artifacts were generated post-hoc from the code implementation (which was also AI-generated). Not only was the writeup quality poor, but flew in the face of all embedded software engineering best practices (a major learning goal of the class). Don’t do this, or anything equivalently embarassing enough to make it into my syllabi as a cautionary tale.