My Project
|
Introduction
Version Log
Acronyms
API's
Coding Standard
Documentation
Requirements
Testing
Tools
This document serves the purpose of providing the background and details of the embedded software that was developed for ........
Provide an introduction to the project, its purpose, and basic overview of what the system does.
Final build capable of detecting an event through Adc and storing the event to RAM. RAM data can be retrieved through the CAN bus.
Any acronyms used within this documentation are defined here.
A2D - Analog to Digital Converter
ADC - Analog to Digital Converter
ATD - Analog To Digital converter
CAN - Controller Area Network
DIO - Digital Input / Output
I2C - Inter-Integrated Circuit
MCU - Micro Controller Unit
MEM - Memory
RAM - Random Access Memory
ROM - Read Only Memory
RTC - Real Time Clock
SPI - Serial Peripheral Interface
SYS - System
TMR - Timer
TSK - Task WDT - Watchdog Timer
Any abbreviations used within this documentation are defined here.
Rq - Request
Rs - Response
Sm - State Machine
St - State
The Application Programming Interface (API) describes the functions that are available to the application for accessing the peripherals and library routines.
"Update this section with an API or links to the API's used in the software. "
Some useful functions for controlling CAN
The XXXXX Coding Standard was used to develop the embedded firmware for this project. While the standard itself is extensive, a general overview is presented here so that a basic understanding of how the code is organized and developed can be understood.
"Update this section with a description of the Coding Standard used, where it is located and some highlights" "Some basic examples are below"
Function names should conform to the following standard,
For example,
Common first words after the sub-system name,
For function prototype parameters,
For local variables (to a function),
For example,
Here is a list of sub-system names. More can be added as needed.
Adc - Analog to Digital Conversion
Dio - Digital Input/Output
Eep - EEPROM memory
Flash - Flash memory
Icu - Input Capture Unit
Mcu - Micro-Controller Unit
Pwm - Pulse Width Modulation
Rtc - Real-Time Counter
Spi - Serial Peripheral Interface
Sys - System Swu - Software UART
Tmr - Timer Test - Testing functionality (anything using this sub-system name should be conditionally compiled so that it does not end up in production code).
Wdt - Watchdog Timer
Code formatting and style shall conform to the following guidelines.
For example,
How To Add An Image To This Documentation: You can include images in the documentation by writing "(\image html filename)". If you put it alone on a line it will be embedded in place. Doxygen supports gif, jpg, jpeg, png, and bmp files. Place the images in the "Doc/Images" directory.
Application "Gimp" can convert a PDF file into a jpeg, png, or bmp. http://www.gimp.org
To combine images that are on 2 different pdf pages:
When adding pictures from a camara, the resolution is usaully too big. I like to scale it down to 800x600.
Application "PDF Split and Merge" can split a PDF document into single pages. http://www.pdfsam.org
PDF Escape can be used to edit PDF files. It is web based (nothing to download). You upload a file and can then edit it. I just use it for copying text from datasheets and then pasting it into my documentation. http://www.pdfescape.com
Edraw is used to generate the architecture and design documents.
Edraw can be used to draw many different kinds of diagrams. It currently has special objects to help draw entity relationship diagrams, UML diagrams, flowcharts, network diagrams, and many other diagrams.
Doxygen is used to generate all the HTML related documentation directly from the source. Information on how to install it and how to properly document your code can be found at http://www.stack.nl/~dimitri/doxygen/index.html
Refer to the Software Requirements Specification for a detailed view of the requirements for the embedded software. Refer to the quick spec 2 for details on the system requirements.
This section is where testing and validation is demonstrated and explained. How test cases were developed. How test cases were determined. Estimated number of bugs per 1k of code. Bug tracking. Things to do.
Currently any bugs which are found in the software are recorded and logged on the Trac website. Reports can be generated on tasks by milestone, user, version etc. Bugs which need to be added to the list can be added by visiting the Trac site at the following link:
update link
Currently any tasks which resulted from software features that need to be added are stored on the Trac website. Reports can be generated on tasks by milestone, user, version etc. Features which need to be added to the list can be added by visiting the Trac site at the following link:
update link
This section explains a number of software development tools which were instrumental in the development of this firmware. These tools include a source code version repository, compiler and IDE, code metrics tools and static analysis tools. Details on each tool can be found below:
The XXX embedded firmware is stored on the XXX SVN server located at UPDATE LINK. The primary client which was used during development was the Tortoise SVN client which is an open source SVN client.
Tortoise can be downloaded from http://tortoisesvn.net/downloads.html. Once downloaded, intstall by double clicking the executable and follow the on-screen instructions. It will be necessary to restart the computer in order to get the sub menu's available by right clicking in windows explorer.
In windows explorer, right click in the C:/ path and select SVN Checkout as shown in the image below.
Enter the following repository information as shown in the image below:
The source can now be accessed from the c:/bears/ directory.
The compiler that was used was the default compiler included in the S12X version of Code Warrior. Production compilation was done with the linker for S12.
Latest Code Metric Report will go here.
Lint is a static analysis tool which was used to analyze the code and check for suspicious and non-portable constructs that were likely to cause bugs. In this case, PCLint from Gimpel. Static analysis performs additional checks that the compiler does not perform. A few examples of these are
Lint integrates into Code Warrior as a separate linker option. It also includes additional checks that can be enabled such as MISRA standard checks. Lint was used primarily to check for inconsistancies which could cause bugs and duplications that could lead to misunderstanding the code. A complete list of checks that lint performs can be found at
http://gimpel-online.com/MsgRef.html