Lade Inhalt...

Implementation of a CAN Bus based Measurement System on an FPGA Development Kit

©2010 Masterarbeit 91 Seiten

Zusammenfassung

Inhaltsangabe:Abstract:
The Controller Area Network (CAN) is a serial field bus protocol which was originally used in road vehicles. Most people still use Microcontrollers (MCU) to control the CAN bus. The development of Field-programmable Gate Array (FPGA) is very advanced, and compared to the MCU the FPGA has many advantages. For this reason, this thesis uses an Altera FPGA development kit to design a CAN bus based measurement system.
During the work, four Direct Digital Synthesizers (DDS) were simulated for four wave channels in the FPGA. All signals of the channels were transmitted from the FPGA to a CAN bus. Between the CAN bus and FPGA an Atmel CAN MCU, which contains both serial and CAN ports, was used as the third party. Whereby the data output from the FPGA were first transmitted to the serial port of the CAN MCU and then shifted to the CAN port of the CAN MCU. The CAN bus device (NI CAN USB-8473) which was used in this thesis, has a CAN port to connect to the CAN port of the CAN MCU, and a USB 2.0 port to connect to a PC. Finally, the data of the CAN bus was monitored on the PC with the LabVIEW platform. With this platform the data could also be transmitted to the CAN bus and then to the FPGA to change the tuning word of DDS. In order to achieve the speed limit of the complete measurement system, the communication rates of FPGA, CAN bus and CAN MCU were programmed to be the maximum. Inhaltsverzeichnis:Table of Contents:
1Introduction4
1.1Background4
1.2Objective4
1.3Outline6
2CAN Introduction7
2.1Background7
2.2Architecture Layers8
2.2.1Physical Layer8
2.2.2Data Link Layer10
2.2.3Higher Layer10
2.3Frame Structure11
2.3.1Data Frame11
2.3.2Remote Frame14
2.3.3Error Frame15
2.3.4Overload Frame16
2.3.5Interframe Space16
2.4Frame Coding17
2.5Error Detecting and Handling18
2.6Fault Confinement19
3CAN and MCU Serial Port Effective Data Study22
3.1CAN Effective Data Study22
3.2MCU Serial Port Study25
3.2.1General 8051 MCU25
3.2.2Using Timer 227
3.2.3X2 Mode28
3.3CAN vs. MCU Serial Port29
4Experiment Components and Setup32
4.1Stratix III FPGA Development Kit32
4.2CAN MCU AT89C51CC0335
4.35-3.3 V Voltage Level Transistor38
4.4NI CAN USB-847340
4.5PC with NI CAN Driver42
4.6Setup42
5Software Development43
5.1FPGA with Quartus II43
5.1.1DDS Design43
5.1.2PLL Application45
5.1.3UART Reception49
5.1.4UART Transmission51
5.2MCU with Keil C5153
5.2.1Serial Port Programming53
5.2.2CAN […]

Leseprobe

Inhaltsverzeichnis


Contents

1 Introduction
1.1 Background
1.2 Objective
1.3 Outline

2 CAN Introduction
2.1 Background
2.2 Architecture Layers
2.2.1 Physical Layer
2.2.2 Data Link Layer
2.2.3 Higher Layer
2.3 Frame Structure
2.3.1 Data Frame
2.3.2 Remote Frame
2.3.3 Error Frame
2.3.4 Overload Frame
2.3.5 Interframe Space
2.4 Frame Coding
2.5 Error Detecting and Handling
2.6 Fault Confinement

3 CAN and MCU Serial Port Effective Data Study
3.1 CAN Effective Data Study
3.2 MCU Serial Port Study
3.2.1 General 8051 MCU
3.2.2 Using Timer 2
3.2.3 X2 Mode
3.3 CAN vs. MCU Serial Port

4 Experiment Components and Setup
4.1 Stratix III FPGA Development Kit
4.2 CAN MCU AT89C51CC03
4.3 5-3.3 V Voltage Level Transistor
4.4 NI CAN USB-8473
4.5 PC with NI CAN Driver
4.6 Setup

5 Software Development
5.1 FPGA with Quartus II
5.1.1 DDS Design
5.1.2 PLL Application
5.1.3 UART Reception
5.1.4 UART Transmission
5.2 MCU with Keil C51
5.2.1 Serial Port Programming
5.2.2 CAN Programming
5.2.3 Interrupt Management
5.2.4 In-System Programming with FLIP
5.3 NI CAN BUS with LabVIEW

6 Experiments and Results
6.1 Problem Diagnosis
6.2 Final Results

7 Conclusion

References

Appendix A: Figures

Appendix B: Tables

Appendix C: Symbols

Appendix D: Abbreviations and Acronyms

1 Introduction

1.1 Background

Since the 1980s the application of Controller Area Network (CAN) in the automobile has solved many problems caused by the huge number of wires between different devices. For more than two decades, automotive electronic engineers have been using Microcontrollers (MCU) to control the CAN bus. As the development of electronic devices progresses, the need for high speed, high safety and low cost has grown rapidly and the limitations of MCUs have become more apparent. At this time, the development of FPGA continues to become more advanced. Compared to the properties of MCU, the FPGA can provide higher standards in the areas of performance, safety, flexibility and reliability. The FPGA also requires shorter development time and is more cost-effective. Therefore, the FPGA is expected to play a significant role in the future of the automobile industry.

1.2 Objective

The main objective of this thesis is to design a CAN bus based measurement system on an FPGA kit working at the fastest possible speed achievable by this system. Initially, the FPGA Altera Stratix III was used to simulate four Direct Digital Synthesizers (DDS) for four wave channels. Each DDS contained a 26-bit phase accumulator, of which the highest 12 bits were used for a wave lookup table. The four different waves (sine, cosine, right triangle and rectangle) were output through their corresponding channels by way of serial bit stream to a CAN bus. Owing to the fact that the FPGA itself does not provide any communication interface and the CAN protocol is protected by patents of Robert Bosch GmbH, it is not permitted to program the FPGA with CAN without a license. Therefore, it was necessary to utilize an open-source protocol to get the data from the FPGA and apply them to the CAN bus. In this thesis an Atmel CAN MCU AT89C51CC03, which contains both serial and CAN ports, was used to communicate with the FPGA.

The CAN MCU communicates with the FPGA by either serial or parallel connections. Although the serial connection usually operates at a lower rate than the parallel connection, it needs fewer ports and is more robust. While the CAN bus does not provide an extremely high rate, the serial connection was chosen for the FPGA and MCU for the purpose of this work.

The CAN bus used in this thesis was the NI CAN USB-8473 made by National Instruments. It has two ports, a CAN port to connect to the CAN port of the MCU, and a USB 2.0 port to connect to a PC. Additionally, it offers powerful development software (LabVIEW) with which the data of the CAN bus can be monitored. Data can also be transmitted to the CAN bus and then to the FPGA to reset the tuning word of DDS. In order to estimate the speed limit achievable by the CAN bus based measurement system during these experiments, the communication rates of FPGA, CAN bus and MCU were programmed to operate at maximum speed.

1.3 Outline

The workflow chart of the entire system is shown in Fig. 1.1.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 1.1 System workflow chart

- Chapter 2 of this thesis introduces the history of the CAN protocol, and then outlines its fundamentals including application field, architecture layers, different frame structures, frame coding, error handling and fault confinement. This information was extracted from CAN Specification 2.0 and ISO 11898 and assists readers to understand the concept of CAN.
- Chapter 3 studies the effective data rate and ratio of CAN and MCU serial communication respectively, concluding with a comparison of each model. This chapter is the theory research key of this thesis.
- Chapter 4 describes all of the devices used during the work and setup. Fig. 1.1 illustrates all the major devices, Altera FPGA, 5-3.3 V level translator, Atmel CAN MCU, NI CAN USB and PC with LabVIEW environment.
- Chapter 5 contains the programming concepts of this thesis.
- Chapter 6 describes the testing of the complete system. It analyses the difficulties encountered during the experiment and illustrates how they were solved.
- Chapter 7 presents the final conclusion of this thesis.

2 CAN Introduction

In order to communicate via CAN, it is necessary to know about the fundamentals of the protocol. This chapter will introduce the history of CAN and present the main content of the CAN protocol based on the CAN Specification 2.0 [1] and ISO 11898 [2].

2.1 Background

CAN is a serial field bus protocol which was originally used in road vehicles. Its development history can be traced back to the early 1980s. At that time, all automotive manufacturers were using point-to-point wiring systems to connect electronic devices in vehicles. As the application of electronics in vehicles rapidly increased, the wiring between different components became heavy, long, expensive and disorganized. This also made repairs very difficult. In order to solve these problems and also to enhance the safety and robust nature of automobiles, Bosch developed the CAN in 1983. In February of 1986 at the SAE (Society of Automotive Engineers) Congress, Bosch introduced CAN. This is considered the “birth of CAN”. Shortly after, in mid 1987, Intel and Philips released the first CAN controller chips, the ‘82526’ and the ‘82C200’ [3]. Since then more and more companies have begun to develop and produce CAN. Today there are more than 50 CAN protocol controller chips available from more than 15 manufacturers [4]. In order to standardize CAN, in 1991 Bosch published the CAN Specification 2.0. In 1993 the ISO (International Organization for Standardization) published complimentary standards for CAN protocol, ISO 11898, and over the next few years issued the revised versions ISO 11898-1, ISO 11898-2 /-3/-4/-5.

Today, due to its high performance, reliability and low cost, CAN is used not only in the automobile industry but also in many other fields including building automation (e.g. heating control, air conditioning, security, access and light control), domestic and food distribution (e.g. washing machines, dishwashers and vending machines), agriculture (e.g. harvesters, seeding, sowing machines and tractor control), medical apparatus, avionics and so on.

2.2 Architecture Layers

In the Open Systems Interconnection (OSI) reference model, the CAN Specification 2.0 and ISO 11898 jointly define the lowest two layers for the CAN: Physical Layer (7th) and Data Link Layer (6th) [1, 2].

2.2.1 Physical Layer

In the physical layer the CAN Specifications 2.0 defines how signals in the CAN bus are actually transmitted. It includes bit timing, bit encoding, and synchronization. The ISO 11898 supplements the definition for the PMA (Physical Medium Attachment) and MDI (Medium Dependent Interface).

According to the ISO 11898 the CAN network medium uses a twisted wire pair, one is referred to as “CAN High” (CAN_H) which has a voltage value of 2.5 V to 4 V, and the other is “CAN LOW” (CAN_L) which has a voltage value of 1 V to 2.5 V. The differential voltages on the CAN_H and CAN_L represent two signal states: recessive state (logic 1) and dominant state (logic 0). If the differential voltage is less than 0.5 V for receiver input or 1.5 V for transmitter output, then it is recessive, otherwise, it is dominant. Fig. 2.1 demonstrates a CAN bit stream: 1 (recessive), 0 (dominant), 1 (recessive).

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2.1 The CAN bit stream “101”

The CAN network contains at least two nodes. Since the twisted pair is the transmission line, in order to minimize signal reflection in accordance with ISO 11898, a 120 Ω resistor is required at each end of the bus. Fig. 2.2 demonstrates a CAN bus layout.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2.2 CAN bus layout

On the basis of transmission rate there are two kinds of CAN:

1) High-speed CAN: Standardized by ISO 11898-2, it is the most common protocol used in automobiles. It has maximum bit rate of 1 Mbit/s with a restricted bus length of 40 m. A longer bus length can be applied by slowing down its bit rate. For example, 130 m long bus can work at a maximum rate of 500 kbit/s and 270 m long bus can work at a maximum rate of 250 kbit/s. In automobiles the High-speed CAN is commonly used to manage control devices, such as anti-lock brake systems, engine control modules, emissions systems, etc.

2) Low-speed/Fault-tolerant CAN: Standardized by ISO 11898-3 (formerly ISO 11519-2), it has a maximum bit rate of 125 kbit/s. It differs from High-speed CAN not only in bit rate, but also because of its special fault-tolerant capability. If one of the wires is cut or short-circuited, the CAN bus can still operate. This is because it operates on relative changes in voltage. In the automobile it is often used to control comfort devices such as seat adjustment, mirror adjustment, door locking and so on.

2.2.2 Data Link Layer

The Data Link Layer (DLL) is just one layer above the physical layer in the OSI model. Its function is to assemble the signals received from the physical layer into a meaningful message to provide a procedure for data transmission control. The DLL is subdivided into LLC (Logic Link Control) and MAC (Medium Access Control).

- LLC: The LLC provides three functions, frame acceptance filtering, overload notification and recovery management. Frame acceptance filtering helps receivers to decide whether the frames are relevant according their identifier. The overload notification function sends an overload frame to make a delay if the receiver is not ready for a new frame. The recovery management function provides the means for automatic retransmission of frames that have been aborted in their last transmission.
- MAC: The MAC is the kernel of entire CAN protocol. It presents messages received from the LLC sublayer and accepts messages to be transmitted to the LLC sublayer. The MAC sublayer is responsible for data encapsulation/decapsulation, frame coding (stuffing, destuffing), medium access management, error detection, error signalling, acknowledgment, serialization/deserialization.

2.2.3 Higher Layer

The CAN Specification 2.0 and ISO 11898 jointly specify only the physical and data link layers in the OSI model. They don’t include any tasks from the application layer, such as Start-up behavior, Identifier (ID) definition for different nodes, flow control, transportation of data exceeding data frame (eight bytes), data frame content definition, status reporting and so on. Thus, in order to improve the CAN application there are several associations, organizations and companies specifying higher-layer protocols. The most common protocols are CANopen developed by CAN in Automation (CiA), DeviceNet created by Allen Bradley, CAN Kingdom introduced by KVASER, J939 developed by SAE, SDS, CANaerospace and OSEK/VDX.

2.3 Frame Structure

In a CAN system, message transmission and reception between nodes are performed and controlled by four different frame types: data frame, remote frame, error frame and overload frame. Besides, the data frames and remote frames are separated from preceding frames, regardless of type, by a bit field called interframe space.

2.3.1 Data Frame

The data frame is the fundamental frame carrying data from a transmitter to all receivers. A data frame is composed of seven different bit fields. Fig. 2.3 illustrates its structure.

Fig. 2.3 Structure of a data frame

(1). SOF (Start of Frame)

It is a single dominant bit (logic 1) and marks the beginning of all data and remote frames.

(2). Arbitration Field

Arbitration field indicates the priority of data. It is composed of an ID field and a dominant RTR (Remote Transmission Request) bit.

The ID field serves two purposes: enabling receivers to filter frames and assigning a priority to a frame. Thus, the ID in different source frames is unique. The principle of arbitration is called non-destructive CSMA/CR (Carrier Sense Multiple Access with Collision Resolution). In the case of collision, where two or more nodes start sending frames at the same time, contention for the bus is arbitrated by comparing the ID of each node bit by bit from MSB (Most Significant Bit) to LSB (Least Significant Bit). The bus acts like an AND gate: if any node sends a dominant bit (logic 0) on the bus, the bus will receive a dominant bit and every node can read it. When the node detects that the actual bit on the bus is not the same to its transmitting one, it will abort transmission and wait for the next idle period before reattempting transmission. Thus, the node which has lowest ID has the highest priority and wins the arbitration for transmission.

Fig. 2.4 illustrates an arbitration example for standard format.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2.4 CAN arbitration example for standard format, Node D won the arbitration [5]

In Fig. 2.4 the Nodes A, B, C and D contend for the bus to transmit data. Node D has the smallest ID, therefore it gets the higher priority and wins the arbitration. The CAN bus can read only the data from Node D.

Depending on the IDE (Identifier Extension Flag) bit, the ID field has two formats: standard format (also called base format) and extended format.

1) Standard format: if the IDE is dominant, the arbitration field consists of 11-bit standard ID (ID-28 to ID-18).

2) Extended format: if the IDE is recessive, the arbitration field consists of 11-bit standard ID (ID-28 to ID-18), a recessive SRR (Substitute Remote Request) bit, a recessive IDE bit and 18-bit ID extension (ID-17 to ID-0).

For both formats the first seven bits (ID-28 to ID-22) must not all be recessive. If a standard format frame contends the bus with an extended format frame, the standard format frame always wins.

(3). Control Field

This field indicates the number of data bytes in a message to be transmitted. It has six bits and also standard and extended formats. For the standard format its bit ordering is a dominant IDE bit, a single reserved bit r0 and four DLC (Data Length Code) bits. For the extended format the bit ordering is two reserved bits r1 and r0, and four DLC bits. The DLC bits indicate the total number of bytes contained in a data frame. Table 2.1 shows how the DLC represents the number of bytes. The maximum number of bytes in a data frame is eight.

Abbildung in dieser Leseprobe nicht enthalten

Table 2.1 Coding of the numbers of data bytes by the DLC

(4). Data Field

The data field contains the data to be transmitted within a data frame. It carriers from 0 to 8 bytes (each byte consists of 8 bits) starting with MSB.

(5). CRC (Cyclic Redundancy Check) Field

This field is used to check the frame for a transmission error. It consists of a 15-bit CRC sequence and a single recessive CRC delimiter bit.

The value of 15-bit CRC sequence is the remainder of a polynomial division. The polynomial dividend is composed of coefficients given by the non-stuffed bit stream (For more information regarding bit stuffing code see Chapter 2.4 Frame Coding) consisting of SOF, arbitration field, control field and data field, and for the 15 lowest coefficients, 0. The polynomial divisor is X15 + X14 + X10 + X8 + X7 + X4 + X3 + 1.

(6). ACK (Acknowledgement) Field

The ACK field has two bits, one is an ACK slot bit and another is a recessive ACK delimiter bit. The transmitter sends only recessive ACK slot bit. A receiver which has received a correct message sends a dominant ACK slot bit to replace the recessive one. When the transmitter detects a dominant ACK slot bit, it knows that at least one node has got its message correctly.

(7). EOF (End of frame)

This field indicates the end of a frame and consists of seven recessive bits.

2.3.2 Remote Frame

The remote frame is used by the receiver node to request transmission of a message from the transmitter node. Similarly to the data frame it consists of six fields: SOF, arbitration field, control field, CRC field, ACK field and EOF, and also has standard and extended formats. It differs from a data frame in two ways, one is that it does not have a data field and the other is that its RTR bit in the arbitration field is recessive (for data frame it is dominant).

2.3.3 Error Frame

An error frame is transmitted by any node in case of a bus error detected. It consists of two fields: error flag and error delimiter.

- Error Flag: An error flag is a superposition contributed by different nodes and has two different flag forms: active error flag and passive error flag.

1) The active error flag consists of six consecutive dominant bits. An error active node detecting an error condition signals this by transmission of an active error flag. As a consequence, all other nodes detect an error condition and on their part start transmission of an error flag. So the sequence of dominant bits, which actually can be monitored on the bus, results from a superposition of different error flags transmitted by individual nodes. The total length of this sequence varies between a minimum of six and a maximum of twelve bits.

2) The passive error flag consists of six consecutive recessive bits. An error passive node detecting an error condition tries to signal this by transmission of a passive error flag. The error passive node waits for six consecutive bits of equal polarity, beginning at the start of the passive error flag. The passive error flag is complete when these six equal bits have been detected.

- Error Delimiter: An error delimiter consists of eight recessive bits. After sending an error flag, each node sends recessive bits and monitors the bus until it detects a recessive bit. Afterwards, it will send seven more recessive bits. Therefore, the error delimiter is eight bits in total length.

2.3.4 Overload Frame

The overload frame is used by the receiver to notify that it is not ready to receive a frame. There are three conditions which lead to the transmission of overload frame.

1) The internal conditions of a receiver which require a delay of the next data frame or remote frame.
2) Detection of a dominant bit at the first and second bit of interframe space.
3) When a CAN node samples a dominant bit at the eighth bit (the last bit) of an error delimiter or overload delimiter, it will start transmitting an overload frame (not an error frame).

Similar to the error frame, the overload frame also contains two fields: an overload flag comprised of six up to twelve dominant bits and an overload delimiter comprised of eight recessive bits.

2.3.5 Interframe Space

This interframe space is used to separate data frames and remote frames from preceding frames. There are no interframe spaces inserted in front of overload frames and error frames. The interframe space contains the bit fields: Intermission, Bus Idle and Suspend Transmission in a special case.

1) Intermission consists of three recessive bits. During Intermission no node is allowed to start transmission of a data frame or remote frame, except when signalling an overload condition.
2) Bus Idle consists of recessive bits at any length including zero. The bus recognizes this condition and any node can access the bus for transmission.
3) Suspend Transmission: this happens only after an error passive node has just transmitted a message. It follows the Intermission and carries eight recessive bits.

2.4 Frame Coding

The bit stream in a message is coded according to the NRZ (Non-Return-to-Zero) which is the most efficient binary code for bandwidth and also used for example, in RS232. Thus during the total bit time the generated bit level is either dominant or recessive.

One possible inadequacy of NRZ code is that it does not ensure enough signal edges for synchronization if many consecutive bits with the same polarity (all are dominant or recessive) are transmitted. To maintain synchronization the CAN protocol uses bit-stuffing code. Whenever a transmitter detects five consecutive same logic bits including stuff bits in the domain of SOF to CRC sequence in data or remote frames, it will insert a complementary bit in the actual transmitted bit stream. When the receiver receives a data or remote frame, it will automatically delete the stuff bits (called destuffing). Fig. 2.5 illustrates an example of bit-stuffing and bit-destuffing code. After destuffing the bit stream, the receiver receives the original bit stream.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2.5 Example of bit stuffing and destuffing code

2.5 Error Detecting and Handling

In CAN communication the MAC sublayer provides corresponding error detection mechanisms to the following five different errors.

1) Bit error: a node that is sending a bit on the bus simultaneously monitors the bus . A bit error is detected when the bit value that is monitored differs from the bit value sent.
2) Stuff error: a stuff error is detected at the time the sixth consecutive equal bit occurs in a frame field that is coded by bit stuffing.
3) CRC error: the CRC sequence consists of the result of the CRC calculation of the transmitter (see Chapter 2.3.1-(5) CRC Field). The receiver then calculates the CRC sequence of the received de-stuffed bit stream. If both CRC sequences don’t match, then a CRC error is assumed.
4) Form error: a form error is detected when a fixed-form bit field contains one or more illegal bits.
5) ACK error: an ACK error is detected by a transmitter whenever it does not find that the bit in the ACK slot is dominant.

If any node detects any error it immediately notifies all other nodes of that error by sending an error flag (as described in Chapter 2.3.3 Error Frame). The node which is transmitting the message will abort its transmission and after a certain time (recovery time) retransmit that message automatically if there is no other higher priority message. The recovery time, from detecting an error until the start of next transmission, is 17 up to 31 bit times, if there are no further errors.

2.6 Fault Confinement

There are two classes of errors occurring in CAN: a temporary error where data on the bus temporarily becomes erratic due to noise, voltage spikes or other reasons, and a continual error where data on the bus becomes continually erratic due to a node’s internal failure, driver failure or disconnection. The CAN bus has a function called fault confinement to discriminate between these errors. The fault confinement helps to lower the communication priority of an error-prone node in order to prevent it from hindering communication of other normal nodes, and if a continual data error on the bus is occurring, to separate the node that is the cause of the error from the bus.

With respect to fault confinement, a node may be in one of the three states:

1) Error Active State: this is a state in which the node can participate in communication on the bus normally. If the node in an error active state detects an error, it transmits an active error flag.

2) Error Passive State: this is a state in which the node tends to cause an error. Although the node in an error passive state can participate in communication on the bus, it cannot notify other nodes of an error positively during a receive operation in order not to hinder their communication. Even when the node in an error passive state has detected an error, if no errors are detected by other nodes in an error active state, it is assumed that no errors have occurred anywhere on the bus. When the node in an error passive state has detected an error, it transmits a passive error flag. Furthermore, the node in an error passive state cannot start transmission immediately after it has finished sending. A suspend transmission period (comprised of 8 recessive bits) is inserted in an interframe space before the next transmission can start.

3) Bus Off State: The bus off state is a state in which the node cannot participate in communication on the bus. When in this state, the unit is disabled from all transmit/receive operations.

Each of these states are managed by the transmit error counter (TEC) and receive error counter (REC), and the relevant error state is identified by a combination of these counter values. The relationship between error states and counter values is shown in Fig. 2.6.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2.6 Error States of a Node [5]

From the above figure it is clear that if the TEC or REC of a node exceeds 127 then the node goes into the error passive state. The error passive node goes back to error active state when both TEC and REC are less than 128. If its TEC becomes larger than 255, then it goes into the bus off state. In the bus off state it returns to its initial error active state only after a hardware or software reset or after having successfully monitored 128 occurrences of 11 consecutive recessive bits on the bus.

The TEC and REC change according to the following rules: [2]

1) When a receiver detects an error, the REC will be increased by 1, except when the detected error is a bit error during the sending of an active error flag or an overload flag.
2) When a receiver detects a dominant bit as the first bit after sending an error flag, the REC is increased by 8.
3) When a transmitter sends an error flag, the TEC is increased by 8. There are two exceptions in which the TEC remains unchanged. One is if the transmitter is error passive and detects an ACK error because of not detecting a dominant ACK and does not detect a dominant bit while sending its passive error flag. The other is if the transmitter sends an error flag because a stuff error occurred during arbitration, and should have been recessive, and has been sent as recessive but monitored as dominant.
4) If a transmitter detects a bit error while sending an active error flag or an overload flag, the TEC is increased by 8.
5) If a receiver detects a bit error while sending an active error flag or an overload flag, the REC is increased by 8.
6) Any node tolerates up to 7 consecutive dominant bits after sending an active error flag, passive error flag or overload flag. After detecting the 14th consecutive dominant bit (in case of an active error flag or an overload flag) or after detecting the 8th consecutive dominant bit following a passive error flag, and after each sequence of additional eight consecutive dominant bits, every transmitter increases its TEC by 8 and every receiver increases its REC by 8.
7) After the successful transmission of a message (getting ACK and no error until EOF is finished) the TEC is decreased by 1 unless it was already 0.
8) After the successful reception of a message (reception without error up to the ACK slot and the successful sending of the ACK bit), the REC is decreased by 1, if it was between 1 and 127. If the REC was 0, it stays 0, and if it was greater than 127, then it will be set to a value between 119 and 127.

3 CAN and MCU Serial Port Effective Data Study

This chapter discusses the effective data transmission of CAN and MCU serial ports. Speed and efficiency are the key factors in developing a new technology, and so during the course of this chapter one will see not only how fast and efficient the two communications really are, but also which has better performance.

3.1 CAN Effective Data Study

The CAN bus transmits data in form of the data frame which was described in detail in Chapter 2.3.1. Following a data frame there must always be an interframe space. Table 3.1 shows how many bits (excluding stuffing bits) are needed for transmission of a standard data frame and an extended data frame respectively.

Abbildung in dieser Leseprobe nicht enthalten

Table 3.1 Number of bits for transmission of a standard frame and an extended frame

Regardless of the data field, it takes at least 47 bit times to transmit a standard frame and at least 67 bit times to transmit an extended frame. Considering the data field, if a data frame carries 8 bytes of data, which is 64 bits, then the number of bits for a standard frame is 47 plus 64 which equals 111 and for an extended frame it is 67 plus 64 which equals 131.

In Chapter 2.4 it was explained that CAN uses the bit stuffing method to code frames. The bit stuffing domain spans from the SOF through to the CRC sequence. Within the bit stuffing domain, if there are five consecutive bits including stuffed bits with the same polarity, a sixth complementary bit will be inserted. In the worst case, where the frame has the maximum number of stuffed bits, the number of total bits for both standard and extended formats can be represented by the following formulas:

Abbildung in dieser Leseprobe nicht enthalten

From the above formulas, B is the number of data bytes contained in a data frame, and represent the number of total bits for the standard frame and extended frame respectively. In order to know how effective the transmission is, the proportion of the number of effective data bits to the number of total bits transmitted are used to represent the effective data ratio. That is:

Abbildung in dieser Leseprobe nicht enthalten

In formula 3.3, the B is still the number of data bytes, the N is either or depending on the frame format, the is the result for the ratio.

By setting the value of B in all cases to the formulas 3.1, 3.2 and 3.3 the results can be shown in Table 3.2.

Abbildung in dieser Leseprobe nicht enthalten

Table 3.2 Number of total bits and effective data ratio

From Table 3.2 it is obvious that for the standard format the maximum effective data ratio is 57.7% and for the extended format it is 48.9%.

3.2 MCU Serial Port Study

The speed of MCU serial port is usually measured with baud rate, which indicates the number of signal (symbol) changes per second. Since the serial port transmits one bit (0 or 1) per baud, the baud rate is numerically the same as the bit rate.

3.2.1 General 8051 MCU

The general 8051 MCU, developed by Intel in 1980 using Harvard architecture, has a full duplex asynchronous port which can transmit and receive simultaneously.

There are 4 operation modes for the serial port.

- Mode 0: In this mode the serial port is simply a synchronous shift register. Although it has a fixed baud rate at × (frequency of oscillator), it is not full duplex and usually is used to expand the I/O interface of MCU.

- Mode 1: In this mode the MCU serial port is used to communicate between two devices. The port transmits or receives 10 bits as a frame every time. The 10 bits, in order, are one start bit (0), 8 data bits (Least Significant Bit first), and the last stop bit (1) (see Fig. 3.1). The baud rate is not fixed and can be programmed by the MCU.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 3.1 Serial communication in Mode 1

- Mode 2 and Mode 3: In both modes 11 bits are transferred every time. They in order, are one start bit (0), 8 data bits (LSB first), one programmable bit (which is typically used as a parity check bit) and the last stop bit (1). The two modes are used for multi-machine communications. The only difference between them is the baud rate setting.

In this thesis, the communication between FPGA and MCU was required, therefore Mode 1 was the most suitable choice. In this Mode the form of bit stream is fixed. There are always eight effective data bits of ten total bits in a frame. Therefore, the effective data ratio is 80%. The baud rate is calculated according to the following formula:

Baud_rate = × (3.4)

The SMOD is the highest bit of Power Control Register (PCON). The TH1 is the Timer 1 High Byte Register. The Timer 1 works in Mode 2 (8-bit Timer with auto reload). Fig. 3.2 explains how the Timer 1 works.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 3.2 Timer 1 in Mode 2: 8-bit Auto Reload [6].

With reference to Fig. 3.2, the ‘Periph Clock’ is the peripheral clock whose frequency value is half of the . When the register is set to 0 and the TR1 register is set to 1, the value of the Timer 1 increases bitwise from the value of TH1. At the time when its value exceeds 0xFF (255 in decimal), the Timer 1 notifies the TF1 register by setting it to 1. Immediately the CPU stops increasing the value of the Timer 1 and transmits the data. After the CPU finishes the transmission, it sets the TF1 to 0. The value of Timer 1 will return to the value of TH1 and increase bitwise again. This is the cycle through which the serial port transmits with Timer 1 in Mode 1.

In order to set the maximum baud rate, the SMOD should be set to 1, and the TH1 should be 0xFF (255 in decimal), thus the maximum baud rate is ×. In this thesis the value of was 12 MHz, thus the maximum baud rate achieved was 62.5 kbps.

[...]

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2010
ISBN (eBook)
9783836648691
DOI
10.3239/9783836648691
Dateigröße
4.6 MB
Sprache
Englisch
Institution / Hochschule
Technische Universität Berlin – Fakultät IV - Elektrotechnik und Informatik, Technische Informatik
Erscheinungsdatum
2010 (Juli)
Note
1,3
Schlagworte
fpga can-bus uart labview microcontroller
Zurück

Titel: Implementation of a CAN Bus based Measurement System on an FPGA Development Kit
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
book preview page numper 19
91 Seiten
Cookie-Einstellungen