Report Finished!

Deserves a few beers I think ;-)

Mask Set Errata

http://www.freescale.com/files/
microcontrollers/doc/errata/MSE9S12DP256B_1K79X.pdf

There is a few things in here about the CAN and other relating issues

Sputnic Project Group Meeting - Minutes

Agenda:
1. Project Labs
2. Licences
3. Mailing List
4. Poster Presentation
5. Cross-over of projects
6. Resources / Shipping List



1. Project Labs
5th year MEng students have already been assigned a lab within the Royal College building. Room R169.

Honours Students will be assigned some PCs within the Arrol Lab (L1009).
This is yet to happen, however, the process of getting these systems is underway.
There might have to be some sort of booking system put in place for these machines.
There might be the need for a hardware lab as well. Students would use this lab for implementing any addition hardware.

2. Licences
The 5th year students will need a licence for their R169 project lab.
System support are going to install the licences onto PCs in the arrol lab and hopefully they will have this sorted out by the end of next week.
Furthermore, we will hopefully be able to get licences for our home machines, however, to have a fully functional home machine will depend on the amount of BDMs available.

3. Mailing List
A mailing list has been set up as sputnic@cis.strath.ac.uk, however, it is not fully active yet. You will recieve an email once you have been subscribed to it.
In addition to the mailing list, a wiki (tikiwiki) has been set up.
Http://www.cis.strath.ac.uk/local/wiki

We are encouraged to use this to this wiki to share common information about the Sputnic projects.

4. Poster Presentation
Week 11 - 6 x A4 (landscape)
As advised by the 5th year students, the use of a Gant chart is recommended.
The Poster Presentations will be cover in more depth at another time.

5. Cross over of projects
Please collaborate individually with each other on relevant material.
Furthermore, the wiki is in place to help with common issues/problems.

6. Resources / Shopping List
There is a limited number of BDMs; we need to check out exactly how many, however, need a full Licenced machine to do that.
Furthermore, the black boxes need to be checked and marked with working or not working. After which, we can take steps to getting them fixed.
Duncan is going to hopefully tap Freescale for some more free stuff, hopefully some more BDMs as well and other things students need.
Each student has to create an invidual shopping list of parts they need and email them to duncan, e.g. Zigbee chips, ethernet etc....

Other Information.
All emails regarding the projects should have the prefix [project]
As advised by Duncan, it is recommened to have some sort of contingency plan, please try and simulate something incase the actual hardware is not available or you start to have issues with it.

To dos:
Email Duncan your shopping list (remember the [project] prefix)
Email Duncan your preferred times for individual meetings and also whether you prefer them on a weekly or 2 weekly basis, please remember Duncan would prefer Mondays, Thursday & Fridays if possible and again, the [project] prefix.

Statement of Intent

The Controller Area Network (CAN), developed in the 1980s by Robert Bosch [1], is one of the most important networks in the field of real-time embedded systems; allowing for short real-time messages to be transmitted and received at speeds of up to 1 Mbit/sec.

The nature of CAN permits messages to be transmitted to multiple nodes simultaneously as CAN passes messages with a specific identifier, not messages with a specific destination. Each node chooses whether or not it will act upon a specific message by filtering the message's identifier. This can be done using either hardware or software. Although this technology was originally developed several decades ago, it is still widely used today in control applications for aircrafts, factories and automobiles.

This project aims at investigating, designing and implementing such a network and a software library + API to complement the previous SPUTNIC [Single-chip Processor Unit Together with Network Interface Chips] Projects which were based on the Motorola HCS12 single-chip processor and undertaken in 2002/03 and 2003/04. The creation of software libraries and an API will allow future SPUTNIC projects to utilise the capabilities of the Controller Area Network .

Furthermore, this project will also investigate the use of UDP/IP and/or TCP/IP as a gateway to the Controller Area Network (CAN) as well as the possible limitations introduced by using such protocols.

[1] CAN Specification Version 2.0, Parts A and B, by Robert Bosch GmbH

UDP/IP and/or TCP/IP (optional)

Been looking more into the original idea of using TCP/IP as a bridge, however, not sure if it's the best idea, so will also look at UDP/IP ;-)

Further Notes on Demos

Since part of the project is to help other students understand how to use the CAN interface more easily, as well as giving them some form of API to use, I feel that giving a collection of demos that show all the different uses of the CAN (and explained) would be a lot more useful than implementing one massive demo which could cloud the understanding of the CAN API. Obviously, there is room for larger demos, however, initially I will not focus on them.

Simple Demo

Since it popped into my head, might as well note it.
A very quick and simple demo could be done by having 2 or more chips linked with the CAN network along with using the onboard LEDs and buttons. A simple master node could be created that counts the number of times a button is pressed on ANY of the chips (i.e. the number of times messages are passed to it) that are connected to the CAN bus. Could be further expanded by telling the other chips that the master node had recieved the message, or could broadcast the new total count on the master node etc...

Bosch specification. V2.0
Standard CAN (V2.0A) 11 bit identifiers.
Extended CAN (V2.0B) 29 bit identifiers.

Bit Timing

http://www.freescale.com/files/
microcontrollers/doc/app_note/AN1798.pdf

33388 FAULT TOLERANT CAN INTERFACE

Yipee, as I already know the development board has CAN, however, the CAN physical layer was not obvious at all.

Using the schematics and following some copper, I can confirm that the development board has one physical interface. Another physical interfaces can be added, however, that will involve some soldering ;-)

CAN Physical layer details:
- Low-speed
- Fault tolerant CAN physical interface device
- Compatible with CAN 2.0 A and B protocals. (Very important)
- Very low sleep/standby current (15mA typical)
- Supports communication speeds up to 125 kB/s (Min: 10 kB/s)
- -40°C ≤ TA ≤ 125°C

Some Features:
- Automatic switching to single wire mode in the event of bus failures with
return to differential mode if bus failures disappear
- Supports unshielded twisted pair bus

PDFs
http://www.freescale.com/files/
analog/doc/data_sheet/MC33388.pdf

NOTE: High Speed 1.0Mbps CAN Interfaces are available too MC33742