Difference between revisions of "ECE497 CAN Cape"
(formatting adjustment of work breakdown) |
|||
Line 2: | Line 2: | ||
{{YoderHead}} | {{YoderHead}} | ||
− | Team members: [[user:Mehlda|David Mehl]] | + | Team members: [[user:Mehlda|David Mehl]] and [[user:Khansa| Sabeeh Khan]] |
== Grading Template == | == Grading Template == |
Revision as of 18:52, 2 November 2016
Embedded Linux Class by Mark A. Yoder
Team members: David Mehl and Sabeeh Khan
Contents
Grading Template
I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!
00 Executive Summary 00 Installation Instructions 00 User Instructions 00 Highlights 00 Theory of Operation 00 Work Breakdown 00 Future Work 00 Conclusions 00 Demo 00 Late Comments: I'm looking forward to seeing this. Score: 10/100
(Inline Comment)
Executive Summary
Our project combines a cape circuit board design with the necessary software to configure the Beaglebone Black in order to view the messages on a CAN bus using the can-utils package. The use of jumpers allows for the cape to be adaptable to different situations (such as CAN development, sniffing a vehicle bus, evaluating CAN transceivers, etc) by allowing the user to select whether or not to use a terminating resistor, 3.3V or 5V for the transceiver chip, and if they would like an OBD-II signal ground to be connected to the ground pour of the board.
The first revision of the circuit board has been tested and is functioning as expected, and the configuration script is setting up the pins properly. We were able to read the CAN messages off of a homemade CAN bus built out of two dsPIC33EV256GM102 microcontrollers
We attempted to use a device tree overlay, but it failed to configure the pin registers correctly, if at all. We will be investigating this issue further, but as far as functionality is concerned the configuration script gets the cape to work without issue
The CAN cape will be an excellent tool for anyone wishing to look at CAN communication traffic on a bus or attempting to explore CAN system development. It will be flexible enough to meet almost all CAN development needs with only minor adjustments required to the setup steps to achieve different functionality (active bus participant vs. spy, setting bitrate, etc)
Packaging
If you have hardware, consider Small Build, Big Execuition for ideas on the final packaging.
Installation Instructions
Give step by step instructions on how to install your project.
- Include your github path as a link like this to the read-only git site: https://github.com/MarkAYoder/gitLearn.
- Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.
- Include a Makefile for you code.
- Include any additional packages installed via opkg.
- Include kernel mods.
- If there is extra hardware needed, include links to where it can be obtained.
User Instructions
Once everything is installed, how do you use the program? Give details here, so if you have a long user manual, link to it here.
Highlights
Here is where you brag about what your project can do.
Include a YouTube demo.
Theory of Operation
Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.
Work Breakdown
Create PCB Footprints: Sabeeh and David
Create Schematic: David
Create PCB Layout: David
Explore Device Tree Overlays: Sabeeh
Create Setup Script: Sabeeh
Verify First Revision PCB: Sabeeh and David
Verify Second Revision PCB: Work in Progress, target date 11/8/16
Verify Overall Functionality: Work in Progress, target date 11/8/16
Enhance User Interface: Time permitting, target date 11/10/16
Future Work
Suggest addition things that could be done with this project.
Conclusions
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.
Embedded Linux Class by Mark A. Yoder