CHAPTER 1 Introduction
1.2 Scope of work
The MOST devices in our lab, including the RadioTuner4MOST, Amplifier4MOST, DVDPlayer4MOST, IPod Gateway, the MOST PCI Board and the Optolyzer Interface Box, from SMSC, are connected in a ring topology as a multimedia network system. Via the MOST PCI Board, a PC is capable of communicating with the MOST network for management. Moreover, by means of the NetServices API, we can develop our control programs on the Windows platform to implement different multimedia applications of MOST.
Compared with Jun-Ying Huang’s work, in this thesis, more functions will be integrated in the control program.
The CAN devices in our lab, including USBCAN2 interface, SAAB 95 SID, and NI-CAN PCI board, which are connected through two twisted wires of low speed CAN-bus. Via USBCAN2, a PC is capable of controlling other CAN devices by sending CAN messages.
CHAPTER 2 MOST Specification
Figure 2.1 Structural overview of the documentation
Figure 2.1 [8] is the structural overview of the MOST specification documentation. It is a main specification within the MOST Framework. This specification is divided into three parts, Application Section, Network Section, Hardware Section. The arrows show the direction of references.
In this chapter, based on the documents “MOST Specification Framework” [9] and “MOST Specification” [10], we wish to give an introductory overview of the MOST System and its abilities. A MOST System often indicates a MOST network which is a group of MOST Devices linked together by some way.
A MOST System can be described by three definition areas which are MOST Interconnect, MOST System Services, and MOST Devices.
At first, we start with MOST Topology, the way of physical interconnection between nodes.
Then we get in the section of Data Transport, to see what is transported on the MOST network.
The third part of this chapter is Logical Device Model in which the logical components of a MOST device are described along with their functionalities. This section covers the contents from the application level to the lower physical layer. [11]
2.1 MOST structure
2.1.1 Point to Point Link
There are two basic system architectures supported by MOST technology. The first is a one-way, point-to-point link requiring a simple transmitter on one side and a receiver on the other. This is an extremely cost effective, one-way synchronous digital connection for applications such as connecting a digital audio source to active speakers, or a digital video source to a monitor. However, this basic configuration can easily be extended to more complex structures, such as branches or bi-directional links.
2.1.2 Ring Topology
Figure 2.2 Ring Topology
The second basic system architecture is a network with a ring topology. This network can have as few as two nodes, effectively a full duplex point-to-point connection, or as many as 64 nodes, as shown in Figure 2.2.
There are many advantages of a ring topology, which include the following:
‧ Minimum use of physical layer media, reducing system cost and weight.
‧ Low overall cost and constant cost per node since there is no overhead cost in the form of a hub, switch, or other shared network resource.
‧ Ease of expansion and no change in the basic architecture (such as the wiring infrastructure) is required.
‧ Availability of all source data (e.g. digitized audio) at each device.
One major disadvantage of a traditional ring topology is that the failure of one node can cause the entire network to fail. However, it can be largely overcome in a MOST network. Many failure mechanisms of a node such as power loss, or loss of lock will result in the transceiver going into bypass mode such that the rest of the network is unaffected.
2.2 MOST protocols
2.2.1 Structure of MOST Protocols
On the application level, the functions are addressed independently of the devices they belong to. Furthermore, the particular functions are unified into the function blocks according to their content. Hence, a function is addressed in a function block. The MOST protocols on the application layer have the following structure: [12]-[14]
DeviceID . FBlockID . InstID . FktID . OPType . Length (Data) DeviceID
The DeviceID with a length of 16 bits, stands for a physical device or a group of devices (Group Address), and is network specific. It represents the logical node address of either the sender or the receiver, depending on the case. A group address or a broadcast address (0x03C8) could be used for the target too. In case the sender does not know the receiver’s address, the DeviceID is set to 0xFFFF and will be corrected by the NetServices of the sender.
FBlockID
It specifies particular FBlock in the device. Every function block with a special FBlockID must contain certain specific functions other than the mandatory functions. Two kinds of proprietary FBlockIDs are defined: System specific and Supplier specific. System specific type can be used by any carmaker and is predefined, where the Supplier specific type is used by OEMs (Original Equipment Manufacturer) for development purpose.
InstID
It is an identifier of instance of function block. If the FBlockID is not unique within the system, this identifier specifies the function block. FBlockID and InstID create the functional address which has to be unique.
0x01
‧ - By default, every function block has instance ID 0x01. In case there are several FBlocks of the same kind within one MOST device, the default number (within the device) starts at 1.
‧ 0x00 - Don’t care. The device dispatches the message to one specific FBlock in the device.
0xFF
‧ - Broadcast (within a device). The message is dispatched to all instances of the matching FBlock.
FktID
The FktID stands for a function. This means a function unit (Object) within a device which provides operations (e.g. “Eject CD”) can be called via the network. The FktID is encoded in 12 bits on network level and is extended to 2 bytes on application level. The address range of FktIDs is subdivided into the following sections: Coordination, Mandatory, Extensions, Unique, System Specific and Supplier Specific.
OPType
The OPType indicates which operation must be applied to the property or method specified in FktID:
Length
Length is encoded in 16 bits which specifies the length of the data field in bytes. This parameter is not transferred through the control channel, but is computed in the receiving node.
Data is transferred in a continuous bi-phase encoded bit stream yielding more than a 24.8Mbps data rate, and the sample frequency in a MOST system can be chosen in a range between 30 kHz and 50 kHz.
2.2.2 Data Types
Different types of information can be transmitted over MOST and the frame structure separates the data into three different sections: Control data, asynchronous packet data and synchronous stream data.
Figure 2.3 Control data Control data transfer
‧ is for device specific transfers and system management. As shown in Figure 2.3, control data “Eject CD” is sent to the CD player to eject the CD. This kind of data is transported in parallel to the real-time and asynchronous data.
Figure 2.4 Packet data
‧Bulk data / burst data transfer in asynchronous packets with variable bandwidth requirements. As shown in Figure 2.4, it is often used for TCP/IP packets between computers.
Figure 2.5 Synchronous data
‧Real-time data transfer which requires a guaranteed bandwidth to maintain data quality.
As shown in Figure 2.5, audio stream from microphone to the speaker is such kind of data. Indeed, all nodes on the MOST network have access to it.
2.2.3 Frame Structure
A block consists of 16 frames with 512 bits (64 bytes) each, running at the system sample rate as frame rate (typical 44.1 kHz). Organization of data transfer in blocks of frames is required for network management and control data transport tasks. A control message has a fixed size of 32 bytes and is time multiplexed over 16 frames (1 block), each having 2 control data bytes.
Figure 2.6 MOST Frame
Figure 2.7 Structure of MOST Frame
One MOST25 frame consists of 512 bits (64 bytes). The first byte is used for administrative purposes. The next 60 bytes are used for stream and packet data transfer, where the Boundary is defined in 4 byte steps. All Stream data bytes are transmitted before any Packet data bytes
occur. The next two bytes of each frame are reserved for Control data and the last byte is another administrative byte. As shown in Figure 2.6 and Figure 2.7.
2.3 MOST NetServices
This section consists of two parts. Section 2.3.1 gives an overview of MOST System Services in which MOST NetServices are included. It can be regarded as an introduction to the MOST Specification from a different point of view. In Section 2.3.2, MOST NetServices Layer 1 API is introduced, since we will construct our multimedia control program with the API. We survey MOST System Services and Basic Layer System Services API in this chapter, and would not go deep into the specifications.
2.3.1 System Services Overview
The MOST System Services provide all basic functionality to operate a MOST System, and are consists of the following four parts:
‧ Application Socket
Figure 2.8 Application Socket
The Application Socket offers a wide variety of functions for building an application. Some of the functions are mandatory and some depend on the kind of application and are therefore optional. The Application Socket (Layer 2) together with the Basic Layer System Services
(Layer 1) are implemented in the NetServices software which contains all basic functionality a MOST Device needs.
‧ Basic Layer System Services
Figure 2.9 Basic Layer System Services
The Basic Layer of the System Services is also known as MOST NetServices Layer 1 which provides comfortable access on the Low Level System Services.
‧ Low Level System Services
Figure 2.10 Low Level System Services
Low Level System Services, except for the physical interface, are implemented in the MOST Transceiver [8].
‧ Stream Services
The Stream Services provide transport services for real-time source data. This allows handling source data in the respective parts of the application area.
2.3.2 NetServices Layer 1 API
Figure 2.11 Structure of MOST NetServices Layer 1
MOST NetServices Layer 1 API is the interface between the MOST Low Level System Services and an application. All functions are combined in a library that they can be included if required. MOST NetServices API is implemented in ANSI C and can be adapted by the file
“adjust.h” which contains all the parameters needed to set up NetServices according to the application.
z MOST NetServices Kernel (MNS)
‧ Initialization of all services
‧ NetServices trigger functions
z MOST Supervisory and Startup Functions (MSV)
‧ Transceiver Initialization
‧ Master/Slave Selection
‧ Compiler Selectable Source Port Configuration
‧ Network Start Up and Shut Down
‧ Power Management
‧ Failure Diagnosis and Reporting
‧ Self Testing Services
z Control Message Service (CMS)
‧ Initialization
‧ Control Message Receive Service
‧ Control Message Transmit Service
‧ Message Buffering and Handling
‧ Error Handling and Notification
z Application Message Service (AMS)
‧ Initialization
‧ Application Message Send Handler
‧ Application Message Receive Handler
‧ Message Buffering and Handling
‧ Error Handling and Notification
z Remote Control Service (RCS)
‧ Initialization
‧ Remote Write Service
‧ Remote Read Service
‧ Remote Error Handling and Notification
z Synchronous Channel Allocation Service (SCS)
‧ Channel Allocation
‧ Allocation and Routing
‧ De-Allocation
‧ De-Allocation and Routing Disconnect
‧ Source Connect
‧ Source Disconnect
‧ Sink Connect
‧ Sink Disconnect
‧ Detect Channel by Label
z Transparent Channel Allocation Service (TCS)
‧ Channel Allocation
‧ Allocation and Routing
‧ De-Allocation
‧ De-Allocation and Routing Disconnect
‧ Source Connect
‧ Source Disconnect
‧ Sink Connect
‧ Sink Disconnect
z Asynchronous Data Transmission Service (ADS)
‧ Initialize – SetDataAddress
‧ Buffered Transfer of Data Packages
‧ Buffered Receive of Data Packages
‧ Data Transfer Error Handling
z MOST Transceiver Control Service (MCS)
‧ Addressing
‧ Accessing important Transceiver’s Register
‧ Selecting RMCK Frequency
‧ Master Functions
2.4 MOST Multimedia Applications
Figure 2.12 Structure of MOST Network
2.4.1 Application 1: Listen to the Radio
Source: RadioTuner4MOST Sink: Amplifier4MOST
‧ Listen to the radio on the MOST network.
Source:
RadioTuner4MOST
Sink:
Amplifier4MOST
Listen to the radio on the MOST network
Figure 2.13 Flowchart of listening to the Radio
2.4.2 Application 2: Watch DVD movies
Source: DVDPlayer4MOST Sink: Amplifier4MOST
‧ Watch VCD/DVD movies.
(Video is output from the DVD player while audio is output from the amplifier.)
Source:
DVDPlayer4MOST
Sink:
Amplifier4MOST
Watch VCD/DVD movies (Video is output on the screen)
Figure 2.14 Flowchart of watching DVD movies
2.4.3 Application 3: Listen to IPod music
Source: IPod Gateway Sink: Amplifier4MOST
‧ Listen to IPod on the MOST network.
Source:
IPod Gateway
Sink:
Amplifier4MOST
Listen to IPod on the MOST network
Figure 2.15 Flowchart of listening to IPod music
CHAPTER 3 CAN specification
CAN (Controller Area Network) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle. It was designed specifically for automotive applications but is now also used in other areas.
3.1 CAN structure
Figure 3.1 Layer architecture of CAN
The CAN architecture represents two layers: [15]
z Data link layer
LLC (Logic Link Control)
MAC (Medium Access Control) z Physical layer
PLS (Physical Signalling)
PMA (Physical Medium Attachment)
MDI (Medium Dependent Interface)
3.1.1 Bus topology
Figure 3.2 Bus topology
All CAN devices connect to the same transmission line by using two twisted wires. As shown in Figure 3.2.
3.2 CAN protocols
3.2.1 Structure of CAN protocols
Figure 3.3 Principles of CAN data exchange
Each node requires: [5]
a host-processor
The host-processor decides what received messages mean, and which messages it wants to transmit itself
Sensors, actuators and control devices can be connected to the host-processor (if desired).
a CAN Controller (hardware with a synchronous clock)
Receiving: the CAN Controller stores received bits (one by one) from the bus until an entire message is available, that can then be fetched by the host processor (usually after the CAN Controller has triggered an interrupt)
Sending: the host-processor stores its transmit-messages into a CAN Controller, which transmits the bits serially onto the bus
a Transceiver (possibly integrated into the CAN Controller)
Receiving: it adapts signal levels from the bus, to levels that the CAN Controller expects and has protective circuitry that protect the CAN Controller
Sending: it converts the transmit-bit signal received from the CAN Controller into a signal that is sent onto the bus
Bit rates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasing the bit rate allows longer network distances (e.g. 125 kbit/s at 500 m).
3.2.2 CAN Technology
CAN is a multi-master broadcast serial bus standard for connecting electronic control units (ECUs).
Each node is able to send and receive messages, but not simultaneously: a message
up to eight message bytes) is transmitted serially onto the bus, one bit after another — this signal-pattern codes the message (in NRZ) and is sensed by all nodes.
The devices that are connected by a CAN network are typically sensors, actuators and control devices. A CAN message never reaches these devices directly, but instead a host-processor and a CAN Controller is needed between these devices and the bus.
If the bus is free, any node may begin to transmit. If two or more nodes begin sending messages at the same time, the message with the more dominant ID (which has more dominant bits i.e. bit 0) will overwrite other nodes less dominant IDs, so that eventually (after this arbitration on the ID) only the dominant message remains and is received by all nodes.
3.2.3 Data Types
A CAN network can be configured to work with two different message (or "frame") formats:
the standard or base frame format (or CAN 2.0 A), and the extended frame format (or CAN 2.0 B). The only difference between the two formats is that the “CAN base frame” supports a length of 11 bits for the identifier, and the “CAN extended frame” supports a length of 29 bits for the identifier, made up of the 11-bit identifier (“base identifier”) and an 18-bit extension (“identifier extension”). The distinction between CAN base frame format and CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in case of an 11-bit frame, and transmitted as recessive in case of a 29-bit frame. CAN controllers that support extended frame format messages are also able to send and receive messages in CAN base frame format. All frames begin with a start-of-frame (SOF) bit that denotes the start of the frame transmission.
CAN has four frame types:
Figure 3.4 Types of CAN frame
Data frame: a frame containing node data for transmission
Remote frame: a frame requesting the transmission of a specific identifier Error frame: a frame transmitted by any node detecting an error
Overload frame: a frame to inject a delay between data and/or remote frames [5]
z Data frame
The data frame is the only frame for actual data transmission. There are two message formats:
Base frame format: with 11 identifier bits Extended frame format: with 29 identifier bits
The CAN standard requires the implementation must accept the base frame format and may accept the extended frame format, but must tolerate the extended frame format.
Figure 3.5 CAN data frame
Base frame format [5]
The frame format is as follows:
Field name
Length (bits)
Purpose
Start-of-frame 1 Denotes the start of frame transmission Identifier 11 A (unique) identifier for the data Remote transmission
request (RTR)
1 Dominant (0) (see Remote Frame below)
Identifier extension bit (IDE)
1 Must be dominant (0)Optional
Reserved bit (r0) 1
Reserved bit (it must be set to dominant (0), but accepted as either dominant or recessive)
Data length code (DLC)* 4 Number of bytes of data (0-8 bytes)
Data field 0-8 bytes Data to be transmitted (length dictated by DLC field)
CRC 15 Cyclic Redundancy Check CRC delimiter 1 Must be recessive (1)
ACK slot 1
Transmitter sends recessive (1) and any receiver can assert a dominant (0)
ACK delimiter 1 Must be recessive (1) End-of-frame (EOF) 7 Must be recessive (1)
One restriction placed on the identifier is that the first seven bits cannot be all recessive bits.
(I.e., the 16 identifiers 1111111xxxx are invalid.)
Extended frame format The frame format is as follows:
Field name
Length (bits)
Purpose
Start-of-frame 1 Denotes the start of frame transmission
Identifier A 11 First part of the (unique) identifier for the data Substitute remote request
(SRR)
1 Must be recessive (1)Optional
Identifier extension bit (IDE)
1 Must be recessive (1)Optional
Identifier B 18 Second part of the (unique) identifier for the data Remote transmission
request (RTR)
1 Must be dominant (0)
Reserved bits (r0, r1) 2 Reserved bits (it must be set dominant (0), but
accepted as either dominant or recessive) Data length code (DLC)* 4 Number of bytes of data (0-8 bytes)
Data field 0-8 bytes Data to be transmitted (length dictated by DLC field)
CRC 15 Cyclic redundancy check
CRC delimiter 1 Must be recessive (1)
ACK slot 1
Transmitter sends recessive (1) and any receiver can assert a dominant (0)
ACK delimiter 1 Must be recessive (1)
End-of-frame (EOF) 7 Must be recessive (1)
The two identifier fields (A & B) combined form a 29-bit identifier.
* It is physically possible for a value between 9-15 to be transmitted in the 4-bit DLC, although the data is still limited to 8 bytes. Certain controllers allow the transmission and/or reception of a DLC greater than 8, but the actual data length is always limited to 8 bytes.
z Remote frame
Generally data transmission is performed on an autonomous basis with the data source node (e.g. a sensor) sending out a Data Frame. It is also possible, however, for a destination node to request the data from the source by sending a Remote Frame.
There are 2 differences between a Data Frame and a Remote Frame. Firstly the RTR-bit is transmitted as a dominant bit in the Data Frame and secondly in the Remote Frame there is no Data Field.
Figure 3.6 CAN remote frame
i.e.
RTR = 0 ; DOMINANT in data frame RTR = 1 ; RECESSIVE in remote frame
In the very unlikely event of a Data Frame and a Remote Frame with the same identifier being transmitted at the same time, the Data Frame wins arbitration due to the dominant RTR bit following the identifier. In this way, the node that transmitted the Remote Frame receives the desired data immediately.
z Error frame
Error frame consists of two different fields
The first field is given by the superposition of ERROR FLAGS contributed from different stations. The following second field is the ERROR DELIMITER.
There are two types of error flags
Active Error Flag
Transmitted by a node detecting an error on the network that is in error state "error active".
Passive Error Flag
Transmitted by a node detecting an active error frame on the network that is in error state
"error passive".
z Overload frame
The overload frame contains the two bit fields Overload Flag and Overload Delimiter. There are two kinds of overload conditions that can lead to the transmission of an overload flag:
1. The internal conditions of a receiver, which requires a delay of the next data frame or remote frame.
2. Detection of a dominant bit during intermission.
The start of an overload frame due to case 1 is only allowed to be started at the first bit time of an expected intermission, whereas overload frames due to case 2 start one bit after detecting
The start of an overload frame due to case 1 is only allowed to be started at the first bit time of an expected intermission, whereas overload frames due to case 2 start one bit after detecting