ECE382 Embedded Computer Systems I#
π¨βπ« Instructors#
π Course information#
Course Goal: Develop skills to design, implement, test, and debug microcontroller-based systems by developing operational assembly and C language programs that incorporate the built-in microcontroller functions, and by successfully interfacing the microcontroller to the external world.
Course Text: Embedded Systems: Introduction to Robotics, Johnathan W. Valvano, First Edition, 2019. ISBN: 978-1074544300.
Syllabus: Posted here.
Course Schedule: Posted here and subject to change.
π‘ Communication and Control (C2)#
All communication and announcement π£ will be provided through MS Teams
All lecture π materials will be provided through MS Teams.
Laboratory π¬ work will be posted in this course web.
All assignments must be submitted in Gradescope
Bitbucket will be used for students to provide their source code π for homework and laboratory assignments.
β° Late Policy:#
If problems arise with graded assignments, see your instructor in advance
The cutoff for on-time submission is 07:00 π a.m. on the due date.
Late days are counted in 24-hour periods. Submitting between 07:00:01 on the due date and 07:00:00 the next day is one day late, and so on.
You are given 5 grace days (self-granted extensions) which you can use to give yourself extra time without penalty. No more than 2 grace days (calendar days) can used for each assignment.
Instructor-granted extensions are only considered after all grace days are used and only given in exceptional situations. Computer problems such as hard-drive reimaging are not considered as exceptional situations and you must use grace days.
Late work handed in when you have run out of grace is π₯ discounted up to 20% for the first day late and up to 15% per day late thereafter.
Every assignment has a hard deadline; 4 calendar days past the original due date.
Late submissions (penalty or not) are not accepted after the hard deadline or after the solution to the assignment is published. No late submissions (penalty or not) will be accepted for the assignments right before GRs.
π Documentation Requirements#
All help received on work submitted for grading must be documented in accordance with the course documentation policy.
Each documentation statement must be specific enough that it explicitly describes what assistance was provided, how it was used in completing the assignment, and who provided the assistance.
If no help was received on this assignment, the documentation statement must state βNone.β
If you checked answers with anyone, you must document with whom on which problems. You must document whether you made any changes or not. If you did make changes, you must document the problems you changed and the reasons why.
Vague documentation statements will result in a 5% deduction on the assignment.
Sample Documentation#
Consider the following examples when writing your own detailed documentation statements:
Bad Example: Cadet McFly explained how the factorial worked.
Good Example: Cadet McFly explained how a recursive function worked conceptually, using diagrams and the assignment materials. He did not look at my code nor did I look at his code during this discussion.
Bad Example: : Cadet McFly helped fix my factorial() method.
Good Example: Cadet McFly helped fix my factorial() method by looking at my code** and finding that I had n > 0 instead of n >= 0 on line 85. Note: A situation such as this may result in **less than full credit for the factorial() method, but due to the documentation statement there is no violation of the honor code.
Bad Example: : Cadet McFly and I worked together on the factorial() method.
Good Example: Cadet McFly and I worked together on the factorial() method, each contributing equally to its development. Prior to this help, neither of our factorial() methods was working. My factorial() method is now nearly identical to Cadet McFlyβs factorial() method. Note: In a situation such as this, at most half-credit would be earned for the factorial() method, but due to the documentation statement there is no violation of the honor code.
Bad Example: : Cadet McFly showed me how the factorial() method works.
Good Example: Cadet McFly showed me how the factorial() method works by letting me look at his code. Prior to this help, my own factorial() method was not working. My factorial() method is now nearly identical to Cadet McFlyβs factorial() method. Note: In a situation such as this, no points would be earned for the factorial() method, but due to the documentation statement there is no violation of the honor code.
Bad Example: : Cadet McFly showed me how the factorial() method works.
Good Example: Cadet McFly showed me how the factorial() method works by looking at my code and talking me through each line as I wrote it. Prior to this help my own factorial() method was wrong. My factorial() method is now nearly identical to Cadet McFlyβs factorial() method. Note: In a situation such as this, no points would be earned for the factorial() method, but due to the documentation statement there is no violation of the honor code.
π Recommendations from 23ers - \(\color{red}{\text{Early!!}}\)#
Be prepared to spend a lot of time on this course.
Work \(\color{red}{\text{early}}\) and ask for EI
Get the Labs and HWβs done on time! If you donβt know how, get EI.
Start labs \(\color{red}{\text{early}}\). Get help \(\color{red}{\text{early}}\). \(\color{red}{\text{Early}}\). \(\color{red}{\text{Early}}\). \(\color{red}{\text{Early}}\).
\(\color{blue}{\text{Don't even think about starting any assignments the night before... you will regret your decision every time.}}\)
Start \(\color{red}{\text{early}}\) and ask questions.
Look to the textbook first for questions on code and try to start the labs the night they are assigned so that if you have a question it can be answered the next day, where as if you start the night before its due you are largely on your own.
Start \(\color{red}{\text{early}}\) on every assignment. Set a personal due date at least 2 days before the actual due date to prevent needing to pull all-nighters when stuff doesnβt go right.
Set aside a lot of time to complete assignments for this class.
Start \(\color{red}{\text{early}}\), donβt get behind. Work \(\color{red}{\text{early}}\)
Work on labs \(\color{red}{\text{early}}\) and make sure you understand all the code, it builds on itself.
Start working \(\color{red}{\text{early}}\)
Use the object files if you get behind in Labs rather than fall farther behind.
Try to understand everything. If you donβt make sure you reach out earlier than you think. Labs and homework will take twice the amount of time you expect. Make sure you understand the overall reason for each lab; it will make the final project 50x easier.
Stay on top of the assignments- donβt wait until the last minute andΒ reach out for help if you need it
DO NOT WAIT UNTIL THE LAST MINUTE!!! Go in for EI \(\color{red}{\text{early}}\) and often
Start \(\color{red}{\text{early}}\) and ask lots of questions
Start the labs and the HW the day they are assigned, some of those puppies are more time intensive than you would think. Donβt fall behind because a bunch of the labs build on each other.
Stay on top of HW and Labs. Utilize the discussions channel a lot. If I had an issue someone else usually had the same problem. Review missed questions on HW before the tests. Donβt make the same mistakes twice.
Take time to get the labs right.
\(\color{red}{\text{Early}}\) Birds help you stay on top of your work, and makes nights before demo days less stressful.
Read the textbook and for homework and labs if you understand them
- βοΈ HW 1 Setting up CCS and Git
- βοΈ HW 2 Assembly Basic
- π¬ Lab 2 Assembly Basic
- βοΈ HW 3 Memory
- π¬ Lab 3 Memory
- βοΈ HW 4 Subroutines
- π¬ Lab 4 Subroutines
- π¬ Lab 5 Software Design
- π¬ Lab 8 I/O Interface
- π¬ Lab 10 Multithreading
- π¬ Lab 11 Serial Ports
- π¬ Lab 13 Timers
- π¬ Lab 14 Real-Time Systems
- π¬ Lab 15 ADC
- π Lab15 Sensor Calibration
- π¬ Lab 16 Tachometer
- π¬ Lab 17 Control Systems
- π Final Project