Course Policies and Expectations

Table of contents

1. Contacting the course staff
2. Course Objectives
3. Book and materials
4. Assessments
   1. Summary
   2. Homework
   3. Labs
   4. Project
   5. Capstone
5. Classroom Community
6. Diversity, Equity, and Inclusion
7. Accessibility and Accommodations
8. Class Recording
9. Academic Integrity/Collaboration Policy
   1. Use of outside sources

---

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).

Supplemental reading and materials will be made available when appropriate.

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

Summary

Homework

Homeworks are small assignments meant to prepare you for lecture (for example, by having you do a reading, work on an exercise and write down follow-up questions to be discussed in class, or create a small presentation on a relevant topic). Homework exercises are due one hour before the corresponding class day. During some clases, students will be called on to present their homework and participate in group discussions. Homework is graded on “good faith” effort/completion, rather than correctness. Because homeworks are often tied to the in-class participation of the corresponding class session, there are no late homeworks accepted without a Dean’s note.

Labs

Labs are larger technical assignments that will include prelab, in-class, and writeup/IOA components.

Prelab: these assignments cover prerequisite material for the corresponding lab, in order to ensure that everyone comes to lab prepared. They are due before each lab through Gradescope. The prelab is graded automatically, and gives you immediate feedback on whether a response was correct or incorrect. The official due date is 1pm Monday on weeks that the lab is being held, but the Gradescope is open until the night of the Tuesday lab. You must do the prelab before coming to lab. For some labs, the TAs will ask to see your completed prelab when checking you off for lab.

In-class lab: during lab, you will work through a written set of instructions to build circuits, write code, and discuss conceptual questions with a partner (larger groups permitted at the beginning of the semester; general collaboration within the room allowed and encouraged). You will demonstrate your circuits to TAs. If you do not complete all tasks by the time the scheduled lab slot ends, you can get checked off in hours. When working in pairs, we ask that you work with a different partner every time.

Writeup and IOAs: the writeup is an invidual, written assignment that asks conceptual questions related to the lab topic and relevant lectures. Because these are the only non-low-stakes individual assessments in the course, the intent is for you to demonstrate that you are meeting the course learning goals through your responses. In past years, we’ve found that the written component is sometimes insufficient for this aim – sometimes students misinterpret a question, or don’t go as deep as we’d wish, or say something insightful that isn’t reflected in the rubric, so we’re now supplementing the writeups with IOAs (Interactive Oral Assessments). Twice in the semester (once after labs 1-4, once after labs 5-8), you will schedule an IOA with Milda. This is a short, 1-on-1 conversation where Milda asks you follow-up questions to your writeup answers for the corresponding labs. There won’t be trick/surprise questions here – if you’ve paid attention and participated in class and completed all parts of the lab in good faith, you will have the background you need to succeed in the IOA. You will be able to refer to your writeup responses/personal notes in the IOA (but you must have your screen visible to Milda at all times if you bring a computer). At any point in the semester after the first lab writeup is released, you can request an informal “practice run” at Milda’s office hours, either by yourself or with friends. Because IOAs are scheduled individually with Milda, they can be postponed if extenuating circumstances require, but they cannot be waived (everyone has to complete two, in-person).

Breakdown of grading: Each lab will come with its own rubric. In order of decreasing weight to each lab grade: IOA/writeup, in-class checkoff, prelab.

Late policy: Late labs are accepted up to a week after the deadline with a 10% penalty (can be waived or extended in light of special circumstances by contacting Milda). Lateness is calculated according to the hand-in date of the lab component (so you could, for example, finish the lab on time, but receive a late penalty on the writeup). Late prelabs are not accepted without prior approval.

Because in-person labs and collaboration are a large part of the class, there is no remote option for the class. If you have a circumstance that requires you to miss lab for a portion of the semester, please contact Milda for accommodation.

Project

A major component of the course is a group project that draws on principles taught in class. A project proposal and mid-point demo and report are due during the semester, and a final demo and report are due at the end of the semester.

In lieu of a final exam, the reports (group and individual) are the conduit by which you can provide evidence that you met the learning objectives of the course. To give you a fair chance at communicating this, the reports will ask you to answer specific questions about how your project meets these objectives. Milda may reach out to your group or to you individually to ask follow-up questions on the writeup.

Late projects are not accepted except by exceptional circumstances at the discretion of the instructor.

Capstone

This course can be used as a capstone course. No additional work is required, as long as you fairly contribute to your group’s final project. For the abstract submitted to the department, please provide an summary of the project (what you set out to create, why it was a technical challenge, major design decisions made) and highlight your individual contributions to the group.

Classroom Community

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.

Diversity, Equity, and Inclusion

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.

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 will be made clear for all assignments.

From the University’s Academic Code (page 5), “A student’s name on any exercise (e.g., a theme, report, notebook, performance, computer program, course paper, quiz, or examination) is regarded as assurance that the exercise is the result of the student’s own thoughts and study, stated in his or her own words, and produced without assistance, except as quotation marks, references, and footnotes acknowledge the use of printed sources or other outside help.”

Use of outside sources

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.

Writen components: The work you turn in is expected to be your own. If you use outside sources, please cite them. In terms of AI tools, 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. You are expected to be able to justify and elaborate on anything you’ve handed in when asked. The IOAs are a formal mechanism to this effect.