CAN (Controller area network)
computer science crazy|
Joined: Dec 2008
17-04-2009, 08:18 PM
CAN (Controller area network)
â€œ Protocol for real-time applications
â€œ Developed by Robert Bosch GmbH
â€œ Originally for communication among components of cars
â€œ Applications now using CAN include:
Â¢ elevator controllers, copiers, telescopes, production-line control systems, and medical instruments
â€œ Data transfer rates up to 1 Mbit/s and 11-bit addressing
â€œ Common devices interfacing with CAN:
Â¢ 8051-compatible 8592 processor and standalone CAN controllers
â€œ Actual physical design of CAN bus not specified in protocol
Â¢ Requires devices to transmit/detect dominant and recessive signals to/from bus
Â¢ e.g., Ëœ1â„¢ = dominant, Ëœ0â„¢ = recessive if single data wire used
Â¢ Bus guarantees dominant signal prevails over recessive signal if asserted simultaneously
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
Active In SP
Joined: Feb 2011
05-04-2011, 11:51 AM
final project report..doc (Size: 7.12 MB / Downloads: 201)
CHAPTER 1: INTRODUCTION
This project and implimentation aims in designing a system which helps in monitoring and controlling multi-regions using CAN (Controller Area Network) protocol. This system helps in achieving communication between multiple devices.
The CAN protocol is an ISO standard (ISO 11898) for serial data communication. The protocol was developed aiming at automotive applications. Today CAN has gained widespread use and is used in industrial automation as well as in automotives and mobile machines. The CAN protocol is implemented in silicon. This makes it possible to combine the error handling and fault confinement facilities of CAN with a high transmission speed. The method used for distributing messages to the right receivers contributes to gaining a good use of the available bandwidth. This requires a simple transmission medium. A common transmission medium is a twisted pair of wires. A CAN system can also work with just one wire. In some applications different kinds of links, optical links or radio links, are better suited. Though there is transmission hardware standard (twisted pair), it is not uncommon to use different transmission solutions depending on system requirements.
The modules in this project and implimentation are: Smoke sensor capable of detecting smoke, Gas sensor to detect LPG gas leakages, Temperature sensor to get the temperature, Buzzer to give alerts, Relay to which controlling devices are connected, CAN transceiver is to establish communication between two microcontrollers, LCD to display the parameters.
This system makes use of two Microcontrollers which are connected using a CAN bus. One of the Microcontrollers has Smoke sensor, Gas sensor, Temperature sensor, Relay and Buzzer are interfaced to it. This controller gets input from these sensors and continuously monitors them. The controller automatically controls, if these inputs go beyond threshold level and also alerts through buzzer. These parameters are transferred over CAN bus which is received by the other controller connected to it. This controller makes the parameters to display on LCD connected to it. Also, alerts at this system if parameters go beyond threshold level. The Microcontrollers used in this project and implimentation are programmed using Embedded C programming.
1.2 PROJECT OVERVIEW:
An embedded system is a combination of software and hardware to perform a dedicated task. Some of the main devices used in embedded products are Microprocessors and Microcontrollers.
Microprocessors are commonly referred to as general purpose processors as they simply accept the inputs, process it and give the output. In contrast, a microcontroller not only accepts the data as inputs but also manipulates it, interfaces the data with various devices, controls the data and thus finally gives the result.
The “CAN protocol enable multi-region monitoring and control system” using PIC16F877A microcontroller is an exclusive project and implimentation which is used to design a system which helps in monitoring and controlling multi-regions using CAN (Controller Area Network) protocol. This system helps in achieving communication between multiple devices.
The thesis explains the implementation of “CAN protocol enable multi-region monitoring and control system” using PIC16F877A microcontroller. The organization of the thesis is explained here with:
Chapter 1 Presents introduction to the overall thesis and the overview of the project and implimentation. In the project and implimentation overview a brief introduction of LCD, buzzer, smoke sensor, gas sensor, temperature sensor, relay, and its applications are discussed.
Chapter 2 Presents the topic embedded systems. It explains the about what is embedded systems, need for embedded systems, explanation of it along with its applications.
Chapter 3 Presents the hardware description. It deals with the block diagram of the project and implimentation and explains the purpose of each block. In the same chapter the explanation of microcontrollers, power supplies, LCD, buzzer, smoke sensor, gas sensor, temperature sensor, relay are considered.
Chapter 4 Presents the software description. It explains the implementation of the project and implimentation using PIC C Compiler software.
Chapter 5 Presents the project and implimentation description along with speech recognition module, Ultrasonic sensor module, LCD, buzzer, smoke sensor, gas sensor, temperature sensor, relay interfacing to microcontroller.
Chapter 6 Presents the advantages, disadvantages and applications of the project and implimentation.
Chapter 7 Presents the results, conclusion and future scope of the project and implimentation.
CHAPTER 2: EMBEDDED SYSTEMS
2.1 EMBEDDED SYSTEMS:
An embedded system is a computer system designed to perform one or a few dedicated functions often with real-time computing constraints. It is embedded as part of a complete device often including hardware and mechanical parts. By contrast, a general-purpose computer, such as a personal computer (PC), is designed to be flexible and to meet a wide range of end-user needs. Embedded systems control many devices in common use today.
Embedded systems are controlled by one or more main processing cores that are typically either microcontrollers or digital signal processors (DSP). The key characteristic, however, is being dedicated to handle a particular task, which may require very powerful processors. For example, air traffic control systems may usefully be viewed as embedded, even though they involve mainframe computers and dedicated regional and national networks between airports and radar sites. (Each radar probably includes one or more embedded systems of its own.)
Since the embedded system is dedicated to specific tasks, design engineers can optimize it to reduce the size and cost of the product and increase the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale.
Physically embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure.
In general, "embedded system" is not a strictly definable term, as most systems have some element of extensibility or programmability. For example, handheld computers share some elements with embedded systems such as the operating systems and microprocessors which power them, but they allow different applications to be loaded and peripherals to be connected. Moreover, even systems which don't expose programmability as a primary feature generally need to support software updates. On a continuum from "general purpose" to "embedded", large application systems will have subcomponents at most points even if the system as a whole is "designed to perform one or a few dedicated functions", and is thus appropriate to call "embedded". A modern example of embedded system is shown in fig: 2.1.
Labeled parts include microprocessor (4), RAM (6), flash memory (7).Embedded systems programming is not like normal PC programming. In many ways, programming for an embedded system is like programming PC 15 years ago. The hardware for the system is usually chosen to make the device as cheap as possible. Spending an extra dollar a unit in order to make things easier to program can cost millions. Hiring a programmer for an extra month is cheap in comparison. This means the programmer must make do with slow processors and low memory, while at the same time battling a need for efficiency not seen in most PC applications. Below is a list of issues specific to the embedded field.
In the earliest years of computers in the 1930–40s, computers were sometimes dedicated to a single task, but were far too large and expensive for most kinds of tasks performed by embedded computers of today. Over time however, the concept of programmable controllers evolved from traditional electromechanical sequencers, via solid state devices, to the use of computer technology.
One of the first recognizably modern embedded systems was the Apollo Guidance Computer, developed by Charles Stark Draper at the MIT Instrumentation Laboratory. At the project and implimentation's inception, the Apollo guidance computer was considered the riskiest item in the Apollo project and implimentation as it employed the then newly developed monolithic integrated circuits to reduce the size and weight. An early mass-produced embedded system was the Autonetics D-17 guidance computer for the Minuteman missile, released in 1961. It was built from transistor logic and had a hard disk for main memory. When the Minuteman II went into production in 1966, the D-17 was replaced with a new computer that was the first high-volume use of integrated circuits.
Embedded development makes up a small fraction of total programming. There's also a large number of embedded architectures, unlike the PC world where 1 instruction set rules, and the Unix world where there's only 3 or 4 major ones. This means that the tools are more expensive. It also means that they're lowering featured, and less developed. On a major embedded project and implimentation, at some point you will almost always find a compiler bug of some sort.
Debugging tools are another issue. Since you can't always run general programs on your embedded processor, you can't always run a debugger on it. This makes fixing your program difficult. Special hardware such as JTAG ports can overcome this issue in part. However, if you stop on a breakpoint when your system is controlling real world hardware (such as a motor), permanent equipment damage can occur. As a result, people doing embedded programming quickly become masters at using serial IO channels and error message style debugging.
To save costs, embedded systems frequently have the cheapest processors that can do the job. This means your programs need to be written as efficiently as possible. When dealing with large data sets, issues like memory cache misses that never matter in PC programming can hurt you. Luckily, this won't happen too often- use reasonably efficient algorithms to start, and optimize only when necessary. Of course, normal profilers won't work well, due to the same reason debuggers don't work well.
Memory is also an issue. For the same cost savings reasons, embedded systems usually have the least memory they can get away with. That means their algorithms must be memory efficient (unlike in PC programs, you will frequently sacrifice processor time for memory, rather than the reverse). It also means you can't afford to leak memory. Embedded applications generally use deterministic memory techniques and avoid the default "new" and "malloc" functions, so that leaks can be found and eliminated more easily. Other resources programmers expect may not even exist. For example, most embedded processors do not have hardware FPUs (Floating-Point Processing Unit). These resources either need to be emulated in software, or avoided altogether.