CAN bus in industrial networks. Maximum cable length
CAN (Controller Area Network) is a set of standards for building distributed industrial networks that uses real-time serial data transmission with a very high degree of reliability and security. The central place in CAN is occupied by the data link layer protocol of the OSI model. CAN was originally developed for the automotive industry, but is now rapidly being adopted into the field of industrial automation. It is a well-designed, modern and promising network protocol. The development of CAN was initiated by Bosch in 1983; the first CAN controller chips were released by Intel and Philips in 1987; currently, CAN controllers and transceivers are produced by many companies, including Analog Devices, Inc., Atmel Corp. Cast, Dallas Semiconductor, Freescale, Infineon, Inicore Inc., Intel, Linear Technology, Maxim Integrated Products, Melexis, Microchip, National Semiconductor, NXP, OKI, Renesas Technology Corp., STMicroelectronics, Yamar Electronics, Texas Instruments.
In Russia, interest in CAN has increased greatly in recent years, but there is very little controller equipment for CAN in Russia, tens or hundreds of times less than for Modbus or Profibus. Among the application level protocols for working with CAN, CANopen and DeviceNet are the most widely used in Russia.
Currently, CAN is supported by 11 ISO standards, including [ISO - Diagnostics].
CAN covers two levels of the OSI model: physical and channel (Table 2.7). The standard does not provide any application layer (7th) protocol of the OSI model. Therefore, to implement it, various companies have developed several such protocols: CANopen(organizations CiA), SDS(Honeywell Micro Switch Division), CAN Kingdom(Kvaser company), DeviceNet(from Allen-Bradley, which became a European standard in 2002) and a number of others [Gribanov - Tretyakov].
CAN is characterized by the following basic properties:
- to each message(not the device) priority is set;
- guaranteed length of pause between two acts of exchange;
- configuration flexibility and the ability to upgrade the system;
- broadcast reception of messages with time synchronization;
- consistency of data at the level of the entire system;
- the admissibility of several master devices in the network ("multi-master network");
- ability to detect errors and signal their presence;
- automatic retransmission of messages delivered with an error as soon as the network becomes free;
- automatic discrimination between faults and failures with the ability automatic shutdown failed modules.
The disadvantages include the relatively high cost of CAN devices, the lack of a unified application level protocol, as well as the excessive complexity and intricacy of the channel and application level protocols set out in the organization’s standards CAN in Automation(CiA).
2.6.1. Physical layer
Where is the duration of the leading edge of the transmitter. The basic requirements for the transmission line and its characteristics are close to RS-485, however, CAN transmitters have edge duration control mode impulses. Control is performed by charging the capacitances of the gates of the output transistors from current sources, while the current value is set by an external resistor. Increasing the rise time makes it possible to reduce the line matching requirements by low frequencies, increase the length of the taps and reduce the emission of electromagnetic interference.
The ground terminals of all network transmitters must be connected (if the interfaces are not galvanically isolated). In this case, the potential difference between the grounding terminals should not exceed 2 V. Galvanic isolation is recommended for line lengths of more than 200 m, but is not a mandatory requirement of the standard.
For the electrical connection of devices with a CAN interface, the standard provides two options. The first option is to use T-shaped splitters, which consist of three 9-pin D-sub connectors located in one housing, the contacts of which are connected to each other. The splitters have one connector with pins and two connectors with sockets.
The second option requires two connectors in each CAN device. To connect the device to the network, the cable is cut and mating connectors are installed at its ends. The device literally turns on when there is a break in the transmission line. This approach allows you to increase the number of devices and change the network topology by adding new devices and cables with connectors at the ends to the cable break. One of the connectors must have pins, the other must have sockets. Connecting devices to the bus without connectors is not allowed. The terminating resistor should be located inside the connector that connects to the end of the cable. To connect modules to the CAN bus, a 9-pin D-Sub connector must be used. A connector with sockets is installed on the module, and a connector with pins is installed on the connecting cable. The pinout of the connectors is shown in table. 2.8.
The use of connectors with pins or sockets is determined by the following rule: when hot-swapping modules, power must remain only on the connectors with sockets; this avoids accidental short circuit.
Note that the CANopen standard, based on CAN, provides a much greater variety of connector options, including flat cable, RJ-10, RJ45, detachable screw terminal block, and about ten more special design options [Cabling]. Other connectors can also be used.
|
This property of CAN makes it possible to gain access to a line by comparing the logical levels sent to the line with the level that is actually installed in it: if the transmitter sends a recessive state to the line, but a dominant one remains in it, then the line is busy. Access is granted to the network node that can provide it with a dominant signal level. Nodes with a recessive level leave the line and wait for the next case. This access method is also valid when using a fiber optic channel or a wireless network - in these cases, the presence of light or an electromagnetic wave will always dominate its absence. Conclusion in Fig. 2.20 allows you to set the threshold voltage for the input and the level of common mode voltage in the line when it is in a recessive state. Typically = 2.5 V. To set the level of common mode voltage on the line, the terminal resistances are divided into two 60 ohm resistors, connected in series, and the terminal is connected to the connection point. With a symmetrical pulse shape and a relatively recessive state, the level of radiated interference decreases, since the increments of currents in each of the twisted pair wires when switching logical levels (see Fig. 2.21) turn out to be equal in magnitude, but opposite in sign and therefore compensate each other. The output has several purposes. If it is set to a logic one state, the transceiver goes into sleep mode, in which it draws very little current from the power supply and the output is set to a high-impedance (recessive) state. You can “wake up” it with a signal arriving at the receiver from the transmission line. Connecting this pin to ground through a resistor allows you to set the desired duration of the transmitter pulse rises. Some transceivers have two modes: standby and sleep, which differ in the level of current consumption and the method of switching to active mode. A low-power mode is provided as standard to save battery power in a parked car.
If the signal is dominant for too long (more than 1 ms), the timeout pulse generator (indicated by a rectangle with a pulse in Fig. 2.20) temporarily disables the transmitter, since otherwise the module may be permanently blocked by the link layer as having failed. The standard provides the ability to connect to CAN networks any number of devices, but practically it is limited by the load capacity of the transmitters (100...200) or the delay in repeaters. The CAN transceiver has a clock generator with a frequency of 16 MHz ±0.1%. The width of one bit is programmatically set from 8 to 25 clock pulses, usually 8 pulses at a transmission rate of 1 Mbit/s and 16 pulses at 20 kbit/s. Synchronization of all network nodes occurs during the first synchronization cycle. The bit processing procedure in the receiver provides a programmable delay of the synchronization pulses necessary to compensate for the signal delay time in the communication line and the phase shift due to frequency drift of the clock generator. There are two types of synchronization: hard synchronization using the start bit at the beginning of the message and resynchronization during message transmission. Using resynchronization, you can adjust the time interval from the start of synchronization to the moment at which the logical level of the received data pulse is measured. The adjustment interval can be changed to 1...4 cycles. To determine the logical state of the bus, the levels of received signals are measured at a distance of 6 clock cycles from the leading edge of the pulse (bit) at a speed of 1 Mbit/s and at a distance of 14 clock cycles at a speed of 20 kbit/s [CAN ] (for comparison, we indicate that in standard UART samples are taken in the middle of the pulse). The number of samples can be 1 or 3 (set by software). CAN uses synchronous bit transmission. This increases the communication channel capacity, but requires a more complex synchronization process.
| |||||||||||
The CAN (Controller Area Network) network interface was developed in 1987. (version 1.0) by BOSCH and INTEL to create on-board real-time multiprocessor systems. The latest interface specification 2.0, developed by BOSCH in 1992, is an addition to the previous version. ISO 11898 (for high-speed applications) and ISO 11519-2 (for low-speed applications) are registered with the International Standards Organization.
Principle of operation
CAN is a highly integrated network data transfer interface with speeds up to 1 Mbit/s. Devices in the CAN system are connected via a bus consisting of 3 wires (2 signal and one common) (see figure).
Data messages transmitted from any node via the CAN bus can contain from 1 to 8 bytes. Each message is marked with an identifier that is unique on the network (for example: “Heating to 240”, “Heating failure”, “Bunker loaded”, etc.). During transmission, other network nodes receive the message and each of them checks the identifier. If the message is related to this node, then it is processed, otherwise it is ignored. The CAN controller of each device can process several identifiers simultaneously (for example, SIEMENS and INTEL controllers can process up to 15). Thus, in each device you can easily organize several “virtual” channels for exchanging information with various devices, including channels for simultaneous receipt of messages.
Rice. 1. Connecting devices via CAN bus
Identifiers
The identifier determines the type and priority of the message. A lower numerical ID value corresponds to a higher priority value. A message with a higher priority is transmitted before a message with a lower priority. After a message with a high priority, a message with a lower priority is transmitted, unless a message with a higher priority appears during transmission, then a message with an even lower priority is transmitted, etc.
Physical bus
It consists of a twisted pair (shielded or unshielded) and a common wire. Flat pair (telephone type cable) also works well, but is more sensitive to external noise sources.
High reliability
To ensure trouble-free operation in harsh conditions according to the ISO11898 standard, the CAN controller provides network operation in the following cases:
- any of the 3 wires in the bus is broken,
- any wire is shorted to power,
- any wire is shorted to common wire.
If 2 wires break, some of the functions of the main system can be implemented in each of the subsystems created by the break.
Network flexibility and ease of expansion
The message transmission scheme adopted in the CAN network provides great opportunities for creating, expanding and modernizing systems.
New devices designed to receive data can be added to the network without changing existing ones software, if their connection does not lead to exceeding the load capacity and maximum bus length. At the same time, new network devices are able to exchange information with each other without disrupting the functionality of the old system, if new identifiers were used in the exchange protocol.
The CAN network has the ability to simultaneously transmit messages to several devices at once. This feature allows you to transmit clock signals through it.
CAN bus arbitration
In any system, some parameters change faster than others. For example, the rotor speed of an engine typically changes over a shorter period of time than the temperature of its housing or the position of the damper. Rapidly changing parameters must be transmitted more frequently and therefore require higher priority. During operation, it is also possible that alarm messages may occur and must be transmitted with the highest priority (e.g. exceeding permissible temperature, breakage of the control solenoid, short circuit in a circuit, etc.).
CAN network nodes are equal in the exchange, and each of them at any time can have a message that requires immediate transmission. The possibility of simultaneous transmission demands from different devices is not unusual, but happens regularly. To resolve such a conflict, a high-speed mechanism for distributing the order of message transmission is required. For this purpose, the CAN system uses Non-Destructive Bitwise Arbitration.
The priority of a CAN message is determined by the binary value of its identifier.
A numerical value for each message identifier is assigned during the initial system design phase. The ID with the lowest numerical ID value has the highest priority. Transmission of a logical zero via the CAN bus is carried out by a current send, and the state of a logical one is determined by the absence of current. During the transmission process, each of the message sources that needs transmission begins to transmit its identifier, simultaneously checking it on the line. If a mismatch is detected during the transmission process (i.e., an “extra” zero), then the transmitter that detects this mismatch stops transmitting its identifier and switches to receiving. There is no contention on the bus, since the logic-one bit value is not actually transmitted, and as a result, the message with the highest priority passes along the bus as if it were the only one. On the next bus cycle, a lower priority message will be sent, and so on. This ensures maximum bus throughput and minimum latency for hot messages.
Rice. 2. Connecting devices via CAN bus
Error Detection
CAN contains a 5-stage error detection mechanism:
- cyclic redundancy check (CRC),
- control of the transmitted bit field,
- control of the "Acknowledgment" signal,
- current monitoring of the logical bit level,
- bit filling control.
Cyclic Redundancy Check (CRC)
Each transmitted message contains a control code (CRC) calculated by the transmitter based on the content of the transmitted message. Receiving nodes perform a similar operation, flag detected errors and set the appropriate flags.
Logic bit level monitoring
Any transmitter automatically monitors and compares the actual logical bit level on the bus with the level it is transmitting. If the levels do not match, a logical bit level error is flagged.
(Note: this mechanism is also used in bus arbitration to determine the priority of a message, but of course an error does not occur in this case.)
Control of the transmitted bit field
Predefined bit combinations are transmitted as part of a CAN message, which are controlled upon reception. If the receiver detects an invalid bit in one of these combinations, the format error flag is set.
Bit stuffing control
CAN uses a technique of adding a padding bit to further control the messages being transmitted. After transmitting five consecutive bits with the same level, the transmitter automatically inserts a bit of the opposite value into the bit stream. Message receivers automatically remove such bits before processing the message. If a sixth bit of the same polarity is detected, a bit stuffing error is flagged.
Control of the Acknowledgment signal
Each transmitted message is acknowledged by the receiver, and if this does not happen, then the acknowledgment error flag is set.
Error flag
If an error is detected, the node that detected the error interrupts the transmission by sending an error flag. In this case, the transmitter automatically reinitializes the transmission of the message, which prevents all nodes from causing errors and guarantees the consistency of data in the network.
Taking into account the operation of all control mechanisms, the real value of the occurrence of an undetected error in the CAN system is 10-11.
CAN message format
The standard CAN protocol (version 2.0A) supports a message format with 11-bit identifiers (Standard message).
The Enhanced CAN Protocol (version 2.0B) supports 11-bit and 29-bit identifier formats (Extended Message).
Most version 2.0A controllers send and receive only standard format messages, although some can only receive extended format messages.
Version 2.0B controllers can send and receive messages in both formats.
Format differences
In version 2.0B, the identifier bits field consists of two parts.
First part(the main part of the identifier) is eleven bits long for compatibility with version 2.0A, The second part- eighteen bits (identifier extension), giving a total identifier length of twenty-nine bits.
The Identifier Extension (IDE) and Substitute Remote Request (SRR) bits in the Arbitration Field are used to distinguish between formats.
Administrator
Necessity of serial connection in cars
This is our next translated article from the series dedicated to the CAN bus, which reveals in a little more detail how the CAN bus is structured and functions. English original.
Many cars already have a large number of electronic control systems. The growth of automotive electronics is the result partly of consumer desire for greater safety and comfort, and partly of government demands for better emissions controls and lower fuel consumption. Control devices meeting these requirements have already been used for some time in the field of engine, gearbox and throttle valve, as well as in anti-lock braking systems (ABS) and acceleration control (ASC).
The complexity of the functions implemented in these systems requires the exchange of data between them. In traditional systems, data is exchanged using dedicated signal lines, but this is becoming increasingly difficult and expensive as control functions become more complex. In the case of complex control systems (such as Motronic), in particular, the number of connections cannot be increased any further.
In addition, a number of systems are being developed that implement functions that span more than one control device. For example, ASC requires interaction between the engine management system and throttle (injection) control to reduce torque when the drive wheel slips. Another example of functions spanning more than one control unit is electronic gearbox control, where ease of gear shifting can be improved by momentarily adjusting the ignition timing.
If we also consider future developments aimed at overall optimization of vehicles, it is necessary to overcome the limitations existing in connection with conventional control devices. This can only be done by networking the system components using a serial data bus. Bosch developed a "Controller Area Network" (CAN) system for this purpose, which has since been standardized internationally (ISO 11898) and has been "cast in stone (in silicon)" by several semiconductor manufacturers.
Using CAN, peer (single-level) stations (controllers, sensors and actuators) are connected via a serial bus. The bus itself is a symmetrical or asymmetrical two-wire circuit that can be shielded or unshielded. The electrical parameters of the physical transmission are also specified in the ISO 11898 standard. Suitable bus driver chips are available from a wide range of manufacturers
The CAN protocol, corresponding to the data link layer of the ISO/OSI reference model, meets the automotive requirements for current automotive applications. Unlike cable trees, the network protocol detects and corrects transmission errors caused by electromagnetic interference. Additional benefits Such a network is characterized by ease of configuration of the entire system and the possibility of central diagnostics.
The purpose of using CAN in vehicles is to allow any station to communicate with any other without placing too much load on the controller's computer.
Using a CAN network in cars
There are four main applications for serial communications in vehicles, each with different requirements and purposes.
Network controllers for synchronizing engine, transmission, chassis and brakes. Data transfer rates range from 200 kbit/s to 1 Mbit/s, typical for real-time systems.
Network components of general electronics and chassis electronics that make the car more comfortable. Examples of such multiplex applications are lighting control, air conditioning and central locking, as well as seat and mirror adjustment. Particular attention here must be paid to component costs and wiring requirements. Typical data transfer rates are around 50 kbit/s.
In the near future, serial communication will also be used in the field of mobile communications to link components such as car radios, car phones, navigation aids, etc., to a central, more ergonomic control panel. The functions defined in Project Prometheus, such as vehicle-to-vehicle communications, will rely heavily on serial communications.
Currently CAN is used for the first three applications, but for diagnostics the preferred solution is an interface in accordance with the ISO 9141 standard.
Industrial applications of CAN network
A comparison of the requirements for vehicle bus systems and industrial fieldbus systems reveals surprising similarities: low cost, performance in harsh electrical environments, high real-time capabilities and ease of use are equally desirable in both sectors.
The standard use of CAN in the Mercedes-Benz "S-Class" and the adoption of CAN by US commercial automakers for fast transmission (up to 1 Mbit/s) had industrial users pricking up their ears. Not only have manufacturers of mobile and stationary agricultural and marine machinery and equipment chosen CAN, but so have manufacturers of medical equipment, textile machinery, and specialty machinery and elevator controls. The serial bus system is particularly well suited for networked "smart" I/O devices, as well as sensors and actuators within a machine or plant.
The textile machinery industry is one of the pioneers of CAN. One manufacturer equipped its weaving machines with modular control systems communicating in real time via CAN networks as early as 1990. Meanwhile, several textile machine manufacturers have banded together to form the CAN Textile Users Group, which in turn is a member of the international user and manufacturer group CAN in Automation. Similar requirements for textile machinery are found in packaging machines and paper making and processing machines.
In the US, a number of enterprises use CAN in production lines and machines as an internal bus system for networked sensors and actuators within the line or machine itself. Some users, such as the medical engineering sector, decided in favor of CAN because they had particularly stringent safety requirements. Other manufacturers of machinery and equipment with special safety requirements (e.g. robots and transport systems) face similar problems.
In addition to high transmission reliability, low connection costs per station are another decisive argument for CAN. In applications where cost is critical, it is critical that CAN chips be available from various manufacturers. The compactness of other controller chips is also an important argument, for example in the field of low-voltage switchgear.
How CAN networks work
Data exchange principles
When data is transmitted over CAN, no stations are addressed, but instead the contents of the message (such as engine speed or temperature) are identified by an identifier that is unique throughout the network. The identifier determines not only the content, but also the priority of the message. This is important for bus distribution, where multiple stations compete for access to the bus. If the CPU of a given station wants to send a message to one or more stations, it transfers the data and their identifiers to the designated CAN chip (Ready state). This is all the CPU has to do to initiate communication. The message is generated and transmitted using a CAN chip. Once a CAN chip receives a bus allocation (Send Message state), all other stations on the CAN network become recipients of that message (Receive Message state). Each station on the CAN network, having correctly received a message, performs an acceptance test (receive test) to determine whether the received data belongs to that station (Select state). If the data is relevant for the corresponding station, it is processed (state "Accepted"), otherwise it is ignored. A high degree of system and configuration flexibility is achieved thanks to the content-oriented addressing scheme. It is very easy to add stations to an existing CAN network without making any hardware or software changes to the existing stations, as long as the new stations are pure receivers. Since the data transfer protocol does not require physical destination addresses for individual components, it supports the concept of modular electronics and also allows multiple reception (broadcast, multicast) and synchronization of distributed processes: measurements required as information by several controllers can be transmitted via a network in such a way that each controller does not need to have its own sensor.
1. Broadcasting and input filtering by CAN nodes to determine whether the data is suitable for a particular node
Non-destructive bit checking:
In order for data to be processed in real time, it must be transmitted quickly. This not only requires a physical data link of up to 1 Mbps, but also requires fast bus distribution when multiple stations want to send messages simultaneously.
2. The principle of non-destructive bit checking (evaluation, reading)
In real time, the urgency (queuing) of messages exchanged over a network can vary greatly: a rapidly changing dimension (e.g., engine load) must be transmitted more frequently and therefore with less latency than other measurements (e.g., engine temperature) that vary relative to slowly. The priority at which a message is transmitted over another less urgent message is determined by the associated message ID. Priorities are set during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the smallest binary number has the highest priority.
Bus access conflicts are resolved by bit by bit checking each participating station for the received identifiers by observing (reading) the bus layer bit by bit. According to the "wire and" mechanism whereby the dominant state (logical 0) overwrites the recessive state (logical 1), contention for bus allocation is lost by all these stations with recessive transmission and dominant observation (waiting for 0 to receive). All "losers" automatically become recipients of the highest priority message and do not retransmit until the bus is available again.
Bus Distribution Efficiency:
The efficiency of a bus distribution system is determined mainly by possible application for this serial bus system. To judge which bus systems are suitable for which applications, the literature includes a method for classifying bus allocation procedures. Typically we distinguish the following classes:
Distribution according to a fixed schedule. Allocation is made sequentially to each participant for maximum duration, regardless of whether that participant needs a bus in this moment or not (examples: token cell or token passing).
Bus allocation based on need. The bus is assigned to one participant based on outstanding transfer requests, that is, the allocation system only considers participants wishing to transfer (examples: CSMA, CSMA/CD, control flight, round robin or bit check). For CAN, the bus allocation is negotiated exclusively between messages waiting to be transmitted. This means that the procedure defined by CAN is classified as need-based allocation.
Another means of assessing the effectiveness of bus inspection (evaluation) systems is the bus access method:
Non-destructive access to the bus. With this type of method, a bus is assigned to one and only one station, either immediately or for a specified period of time after one access to the bus (by one or more stations). This ensures that each access to the bus by one or more stations results in a unique bus allocation (examples: token cell, token pass, round robin, bit check.
Destructive tire distribution. Simultaneous access to the bus by more than one station causes all transmission attempts to be aborted and, therefore, there is no successful bus allocation. Bus allocation may require more than one bus access, the number of attempts before successful bus allocation is purely a statistical value (examples: CSMA/CD, Ethernet). In order to process all CAN network transfer requests while respecting latency limits at the lowest possible data rate, the CAN protocol must implement a bus allocation method that ensures that there is always a unique bus allocation, even if there are simultaneous bus accesses from different stations.
The bitwise check method, using the identifier of the messages to be transmitted, uniquely resolves any collision between multiple stations that want to transmit, and it does so at the latest within 13 (standard format) or 33 (extended format) bit periods for any access period. tire. Unlike message checking used by the CSMA/CD method, this non-destructive collision resolution method ensures that bus bandwidth is not used without transferring useful information.
Even in situations where the bus is congested, the association of bus access priority with message content proves to be a useful system attribute compared to existing CSMA/CD or token protocols: despite insufficient bus bandwidth, all outstanding transfer requests are processed in order their importance to the entire system (as determined by the priority of the message).
The available bandwidth is effectively used to transfer useful data, since the "gaps" in the bus allocation remain very small. A crash of the entire transmission system due to overload, which can happen with the CSMA/CD protocol, is not possible with CAN. Thus, CAN allows for fast, traffic-specific bus access that is non-destructive due to bit-based checking based on the message priority used.
Non-destructive bus access can be divided into:
Centralized bus access control and
Decentralized bus access control
Depending on whether control mechanisms are present in the system only once (centralized) or more than once (decentralized).
Communication system with a designated station (in particular for centralized management bus access) must provide a policy that takes effect in the event of a failure of the primary station. This concept has the disadvantage that the failure management strategy is complex and expensive to implement, and that it can take a very long time for the backup station to take over the central station.
For these reasons, and to circumvent the reliability problem of the master station (and therefore the entire communication system), the CAN protocol implements decentralized bus control. All basic communication mechanisms, including bus access control, are executed multiple times in the system because this is the only way to meet the high availability requirements of the communication system.
In general, we can say that CAN implements a traffic-specific bus distribution system that allows, through non-destructive bus access with decentralized access control, to provide a high usable data rate at the lowest possible bus data rate under busy bus conditions for all stations. The efficiency of the bus check procedure is increased by ensuring that the bus is used only by those stations that are waiting to transmit requests.
These requests are processed in order of importance of the messages to the system as a whole. This is especially beneficial in case of overload. Since bus access is prioritized based on messages, low individual latency can be guaranteed in real-time systems.
3. Message frame for standard format (CAN Specification 2.0A)
Message formats.
The CAN protocol supports two message frame formats, the only significant difference being the length of the identifier (ID). In the standard format, the length of the identifier is 11 bits, and in the extended format, the length is 29 bits. A bus message frame contains seven main fields.
A message in standard format begins with a "start of frame" start bit, followed by a "check field" that contains an identifier and an "RTR" (remote transfer request) bit that indicates whether it is a frame with data or a request frame without any data. or data bytes (remote request frame).
The "control field" contains the IDE extension bit (extension identifier) which indicates either the standard format or the extended format, the bit is reserved for future extensions and - in the last 4 bits - the count of data bytes in the data field.
The "data field" ranges from 0 to 8 bytes in length and is accompanied by a "CRC" field, which is used as a frame security check to detect bit errors.
The "ACK" field contains an ACK slot (1 bit) and an ACK delimiter (one recessive bit). The bit in the ACK slot is sent as a recessive bit and is rewritten as a dominant bit by those receivers that received the data correctly at that point in time (positive acknowledgment). Correct messages are confirmed by receivers regardless of the result of the acceptance check. The end of the message is indicated by "end of frame". A "gap" is the minimum number of bit periods separating consecutive messages. If there is no station next access to the bus, the bus remains idle (“bus idle”).
Error detection and signaling.
Unlike other bus systems, the CAN bus protocol does not use acknowledgment messages, but instead signals any errors that occur. To detect errors in the CAN protocol, three mechanisms are implemented at the message level:
Cyclic Redundancy Check (CRC) CRC protects information in a frame by adding redundant check bits at the end of the transmission. At the receiver end, these bits are recalculated and checked against the received bits. If they do not agree, a CRC error has occurred. Frame verification - This mechanism checks the structure of the transmitted frame by checking the bit fields for a fixed frame format and size. Errors found when checking frames are referred to as "format errors".
ACK errors. As mentioned above, received frames are acknowledged by all recipients through a “positive acknowledgment.” If no acknowledgment is received by the sender of the message (ACK error), this may mean that there is a transmission error that was detected only by receivers, that the ACK field was corrupted, or that there are no receivers.
The CAN protocol also implements two bit-level error detection mechanisms.
Monitoring. A transmitter's ability to detect errors is based on monitoring bus signals: each node that transmits also monitors the bus level and thus detects differences between the sent bit and the received bit. This ensures reliable detection of all global errors and errors local to the transmitter.
Bit stuffing - the encoding of individual bits is checked at the bit level. The bit representation used by CAN is NRZ (non-return-to-zero) encoding, which guarantees maximum efficiency in bit encoding. Synchronization edges are generated by bit stuffing, that is, after five consecutive equal bits, the sender inserts a bit of information into the bit stream with an additional value, which is removed by the receivers. Code checking is limited to checking compliance with the filling rule. If one or more errors are detected by at least one station (any station) using the above mechanisms, the current transmission is interrupted by sending an "error flag". This prevents other stations from receiving messages and thus ensures data consistency throughout the network.
After the transmission of an erroneous message is terminated, the sender automatically retries the transmission (automatic retry request). Competition for bus allocation may arise again. Typically, retransmission begins within 23-bit periods after an error is detected; In special cases, the system recovery time is 31 bits.
However, the described method can be effective and efficient in the case where a station malfunction can lead to the interruption of all messages (including correct ones), which blocks the bus system if no measures have been taken for self-monitoring. Thus, the CAN protocol provides a mechanism for separating sporadic errors from persistent errors and localizing station failures (error limitation). This is done by statistically assessing plant error situations in order to recognize the plant's own defects and possible entry into an operating mode where the rest of the CAN network is not negatively affected. This can go so far as to cause the station to turn itself off to prevent incorrect messages from being mistakenly recognized among those that were interrupted.
CAN protocol data reliability:
The implementation of safety-related systems in cars is associated with high requirements for the reliability of data transmission. The goal is often stated to ensure that no dangerous situations arise for the driver as a result of data exchange throughout the life of the vehicle.
This goal is achieved if the reliability of the data is sufficiently high or the probability of residual error is sufficiently low. In the context of data bus systems, reliability refers to the ability to identify data corrupted by transmission errors. Residual error probability is a statistical measure of the degradation of data reliability: it determines the likelihood of data corruption and that this corruption will go undetected. The probability of residual error must be so small that, on average, no corrupted data will go undetected throughout the life of the system.
4. Residual error probability as a function of bit error probability
Calculating the residual error probability requires that the errors are classified and that the entire transmission path is described by the model. If we define the CAN residual error probability as a function of the bit error probability for message lengths between 80 and 90 bits, for system configurations, for example, five or ten nodes and with an error rate of 1/1000 (an error in one message in every thousand), then the maximum probability of a bit error is approximately from 0.02 to about 10^-13. From this, the maximum number of undetectable errors for a given CAN network can be calculated.
For example, if a CAN network operates at a data rate of 1 Mbps, with an average bus bandwidth utilization of 50%, a total lifespan of 4000 hours, and an average message length of 80 bits, then the total number of messages transmitted is 9x10^10. The statistical number of undetected transmission errors during the service life is therefore less than on the order of 10^-2. Or, to put it another way, with a runtime of eight hours a day for 365 days a year and an error rate every 0.7 seconds, one undetected error occurs once every thousand years (statistical average).
Extended Format CAN Messages
The SAE Truck and Bus Subcommittee has standardized signals, messages, and data communications protocols for different speeds data transmission. It became apparent that this type of standardization was easier to implement when a longer identification field was available.
To support these efforts, the CAN protocol was expanded to introduce a 29-bit identifier. This identifier consists of an existing 11-bit identifier (base ID) and an 18-bit extension (extension ID). Thus, the CAN protocol allows the use of two message formats: StandardCAN (Version 2.0A) and ExtendedCAN (Version 2.0B). Since the two formats must coexist on the same bus, it is established which message has higher priority on the bus in the event of bus access collisions with antialiasing formats and the same base identifier: a standard message always takes precedence over a message in an extended format.
CAN controllers that support extended format messages can also send and receive standard format messages. Only messages in the standard format can be transmitted throughout the network if the network uses CAN controllers that only support the standard format (Version 2.0A). Messages in extended format will be misunderstood. However, there are CAN controllers that support only the standard format, but recognize messages in the extended format and ignore them (version 2.0B passive).
The distinction between standard format and extended format is made using the IDE bit (identifier extension bit), which is transmitted as dominant in the case of a frame in standard format. For extended format frames this is recessive. The RTR bit is transmitted dominant or recessive depending on whether data is being transmitted or a specific message is being requested from the station. Instead of the RTR bit in the standard format, the SRR (Substitute Remote Request) bit is sent for Extended ID frames. The SRR bit is always transmitted as recessive to ensure that, in the event of a check, the standard frame always has priority bus allocation to the extended frame when both messages have the same base identifier.
Unlike the standard format, in the extended format the IDE bit is followed by an 18-bit ID number, an RTR bit, and a reserved bit (r1).
All of the following fields are identical to the standard. Compliance between the two formats is ensured by the fact that CAN controllers that support the extended format can also communicate in the standard format
5. Message frame for extended format (CAN Specification 2.0A)
CAN protocol implementations
Communication is identical for all implementations of the CAN protocol. However, there are differences in the extent to which an implementation communicates messages from the microcontrollers that follow it in the circuit. Communication is identical for all implementations of the CAN protocol. However, there are differences in how message passing is implemented from the microcontrollers that follow it in the circuit.
CAN controller with intermediate buffer
Buffer-based CAN controllers (previously called basicCAN chips) implement in hardware the logic needed to create and verify the bit stream according to the protocol. However, the administration of data sets that must be sent and received, in particular reception filtering, is carried out only by the CAN controller.
Typically, CAN controllers with an intermediate buffer have two receive and one transmit buffer. The 8-bit code and mask registers allow limited accept filtering (8 MSB identifiers). Appropriate selection of these register values allows groups of identifiers to be read or, in edge cases, all identifiers to be selected. If more than 8 ID-MSBs are required to differentiate messages, then the microcontroller following the CAN controller in the circuit must supplement the acceptance filtering with software.
CAN controllers with an intermediate buffer can offload a large load to the microcontroller with receive filtering, but they require only a small die area and can therefore be manufactured at a lower cost. In principle, they can receive all objects in the CAN network.
CAN controller with object storage.
CAN objects consist primarily of three components: an identifier, a data length code, and the actual payload.
CAN controllers with object storage (previously called fullCAN) function like CAN controllers with intermediate buffers, but also control specific objects. Where there are multiple simultaneous requests, they determine, for example, which object should be transferred first. They also perform acceptance filtering on incoming objects. The interface to the next microcontroller corresponds to RAM. The data to be transmitted is written to the corresponding RAM area, the received data is read from the RAM area accordingly. The microcontroller only needs to control a few bits (such as the transfer request).
CAN controllers with object storage are designed to handle maximum load from the local microcontroller. However, these CAN controllers require larger die area and are therefore more expensive. In addition to this, they can only administer a limited number of chips (microcontrollers).
Today, CAN controllers are available that combine both implementation principles. They have an object store, by at least one of which is designed as an intermediate buffer. For this reason, there is no longer any point in differentiating between basicCAN and fullCAN.
CAN slave controllers for I/O functions.
Just like CAN controllers that support all the functions of the CAN protocol, there are CAN chips that do not require a subsequent microcontroller. These CAN chips are called SLIO ( serial connection input/output). CAN chips are slaves and must be controlled by a CAN master (central, main microcontroller in the network).
Physical CAN connection
Data rates (up to 1 Mbit/s) require a fairly steep pulse slope, which can only be realized using power elements. In principle, several are possible physical connections. However, users and manufacturers of the CAN in Automation group recommend using driver circuits in accordance with ISO 11898.
Embedded driver ICs in accordance with ISO 11898 are available from several companies (Bosch, Philips, Siliconix and Texas Instruments). The International Users and Manufacturers Group (CiA) also defines several mechanical connections (cable and connectors).
6. Physical CAN Connection according to ISO 11898
Sincerely, translation provided by the workshop team
Store currency is rubles.
CAN bus. Part 1.
1. The local network controllers (CAN)
Areas of use.
Electronic distributors, Automobiles, Marine vessels, Hydraulic equipment, Textile industry, Process industry, Medical equipment, Railway, Construction automation, Aviation radio electronics, Household appliances, Armed forces, Materials processing, Agriculture, Telecommunications, Trucks, Construction Machinery and Vehicles, Industrial Automation.
General information
Controller Area Network (CAN) is a serial bus standard developed in the 80s by Robert Bosch GmbH for connecting electronic control units. CAN was specially designed for stable operation in noise-rich environments. environment using a multi-balanced line such as RS-485. The connection may be more resistant to interference when using twisted pair. Originally created for automotive purposes, but is currently used in a variety of control systems, incl. industrial workers working in noise-rich environments.
Data exchange speeds of up to 1Mbit/s are possible in networks with a length of no more than 40m. Reducing the exchange rate allows you to increase the length of the network, for example - 250 Kbit/s at 250m.
The CAN communication protocol is standardized according to ISO 11898-1 (2003). This standard primarily describes the communication layer consisting of the logical control (LLC) subclause and the access control (MAC) subclause, and some aspects of the physical layer of the ISO/OSI model. The remaining protocol layers are left to the discretion of the network developer.
CAN networks and their varieties
There are various CAN networks. For example, in automobiles, CAN networks are divided into two categories based on the principle of data transmission over the network.
Networks for monitoring comfort and convenience systems, with a large number of information identifiers that are transmitted without observing a certain order or frequency.
And powertrain control networks manage information related to the engine and transmission. They contain less information, but the information is transmitted in an organized and fast manner.
general characteristics
Integrated serial communication bus for real-time applications.
. The network is operational at a data exchange rate of up to 1Mbit/s.
. Has excellent error and malfunction detection and testing capabilities.
. CAN bus was originally designed for use in automobiles.
. Used in various automatic and control systems.
. International standard: ISO 11898
Definition of CAN
CAN is a serial bus system adapted for organizing a network of intelligent devices, as well as sensors and actuators in a system or subsystem.
CAN properties
A CAN system on a serial bus with multifunctional capabilities, all CAN nodes are capable of transmitting data and some CAN nodes can request the bus at the same time. The transmitter transmits the message to all CAN nodes. Each node, based on the received identifier, determines whether it should process the message or not. The identifier also determines the priority that a message has when accessing the bus. Simplicity determines the cost of equipment and the cost of personnel training. CAN chips can be programmed relatively easily. Introductory courses, functional libraries, starter kits, various interfaces, I/O modules and tools in a wide variety are available for public sale at affordable prices. Since 1989, CAN chips can be freely and simply connected to microcontrollers. There are currently about 50 CAN chips available for microcontrollers from more than 15 manufacturers.
CAN is used in most European passenger cars, as well as the decision of truck and SUV manufacturers to further use CAN, determined the development for more than 10 years. Other application areas such as the consumer and industrial sectors have seen growth in sales of CAN equipment and will continue to do so in the future. By the spring of 1997, there were already more than 50 million installed CAN nodes. One of the outstanding features of the CAN protocol is the high reliability of data exchange. The CAN controller records errors and processes them statistically to make appropriate measurements; the CAN node that is the source of the fault will be removed from the connection as a result.
Each CAN message can contain from 0 to 8 bits of user information. Of course, it is possible to transmit longer data using fragmentation. The maximum specified exchange rate is 1 Mbit/s. This is possible with a network length of no more than 40m. For longer communications, the exchange rate must be reduced. For a distance of up to 500 m, the speed is 125Kbit/s, and for transmission over 1 km, a speed of 50 Kbit/s is allowed.
CAN applications
CAN networks can be used as embedded communication systems for microcontrollers as well as open communication systems for smart devices. The CAN serial bus system, developed for automotive applications, will be widely used in industrial communication systems and in many ways they will be similar. In both cases, the main requirements are: low cost, ability to function in difficult conditions, long-term performance and ease of use.
Some users, for example in the field of medical engineering, prefer CAN because stringent safety requirements must be met. Similar conditions with increased requirements for reliability and safety are imposed on some other devices and equipment (i.e. robots, lifting and transport systems).
CAN license
The CAN protocol was developed by Robert Bosch GmbH and is protected by patents.
Basic CAN standards
The following are some international CAN standards
. CAN standards:
o ISO 11898-1 - CAN protocol
o ISO 11898-2 - CAN high speed physical structure
o ISO 11898-3 - CAN low speed fault compatible physical structure
o ISO 11898-4 - CAN start
o ISO 11898-5 - High speed low voltage device (in development).
o ISO 11519-2 - replaced by 11898-3.
. ISO 14230 - "Keyword Protocol 2000" - diagnostic protocol using serial line, not CAN
. ISO 15765 - Diagnostic protocol on CAN bus - Keyword 2000 on CAN bus.
. J1939 - Basic CAN protocol for trucks and buses defined by SAE
. ISO 11783 - J1939 and supplement for agricultural machinery
. ISO 11992 - defines the interface of tractors and trailers
. NMEA 2000 - A protocol based on J1939 for ships, defined by NMEA.
The CAN protocol is an ISO standard (ISO 11898) for serial data transmission. The protocol is designed for automotive applications. Currently, CAN systems are widespread and are used in industrial automation, various transport, special machines and cars.
Advantages of CAN:
- Availability for the consumer.
The CAN protocol has been successfully used for more than 15 years, since 1986. There is a wide selection of CAN products and devices available for sale.
- Implementation of the protocol at the hardware level
The protocol is based on the hardware level. This makes it possible to combine the ability to recognize and control errors with the ability to transmit high-speed data.
- Primitive transmission line
The data line, in most cases, is twisted pair. But communication via the CAN protocol can also be carried out over one wire. In various cases, it is possible to use the most suitable communication channels, optical or radio channel.
- Excellent error and failure detection and fault localization ability.
The ability to detect errors and failures is a significant advantage of the CAN protocol. The error detection mechanism is built on an extensive principle, and the system for checking and confirming errors and failures is also reliable and well developed.
The fault detection system and data retransmission are performed automatically at the hardware level.
- Fault detection and testing system
A faulty source in the system can disorganize the entire system, i.e. occupy all communication channels. The CAN protocol has a built-in capability that protects the system from the source of the malfunction. The source of the error is removed from receiving and transmitting data via the CAN bus.
2. CAN bus
Introduction
The CAN protocol is an ISO standard (ISO 11898) for serial data transmission. The protocol is designed for automotive applications. Currently, CAN systems are widespread and used in industrial automation, various transport, special machines and cars.
The CAN standard describes the signal parameters at the physical level and the order of data transmission, which is determined by two various types messages, bus access arbitration rules, and a method for identifying and testing faults.
CAN protocol
CAN is defined by ISO 11898-1 and includes the following basic information.
. At the physical level, the signal is transmitted using twisted pair cables.
. Arbitration rules are applied to control bus access.
. Data blocks are small in size (in most cases 8 bytes) and are protected by a checksum.
. Data blocks have no addressing; instead, each block contains numeric value, which determines the priority of transmission on the bus, can also carry an identifier for the contents of a data block.
. a complex error handling scheme that results in retransmission of data that is not properly received.
. Effective fault isolation actions and disconnecting the fault source from the bus.
Higher Order Protocols (HLP)
The CAN protocol defines the secure transmission of small data packets from point A to point B using a common communication line. The protocol does not contain flow control, addressing, does not provide message transmission of more than 8 bits, does not establish a connection, etc. The listed properties are defined by HLP (Higher layer protocol) or Higher Order Protocol. The HLP conditions are derived and consist of seven orders of the OSI model.
Purpose of HLP
. Standardize startup procedures and set baud rates
. Distribution of device addressing and types of messages.
. Determining the order of messages
. provides a system-level fault detection mechanism
CAN products
There are two kinds of CAN products, CAN chips and CAN enablers and development tools.
At the highest level are two other product lines, CAN modules and CAN development tools. A wide variety similar products available for public sale.
CAN Patents
Patents for CAN applications can be of various types and directions. Below are several types:
. Synchronization and implementation of transmission frequency
. Transmission of large blocks of data (CAN protocol uses frames no longer than 8 bits)
Distribution control systems
The CAN protocol is a productive basis for creating distribution control systems. The arbitration method allows each CAN device to interact with messages regarding that device.
A distribution control system can be stated as a system in which the capabilities of the processor are distributed among the system devices, or, conversely, as a system with a central processor and local I/O devices.
When developing a CAN network, various compatible hardware devices can be used that have the necessary properties and satisfy the specified or calculated parameters of the network, such as processor frequency, data transfer rate, etc.
Higher Order Protocols (HLP) in effect
The CAN protocol defines the secure transmission of small data packets from point A to point B using a common communication line. The protocol does not contain flow control, addressing, does not provide message transmission of more than 8 bits, does not establish a connection, etc. The listed properties are determined by HLP, higher layer protocol. The HLP conditions are obtained and consist of seven orders
OSI model (Open Systems Interconnect Model)
CanKingdom
CANopen/CAL
DeviceNet
J1939
OSEK
SDS
HLP usually defines
. Launch parameters
. Distributing the message ID among various devices in the system
. Interpretation of the contents of data blocks
. Status of interaction in the system
Characteristics of SDS, DeviceNet and CAN Kingdom.
And the differences between CAN Kingdom and CANopen. There are currently more than 50 HLPs. The use of HLP is mandatory, otherwise you will have to invent your own HLP.
CAnKingdom
CanKingdom is supported by CanKingdom International; the full specification is available on the organization's website.
CanKingdom is commonly referred to as a CAN (Controller Area Network) higher order protocol. In reality, the most orderly protocol. The modules in the system are connected by a network, in which one of the modules is the main one (King). For example: to organize a plug & play system, the main module determines which device can be added and under what circumstances, adding only specified devices is allowed. CanKingdom provides simple unique identification of devices in the system, using the EAN/UPC identification standard, the individual device identifier is determined by the device serial number.
CanKingdom provides the developer with all the potential capabilities of CAN.
The designer is not limited by the CSMA/AMP multimaster protocol and can create virtual systems management of buses of various varieties and topologies. Provides the ability to create general modules without taking into account circumstances such as dependence on HLP and system properties. The designer can specify the use of only specific modules, thereby combining the values of an open system with the advantages of a restricted and secure system.
Because the identifier in CAN messages not only identifies the message, but also controls access to the bus, message numbering is key. Another important factor is the identity of the data structure in the data field in both the sending and receiving modules. By introducing small, simple rules, these factors are completely controlled and communications are optimized for any system. This is performed during a short installation phase during system initialization. It is also possible to include devices that do not follow CanKingdom rules into the CanKingdom system.
CanKingdom is accompanied by relevant documentation for modules and systems.
CAL and CANopen
CAL is short for "CAN Application Layer" CAN application layer or order, protocol supported by CiA. CAL is divided into several components:
. CMS (CAN-based Message Specification) defines data transfer protocols between CAN devices
. NMT (Network Management Service) defines startup and shutdown protocols, fault detection, etc.
. DBT (Distributor Service) defines a protocol for distributing identifiers of various devices in the system
- CAL protocol is different from the OSI model (Open Systems Interconnect (OSI) Model)
- CANopen is a subsection of CAL, and is organized as a set of profiles that are not finalized.
- CAL/CANopen is one of the existing HLP protocols supported by CiA.
- CAL and CANopen specifications are fully available and supported by CiA
DeviceNet
The protocol is being developed by “Rockwell Automation nowadays”, defined by the ODVA (Open DeviceNet Vendor Association). DeviceNet is one of four protocols that CiA supports.
SAE J1939
J 1939 is a high-speed Class C network communication designed to support real-time control functions between controllers that are physically located in different locations in the vehicle.
Jl708/Jl587 is the previous, widespread type of class B network with the ability to exchange simple information, including diagnostic data, between controllers. J1939 has all the properties of J1708/J1587.
J1939 uses the CAN protocol to allow any device to transmit a message over the network when the bus is not loaded. Each message includes an identifier that determines the priority of the message, information about the sender of the data, and information contained in the message. Conflicts are avoided thanks to an arbitration mechanism that is activated with the transmission of the identifier (a secure arbitration scheme is used). This allows messages with the highest priority to be transmitted with the least delay, due to equal access to the bus by any of the devices on the network.
J1939 is organized from several parts based on the (Open Systems Interconnect (OSI) Model). OSI model defines seven communication orders (layers), each representing different functions. While there is a J1939 document allocated to each layer, not all of them are explicitly defined within J1939. Other layers perform secondary functions described elsewhere. The Physical Layer describes the electrical communications interface (a twisted shielded pair of wires that can also be referred to as a bus). The Communication Channel layer describes the protocol or controls the message structure, accessing the bus, and detecting transmission errors. The application layer defines the specific data contained in each message sent over the network.
A complete set of specifications can be purchased from SAE, below is a list of documents
J1939 is supplemented by the following documents:
J1939 Practice Guidelines for Serial Transmission Control and communication network vehicle
J1939/11 Physical order (layer) - 250k bits/s, shielded twisted pair
J1939/13 Diagnostic connectors
J1939/21 Communication Layer Data
J1939/31 Network Layer
J1939/71 Application Layer
J1939/73 Diagnostics
J1939/81 Network Management
OSEK/VDX
OSEK/VDX is a joint project in the automotive industry. Created as an industry standard for open end architecture for distributed vehicle controllers. The real-time operating system, software interfaces, and network management tasks are jointly specified. OSEK" (Open systems and the corresponding interfaces for automotive electronics.) Open systems and information interfaces for automotive electronics. VDX “Whicule Distributed eXecutive" Distributed vehicle executors.
Companies jointly participating in the development: Opel, BMW, DaimlerChrysler, IIIT - University of Karlsruhe, PSA, Renault, Bosch, Siemens, Volkswagen.
Official website: www.osek-vdx.org
Smart Distributed System (SDS)
The SDS system, based on a bus for intelligent sensors and actuators, with a simplified installation process, provides extensive I/O control capabilities. Using a single four-wire SDS cable, the system can be equipped with up to 126 individually addressable devices. Additional information and specifications for SDS are available on the Honeywell developer website. SDS is one of the current four protocols supported by CiA.
Comparative characteristics of the main HLP protocols
General information
DeviceNet, SDS and CAN Kingdom are based on the ISO 11898 CAN communication protocol and operate according to the requirements of the CAN specification. Each CAN module following a specific protocol can be connected to a CAN bus following the same protocol. In any case, when connecting modules that operate using different protocols, in most cases problems arise due to a conflict in the interpretation of messages at the application level. CAN Kingdom differs from SDS and DeviceNet in a basic principle: CAN Kingdom is organized by the main communication node (“King”) at startup, unlike SDS and DeviceNet. This organization simplifies the development of a complex of real-time systems and reduces the required number of modules coordinating specifications, often referred to as profiles.
SDS is effective in connecting I/O devices, various switches and sensors to the PLC, in fact it represents the connection between the main module and remote I/O devices.
DeviceNet is an open system in which all modules have equal rights to use the bus, and the order in which the bus is used is determined by a small set of instructions. The designer of system modules can delegate communication control authority to other modules, such as the main module in a predefined Master/Slave mode, but DeviceNet does not have the ability to delegate authority to other modules. The characteristics of SDS using I/O devices and DeviceNet in Master/Slave mode are similar.
Can Kingdom protocol is focused on production, connection and control systems and does not support profiles for digital and analog devices. The main feature of the protocol is that the module connected to the system only awaits instructions from the host device. All CAN priorities and identifiers are owned and provided by the host. During startup, each module is configured by the main device, the priorities and identifiers of producing and consuming objects are determined. The primary device is the master, but only during system configuration. The master device cannot be installed during a communication session between running applications of different modules. The main device can be removed after configuration and verification of completeness, while each module stores the received instructions in memory.
The CAN controller included in the STM32 MK is a full-featured CAN node that meets the requirements for active and passive devices CAB 2.0A and 2.0B and supports data transfer at a speed of no more than 1 Mbit/s. The CAN controller is also equipped with additional capabilities for organizing deterministic data transmission using a special CAN real-time transmission protocol TTCAN. After activating the TTCAN function, automatic retransmission of messages and automatic insertion of two additional bytes into the CAN packet with a fixed moment in time of message transmission will be supported. All these capabilities are required in real-time CAN control systems.
The full name of the CAN controller is the bxCAN module, where bx indicates the module supports additional capabilities. A regular CAN module uses one receive and transmit buffer, while an advanced CAN module uses multiple receive and transmit buffers. The bxCAN module is a hybrid of two CAN module architectures. It has three mailboxes for transmitted messages and two mailboxes for received messages. Each of the hosts mailboxes has a FIFO buffer to hold three messages. This architecture is a compromise in terms of data transfer performance and occupied space on the IC chip.
The CAN module is equipped with three mailboxes for transmitting messages and has the ability to automatically insert the current time into a message using the TTCAN protocol
The next important function of the CAN controller is filtering received messages. Since CAN is a broadcast bus, every message transmitted is received by all nodes on the bus. A CAN bus of any reasonable degree of complexity carries a fairly large number of messages. The task of each CPU connected to a CAN node is to respond to CAN messages. Thus, to save the CAN controller from the problem of receiving into the buffer unwanted messages, their filtering is necessary. The STM32 microcontroller CAN controller has 14 filter banks that can be used to block all CAN messages except favorite messages or groups of messages.
14 message filters support two configurations that can be used to filter individual messages
Each filter bank consists of two 32-bit registers and can operate in one of four modes. Using basic method A message identifier is written to each filter bank register. After a message arrives, its identifier is checked and, based on this, a decision is made to accept or reject the message. This mode supports two configurations. In the first configuration, the filter bank registers are 3-bit and can be used to filter 11- and 29-bit message ID fields, as well as the RTR and IDE bits in 16-bit mode.
In the second configuration, the message identifier is written to the first 32-bit register, and the message mask is written to the second. The mask register marks the bits of the identifier register as "important" or "not important". Thanks to this, it becomes possible to receive a group of messages using one filter bank. If the receiving filters pass the message, a pointer to the filter that determined the match will be written along with it in the receiving FIFO. This will allow the application to speed up message identification without having to read and decrypt the message packet identifier.
All CAN controllers support two operating modes: normal mode for receiving and transmitting message packets and initialization mode for setting communication parameters. As already mentioned, STM32 MCUs can operate in energy-saving SLEEP mode. In this mode, bxCAN module synchronization is disabled, but access to mailbox registers remains possible. The bxCAN module has the ability to activate when activity is detected on the CAN bus. Its operation can also be reactivated by an application program. When operating in normal mode, two additional submodes are supported. The first sub-mode is SILENT mode. In it, the CAN controller can receive messages, but cannot transmit and does not generate an error bit in sending and acknowledging the message. This mode is designed for CAN buses with passive monitoring. The second submode is LOOPBACK mode. In this mode, transmitted messages are immediately received in the receive buffer. It is necessary for the implementation of diagnostic functions and is also useful during the debugging phase of the program code. Both modes discussed can be combined. They are ideal for performing self-test functions when connected to a live bus.