Lab Assignments

Hello World


  • Get the development environment from sourceforge.
SourceForge SJSU Development Package
  • Compile a sample FreeRTOS sample project
  • Load it onto the processor
  • Add a terminal command to your project, have it do something creative (Like print temperature on the screen)

Reference this article on how to add a terminal command:

SUBMIT YOUR CODE online (copy/paste to Text Entry box). Or simply provide me a link if you use Gitlab or other online repository for your code submission.

Only submit the relevant code, or just the code you added.

LED Switch


Work in groups of 2 and use existing API under gpio.hpp:

  • Interface an external LED (such as P2.1) to "Board A", which we will refer to as "LED Board"
  • Interface an external switch (such as P2.2) to "Board B", which we will refer to as "SW Board" (switch board)
  • Connect the LED Board and SW Board together using "Port 2"
    Example: P2.0 of LED board connects to P2.0 on the SW Board
    Do not forget common ground
  • LED board Software is simple, whenever P2.0 (which is interfaced to the SW Board) is detected HIGH, light up its LED (on P2.1), else turn it off
  • On the SW Board, use "External Interrupt" API (eint.h) to detect when the switch gets pressed
    The callback should simply turn a flag (global variable) to true
    The callback MUST NOT POLL, and MUST NOT DELAY, and EXIT IMMEDIATELY since it is an interrupt function
    Use period_init() function to initialize the callback. This initialization function is only called once before starting the RTOS
  • On the SW Board, use the periodic callbacks, and when the flag is true, toggle the P2.0 for at least 500ms
    Turn on the periodic scheduler at main.cpp
    Deploy your code to periodic_callbacks.cpp (like 10Hz function)
  • Bonus points: Use a binary semaphore in the interrupt, and have the 10Hz task wait on this semaphore with 0 ms block time. See the FreeRTOS video about the binary semaphore
    Note that if you use a periodic callback, you will have to use zero block time for the semaphore since you do not want to block in a period function.
    Binary Semaphores

For the demo:

  • The SW Board should detect its switch press by an external interrupt and toggle its P2.0
  • The LED Board should detect its own P2.0 and light up the LED

This assignment demonstrates the use of external interrupts, and how to interface different boards together. Furthermore, you should have learned the concepts of different tasks that you can run in FreeRTOS. In general, you should never have to poll for events, and you should use interrupt functionality as much as possible. Turn in ONE SUBMISSION per group with the following:

Only turn in the relevant source code, such as main.cpp Indicate at the top of the file who you worked with. (Do not have the other person turn in anything)

Form Groups


Communicate with one of the class ISA to setup your groups @ Canvas. Be sure to have your group name ready and use an appropriate group name.

Failure to do so by the deadline will result in zero points for the assignment. Be sure to do this before leaving the class.

Also, order CAN transceiver hardware for your entire team (1 per person)

Serial Communication


Use either UART2 or UART3 to communicate between two boards. You can work in groups of 2.

  • Locate the UART pins on your board.
    Use the schematic or Wikipedia board article.
  • Interface to the UART pins on someone else's board.
    If you use UART2, you cannot use UART2 on the 2nd board (use UART3 instead).
  • Prove that both of your boards and communicate with each other.
  • Bonus points for doing something creative, such as one board acting like a random sensor, and the second board outputting the sensor reading on the LED display.
  • This assignment demonstrates how to communicate with another device using UART. The UART driver is based on queues, there is no need to poll for data to arrive, or for data to be sent. Size your queues appropriately and they shouldn't be too large or too small. For example, if you service the received data every 100ms, then your queues should only need to be as big as the number of characters you expect to receive within 100ms (38400bps can provide 400 chars in 100ms).

Turn in ONE SUBMISSION per group with the following:

  • Only turn in the relevant source code, such as main.cpp for both boards

Unit Testing


Write unit test for motor_driver.h API that will require you to use a "mock" for the sensor.h


  • Add to the CGreen Makefile motor_driver.c (follow the examples there)
  • Follow the Unit-Test template below
  • Add your new test to the test_main.cpp by #including "test_motor_driver.cpp"
// -------------- // motor_driver.h // -------------- #ifdef __cplusplus extern "C" { #endif // badly written code (doesn't follow TDD) int get_motor_pwm(void); #ifdef __cplusplus } #endif // -------------- // motor_driver.c // -------------- #include "motor_driver.h" #include "sensor.h" int get_motor_pwm(void) { const int sensor_value = get_sensor_value(); int value; if(sensor_value < 0 || sensor_value > 100) value = -1; else if(sensor_value >= 0 && sensor_value < 50) value = 1; else if(sensor_value >= 50 && sensor_value <= 100) value = 5; return value; } // -------------- // sensor.h // -------------- #ifdef __cplusplus extern "C" { #endif int get_sensor_value(void); #ifdef __cplusplus } #endif

#include <stdio.h> #include <cgreen/cgreen.h> #include <cgreen/mocks.h> using namespace cgreen; // The file under test #include "motor_driver.h" extern "C" int get_sensor_value(void) { return mock(); } Ensure(test_bad_values) { expect(get_sensor_value, will_return(-1)); assert_equal(get_motor_pwm(), -1); } TestSuite *motor_driver_get_test_suite() { TestSuite *suite = create_test_suite(); add_test(suite, test_bad_values); return suite; }

Project Setup


Setup your Project Report Template:

  • Go to your class webpage:
    CmpE 243 Home Page
  • There should be a "Red Link" that I created for you to edit; Red-link means that "This Wiki article doesn't exist yet"
    Make sure you are logged into the SocialLedge Wiki, and then click to edit this page
    Rename one of these bullet points to your project name (use a wise name for your project):
    Tag your project with "F17" or similar, such as:
    [[F17: Spartan and Furious | F17: Spartan and Furious]]
    Click to save this page
  • In a separate window, browse to this page, click "Edit" and COPY the entire Wikipedia markup
    Now click on the red link that belongs to your project
    Paste this template for your project, and work on setting weekly goals in your schedule section.
    Save the template
  • Now go back to your project's Wiki page, click "EDIT"
    Add information about the team members
    Add a link to your GITLAB project and add users who can access your project:
    My GITLAB username is simply, "preet"

CAN Communication


You can work in groups of 2:

  • Build and interface the CAN transceiver with another person's CAN transceiver.
  • Initialize the CAN Bus (read can.h in the drivers directory).
  • Use a simple periodic message (every 100ms) that is sent from BoardA to BoardB.
    For example, if BoardA senses a switch pressed, send a 1-byte message with 0xAA, otherwise send 0x00 if button is not pressed
  • For robustness, if the CAN Bus turns off, simply turn it back on at 1Hz (every 1000ms)
  • On BoardB, simply light up an LED (or otherwise turn it off) based on the CAN message data

This assignment gives you an overview of practical use of the CAN Bus, and later, by utilizing the DBC file and auto-generation of code, sending and receiving data becomes very easy.

While this provides bare bones knowledge of how communication works, the future lectures will focus on the application layer while abstracting away the details of CAN messages' data encoding and decoding.

Although the real-time periodic scheduler was not discussed, it might be worth your time to simply turn it on (using #define) since it can help you send periodic messages fairly easily. This will also help you prepare in advance for the future lectures.

Only turn in the relevant source code, such as main.cpp for both boards.

Wiki Schedule


Write a schedule that is a list of your team's milestones. This is a tool for you to assign responsibilities and deadlines for your project's milestones. In general, this should list out when the team as a whole expects a certain functionality to be delivered.

The grading will depend on how well you have assigned your milestones and if the goals are measurable. For example, milestones such as "interface sensor and send sensor data over CAN messages" and "add a filter for the sensor data" are measurable goals, whereas, "interface sensor", and "send data" are too generic and un-measurable goals.

Periodic Scheduler



Easy homework, use the periodic tasks to add two functions that they call, run your program, and then do the following:

  • Modify main.cpp to configure the periodic scheduler, and leave the terminal task present that you will use later in the assignment
  • Design a Software based "filter". The simplest one could be to average a few readings but read and research more on Wikipedia (they even have Psuedocode)
  • Add the two new "Sensor" periodic callbacks, one at 1Hz, the other at 10Hz
    In the 10Hz callback, design a Software filter to filter the Light sensor readings
    In the 1Hz callback, print out the filtered sensor reading.
  • Do more experiments with the "Logging" capability
    Log some data using LOG_INFO() or similar message from file_logger.h
  • Use "info 5000" command to see CPU utilization for 5 seconds.
  • Use "cat log.csv" to view the log file data.

Attach your output to Canvas along with your code.

CAN TX / RX using Auto-gen code


Work in groups of 2 by assuming one board is the DRIVER while the other board is the MOTOR or SENSOR.

The objective of the assignment is to demonstrate CAN data handling using the auto-generated code. Follow these steps:

  • Define a DBC message that your controller sends (TX)
  • Define a DBC message that your controller receives (RX)
  • Attempt to recover the CAN Bus (from Bus OFF) at 1Hz (both Boards)
  • Send the TX message from BoardA at a fixed frequency, such as 10Hz
  • Attempt to receive the RX message (on BoardB) at the designated frequency, and light up an LED when the message enters the MIA state
  • Prove that the MIA handling is occurring as intended (simple LED test by disconnecting the board that sends you a periodic message).
  • Prove that valid data is being received and reacted upon (such as displaying received sensor reading on the LED display)

This is a powerful assignment that demonstrates how to send and receive data using the auto-generated code that is derived from your DBC file. This will be the stepping stone of the overall CAN communication that will occur in your project.

Final Wiki Schedule

DBC File


Create your CAN communication format for each controller and link your DBC file to your Project report at your wikipedia page.

Make sure that the auto-generated code is created as intended and that you don't run into a DBC or the auto-generation issue. In other words, the auto-generated code should compile on all controllers.

CAN Communication Demo


Demonstrate that each ECU is able to communicate over the CAN Bus

  • Code should utilize the auto-generated artifacts from the DBC file
  • MIA handling should occur on the messages that are expected to be received
    Upon MIA, an LED indicator should indicate that there is 1 or more message in the MIA state

In person demonstration should be given for this assignment and there is nothing to turn in otherwise.

Producer / Consumer Tasks


  • Create a task that polls the acceleration sensor, and determines the orientation of the board, such as "up, down, left, right". Create an enumeration such as "typdef enum { invalid, up, down, left, right, }orientation_t;
  • Create a queue, and have the first task send orientation values every second to the queue.
    Print something BEFORE and AFTER sending the enumeration value to the queue.
  • Create a task that is waiting on the orientation enumeration to be sent by the previous task.
    Print something immediately after the second task receives the data from the queue.
  • Use same priority for both tasks and note down the print-outs.
  • Alter the priority of second task to use higher priority, and note down the print-outs
    Note down your results, and submit it at the top of your code submission.

Project Prototypes


Project prototypes are expected to demonstrate the following:

  • Reliable CAN communication between different ECUs
  • Basic obstacle avoidance (free-run mode)
  • Reliable sensor inputs (PCAN will be used by class mentors to assess)
  • Reasonable motor commands (PCAN will be used by class mentors to assess)
  • Extra credit if you go above and beyond and show even more progress such as a working Android app



Your GIT repositories will be audited to assess how much contribution you have made to your GIT project. At minimum, there should be something checked-into the main branch to demonstrate that you know how to use GIT.

Individual Contribution

You will be grading your group members based on how much or how little they contributed to the project. You must be ethical, and honest, and not go based on your "emotions".


Name Letter Grade Notes Last1, First1 A This student was involved in all aspects of the project design and was present at all group meetings. Last2, First2 C- This student contributed to writing the report but was absent for many group meetings.

TDTS06 Computer Networks

Lab assignments

Required (mandatory) assignments

The lab series consists of a series of programming assignments to be presented gradually to a lab assistant. To pass the lab series you need to have passing grade on all required (mandatory) assignments. General guidelines can be found here.

The assignments should be handed in before their respective deadlines, as outlined below.

For most people there will NOT be enough time during the lab times to solve all the assignments. As some of the later assignments can be demanding, and require programming, you are responsible to work hard outside of the allocated lab times to keep up with the labs. Based on past courses, we strongly encourage you to work hard from the first week of the course. Students that fall behind often struggle to catch up.

IMPORTANT about deadlines (updated 10/10/2017):
  • October 14 is the recommended semi-hard deadline for the assignments. You strongly recommend that you have all assignments completed by this time, as this greatly will improve your chances to pass the assignments.
  • October 17 is the first hard deadline for the assignments. This is the last date for demonstration of, and handing in the code for, the assignments. From this date up until the exam, the TAs will not answer any questions about the labs. Please use this time to study for the exam.
  • For those assignments that still require "more work", the final, hard deadline is on November 3, at 17.00. This is the last date for demonstration of, and handing in the code for, the assignments. Contact your lab assistant and schedule a suitable time.
  • After the deadline you will only be allowed to hand in assignment solutions during the exam periods for the TDTS06 course in January, but only if you have previously passed at least assignments 1 and 2. The hard deadline to hand in the assignments during the January exam period will be at the date of the TDTS06 exam (during that period).
  • From the date of the hard deadlines, there will be a two week window during which you have one chance to address the TA's concerns and resubmit an improved version. (One week for the TA to mark the assignment and one week for you to address his/her concerns.)
  • Finally, please take the TA's concerns seriously and address them as carefully as possible. If you have problems keeping a deadline, please contact your lab assistant as soon as possible.
Other notes and advice for the assignments:
  • For all emails regarding the assignments, you should use your LiU email and cc your lab partner.
  • Advice: The first assignment is relatively straight forward, is intended as a warmup exercise that helps you get prepared for the second assignment. It is expected to be done very quickly in the first week, so that you can hit the second assignment running. The second assignment can be much more time consuming and it is strongly recommended that you start it as soon as possible and work hard, so that you can solve, demonstrate, and report the results within before the September deadline. Of course, doing assignment 1 carefully will help here.

Assignment series overview

  • Similar to in your future work life, many of these labs have more than one solution/answer and require that you to digg through various sources of information (including the assignments instructions themselves, textbooks, online resources, and other resources that you may find credible and helpful) to identify the most important information and what you need to reach a solution. You may therefore need to read the instructions multiple times, revisit the information in the instructions (and other resources), and search for yet new information as you refine your solution. At times, you may also need to try new paths as you learn how to best tackle the problem and learn more about each assignment.
  • With a lot of available information, you may in some cases need to read the full instructions multiple times to determine what is expected from you. In fact, in assignments such as assignment 2, a non-trivial part of the assignment is to determine the requirements and identify the steps to get there. (Note that we have been nice and "sprinkled" some hints for you on the way.)
  • You are also required to carefully explain your solutions and findings both verbally and in a written report. Please take this as a learning opportunity to communicate your solutions and findings.
  • Assignment 2 and 4 require substantially more work than assignment 1 and 3. Therefore, please make sure to finish assignment 1 quickly so that you stay on pace with the assignment series.
  • The lab slots are primarily to demonstrate the labs and ask questions to the TAs. Outside that, you are expected to allocate the time necessary for you and your lab partner to complete the assignments.

Registering in Webreg
  • Register here
  • Deadline: 30.08.2017 (or as soon as possible!!)
  • Note 1: Assignment 2 will include learning socket programming in C/C++, java, python or Ruby.
    Recommended groups:
    • C/C++: B, C
    • Java: A
    • Python: A
    • Ruby: C
  • Note 2: Unfortunately, non-registered international students have occasionally had problem to register in WebReg. If you have problem registering in the course, please try at the student center. Once you are registered for the course AND verified your selections on the student portal you should (supposedly) be able to sign up in WebReg. (Unfortunately, it also appears that you may have to wait a day or so for the registrations to get through the system and your IDA accounts to be activated.) In the meantime, I would strongly suggest that you start doing the assignments (and attend the lab sessions).

Assignment 1: "Wireshark lab: Getting started + HTTP" (1 time slot)
  • Instructions
  • Target deadline: Sept. 2 (for purpose of priority)

Assignment 2: Net Ninny (3 time slots)
  • Instructions
  • Sockets and Assignment 2 lecture (Vengatanathan): 2016
  • Important note: This assignment can take time ... To complete this assignment on time, you are therefore strongly advised to spend lots of time on it as soon as possible.
  • Target deadline: Sept. 23 (for purpose of priority)

Assignment 3: Transport-layer and TCP friendly protocols (2 time slots)
  • Instructions
  • Target deadline: Oct. 7 (for purpose of priority)

Assignment 4: Distance vector routing (2 time slots)
  • Instructions
  • Target deadline: Oct. 14 ("semi-hard" for all assignments, please see deadline for labs above)

Optional (bonus) assignment

Solving an optional assignment during the course can render you up to 4 extra points to be used for the written examination (but not resit exams).

Old assignments

Previous year's assignments can be found here: 2010, 2011, 2013, 2014, 2015.

Page responsible: Andrei Gurtov
Last updated: 2017-10-10

0 thoughts on “Lab Assignments

Leave a Reply

Your email address will not be published. Required fields are marked *