Revision as of 01:16, 31 August 2016 (view source) 243 user2 (talk | contribs) (→‎Final Wiki Schedule) ← Older edit		Revision as of 01:17, 31 August 2016 (view source) 243 user2 (talk | contribs) (→‎Project Wiki) Newer edit →
Line 277:		Line 277:
	= Project Wiki =		= Project Wiki =
		+
		+	=== Due ===
		+	Dec 20 at 6pm

---

Revision as of 01:17, 31 August 2016

Hello World

Due

Sep 6 at 6pm

Assignment

1. Get the development environment from sourceforge.

SourceForge SJSU Development Package

2. Compile a sample FreeRTOS sample project

3. Load it onto the processor

4. 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:

http://www.socialledge.com/sjsu/index.php?title=SJ_One_Board

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

Due

Sep 13 at 6pm

Assignment

Work in groups of 2:

• Interface an LED (such as P2.1) to "Board A", which we will refer to as "LED Board"
• Interface a 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
• LED board Software is simple, whenever its 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
• On the SW Board, launch a separate task, and when the flag is true, toggle the P2.0 for at least 500ms
• Bonus points: Use a binary semaphore in the interrupt, and have the task wait on the semaphore instead of polling. See the FreeRTOS video about the binary semaphore

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

Due

Sep 13 at 9pm

Assignment

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

Due

Sep 20 at 6pm

Assignment

Use either UART2 or UART3 to communication 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 another UART on someone else's board.
• If you use UART2, you cannot use the same UART2 on the 2nd board (use UART1 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 demonstrate how to communicate to another device using UART. The UART driver is based on queues, and 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

Project Setup

Due

Sep 27 at 6pm

Assignment

• Setup your Project Report Template
• 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"

To copy the project template, follow these steps:

Go to your class webpage:

http://www.socialledge.com/sjsu/index.php?title=Realtime_OS_on_Embedded_Systems

Go to "Project Template", click "Edit" and COPY the entire Wikipedia markup

Paste this template for your project, and work on setting weekly goals in your schedule section.

CAN Communication

Due

Oct 4 at 6pm

Assignment

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 at 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 the bare bone knowledge of how communication works, the future lectures will focus on the application layer while abstracting away the details of CAN messages's 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.

Wiki Schedule

Due

Oct 11 at 6pm

Assignment

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

Due

Oct 11 at 6pm

Assignment

INDIVIDUAL HOMEWORK:

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

Due

Oct 18 at 6:30pm

Assignment

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

Due

Oct 25 at 6pm

DBC File

Due

Oct 25 at 6pm

Assignment

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

Due

Nov 1 at 6pm

Assignment

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

Due

Nov 1 at 6pm

Assignment

• 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 task that is waiting on the orientation enumeration to be sent by the previous task.
• 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.
• 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

Due

Nov 8 at 6pm

Assignment

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

Git

Due

Nov 8 at 6pm

Assignment

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.

Project Prototypes 2

Due

Nov 29 at 6pm

Assignment

The second version of the project prototypes should demonstrate additional functionality from the first, such as:

• Motor feedback being used to drive the car (the car should not get stuck on an up-hill ramp)
• Android/iOS app displaying useful data
• I/O board displaying useful data

Project Final Demo

Due

Dec 17 at 9am

Project Wiki

Due

Dec 20 at 6pm