|
Design FeaturesMarch 3, 1997 |
EDN Europe
DAVID MARSH, CONTRIBUTING TECHNICAL EDITOR
Today's Controller Area Network represents a workhorse industrial technology with huge market potential.
Controller Area Networking (CAN) has evolved from a purely automotive technology into the industrial mainstream. In 1996, CAN IC sales were almost evenly balanced be-tween automakers and general industry for the first time. Today, approximately 18 million CAN nodes are in use, with predictions of 140 million nodes by 2000.
Early CANs used stand-alone protocol converter ICs coupled to 8-bit host microprocessors (µPs). Today’s CANs increasingly use microcontrollers (µCs) with integral CAN ports. Although 8-bit architectures economically suit peripheral functions, designers need 16- and 32-bit architectures to tackle complex real-time CAN applications: automotive, medical equipment, flight recorders, robotics, gas turbines, textile-production machinery, building-automation systems, and even vending machines and toys.
CAN’s developer, Robert Bosch GmbH, strategically chose Intel to develop the first CAN silicon. Bosch’s CAN protocol licensees now include Hitachi, Motorola, National Semiconductor, NEC, Philips, Siemens, SGS-Thomson, Temic, Texas Instruments, and Toshiba. Significantly, virtually all of these semiconductor makers concentrate CAN R&D effort within Europe—and typically in Germany. Stand-alone CAN controller ICs and µCs enable you to adopt many design approaches and application targets. Stand-alone CAN controllers (see Table 1) offer flexibility in selecting the host processor; µCs with onboard CAN controllers (see Table 2) offer better speed potential through closer integration. And, finally, Table 3 reviews CANbus transceiver ICs that comply with the ISO-11898 physical-layer standard most CANbuses use.
Standards are critical to CAN’s acceptance—and future success. Building on Bosch’s original protocol suite, the "CAN in Automation" organisation (CiA), which is based in Erlangen, Germany, coordinates CAN standards development (see box, "Europe forms centre for CAN user group"). CiA has many special-interest groups that focus on development and maintenance issues. CiA is developing its own application-layer open standard, CAL, due for publication late in 1997. CiA is also developing CANopen Profiles, an open standard for industrial fieldbus systems that uses a subset of CAL communications.
To be useful in widespread applications, the low-level CAN protocol suite needs extensions. Most industrial fieldbus systems need to transmit more than the 8 data bytes the CAN protocol specifies, while developers benefit from higher layers of abstraction that shield programmers from the underlying hardware. The box, "How CAN works," summarises industry-specific application layer standards and presents the CiA’s CAL open-systems standard.
Three CAN controller options
Compliance-testing issues persuade adept logic designers to spec commodity CAN controller or µC ICs. CAN system designers exploit the protocols’ determinism to select the most economical architecture that meets their system’s hard real-time response requirements. Since Intel introduced the first CAN controller IC in 1987, vendors have released or announced more than 20 CAN controller ICs. You can classify these ICs according to three prime characteristics: stand-alone CAN controller IC or µC with integral CAN port; "BasicCAN" or "FullCAN" message-exchange implementation; and support for "Standard CAN" (2.0A) 11-bit message identifiers or "Extended CAN" (2.0B) 29-bit message identifiers.
BasicCAN and FullCAN are de facto CAN controller-IC classifications that refer to the CAN controller-IC to host-system interface. Classic BasicCAN controller ICs are CAN protocol converters that need dedicated supervisory control from a host µC. BasicCAN controller ICs have limited message identifier recognition. The µC decides whether to receive the message, communicating with the CAN controller IC through a register-based architecture.
FullCAN controller ICs have message-identifier filtering circuitry and prioritised input and output message queues that typically store 15 messages for transmission or from reception. FullCAN controllers operate largely independently of host µCs, requesting service only when necessary. The interface between a FullCAN controller and its host µC is normally a dual-port RAM block, requiring more sophisticated (and more costly) silicon area compared with a BasicCAN controller IC. The lowest cost CAN IC class comprises SLIO (serial-link input/output) devices, which suit low-level control applications.
Again in partnership with Bosch, Intel updated the ground-breaking 82526 CAN controller with the 82527 IC. Intel’s 82527 is a stand-alone CAN controller IC that conforms to the CAN 2.0B specification, accepting 11- and 29-bit message identifiers. The 82527 IC has 15 byte-wide message-object registers together with message-identifier filtering, which reduces the burden on the host µC. The 82527 IC’sµC interface suits 16-bit multiplexed buses, as well as 8-bit multiplexed and 8-bit nonmultiplexed buses. Alternatively, designers can use the SPI-compatible synchronous serial interface. The 82527 IC supports CAN operation up to 1 Mbps and provides a programmable clock output and two general-purpose 8-bit I/O ports within its 44-pin surface-mount package.
New CAN controller ICs blur the distinctions between classic BasicCAN and FullCAN controllers. Historically, Philips has been the main proponent of BasicCAN controller ICs, quoting cost and application ease as prime factors. Philips’ SJA1000 CAN controller IC is upwardly pin and software compatible with Philips’ outgoing 82C200 CAN controller IC in all but three minor software-related respects. In BasicCAN mode, the SJA1000 IC functions in CAN 2.0B "passive mode," accepting 11-bit—and tolerating 29-bit—message identifiers.
The SJA1000 IC’s clock divider register contains a switch between BasicCAN mode and what Philips calls "Peli-CAN," a CAN 2.0B-compliant mode that includes extended message-identifier filtering with 4-byte code and 4-byte mask memories. PeliCAN mode provides error-control mechanisms, a self-reception mode, a single-shot transmission option, a listen only mode, support for system bit-rate detection, and local self-test. Philips expects production quantities of the SJA1000 IC in the second quarter.
Other manufacturers offering stand-alone CAN controllers include National Semiconductor and Siemens. Siemens’ SAE 81C90/91 ICs are FullCAN controllers that comply with the CAN 2.0B passive specification. The SAE 81C90/91 ICs have configurable host-µP bus interfaces that couple best with Siemens’ C500 and C166 µCs. Siemens’ SAE 81C90/91 ICs offer stand-alone CAN controller features such as 16 message buffers, multiple transmissions with a single command, automatic eight-message timestamp, and a dedicated transmission-check unit.
In contrast, National Semiconductor’s MM57C360 IC belongs to the SLIO (serial-link input/output) device class. The MM57C360 IC is a simple I/O transceiver that provides 14 digital interface pins in its 28-pin surface-mount package. With an on-chip 125-kbps ISO 11898-type CAN physical bus interface, the MM57C360 IC suits automotive-body and industrial-relay control applications.
Hitachi plans to release the HCAN-1 stand-alone CAN controller IC in the third quarter. The HCAN-1 IC uses a CAN macrocell design that will appear on Hitachi’s H8 and SH µCs and on custom ICs. The HCAN-1 IC is a 1-Mbps FullCAN controller that complies with CAN 2.0B, providing 15 transmit/ receive buffers plus one dedicated receive buffer with its own message-acceptance filter. Under adverse circumstances,CAN controllers, depending on their internal structure, might transmit a lower priority message while a higher priority message is pending (see Reference 1).
Hitachi tackles the potential message-priority inversion problem with buffering and a sorting mechanism, which guarantees that the currenthighest priority message transmits first when the CANbus is free. The HCAN-1 IC has a glueless interface to most 8- and 16-bit hosts, and a sleep mode with intelligent wake-up. Note that the HCAN-1 package has a heatsink that extends ambient-temperature operation to +105° C.
µCs that integrate a CAN controller port provide a potential 50% speed improvement over stand-alone-µC and CAN-controller-IC combinations. In addition to sparing pc-board area, µCs with an integral CAN controller sidestep compatibility issues between µC and CAN controller ICs. Last year, Intel, Motorola, National Semiconductor, Siemens, and Temic announced 8- to 32-bit µC ICs with on-chip CAN controllers. Familiar processor-family architectures include Intel and Motorola standards such as the i8051 and MC6805.
Motorola’s 8-bit MC68HC08 CAN µC family is upwardly compatible with the four MC68HC05X family CAN µC ICs—with extensions to the register set and 78 new instructions. In cooperation with Volvo, Motorola developed the "msCAN08" CAN controller module for the MC68HC08AZ IC, with particular emphasis on predictable real-time response. Incidentally, "msCAN’’ stands for modular scalable CAN, meaning that the silicon design adapts to revised transmission/reception buffer schemes and integrates gracefully with future CAN µCs such as the MC68HC12.
The msCAN08 design complies with CAN 2.0A and CAN 2.0B, using a message filtering scheme that lets you configure one 32-bit message identifier mask, two 16-bit masks, or four 8-bit masks. To overcome the potential priority-inversion problem that simple CAN controllers exhibit, Motorola’s msCAN08 controller uses three message-transmission buffers. Initially, the MC68HC08AZ IC will be available in external-memory and 16- to 32-kbyte ROM versions, with the flash-memory-version MC68HC908 IC due in the first quarter of 1998 (sampling is scheduled for the second quarter of this year).
Siemens and Temic offer CAN µCs that derive from Intel’s 8051 8-bit architecture. Siemens’ SAE C515 µC IC combines an enhanced 8051 µP core with a CAN 2.0B-compliant controller that has 15 message memories. The SAE C515 µC IC provides a synchronous peripheral interface (SPI serial port), three 16-bit timer/counters, a four-channel capture/compare subsystem for pulse-width-modulation (PWM) control, a synchronous/asynchronous serial interface (USART), and 49 multifunction I/O pins. The IC is available in an 80-pin plastic quad flatpack (PQFP).
Temic provides two 8051-derivative CAN µCs, the TSC8051A11 and enhanced TSC80251A2. The TSC8051-A11 IC is a classic 8051 µP core derivative; the TSC80251A2 IC has an en-hanced, register-based architecture. The TSC80251A2 IC is binary compatible with the TSC8051A11 IC but performs approximately 5× faster than an 8051 due to a three-stage pipelined architecture. The TSC80251A2 IC’s µC core has an extended 16- and 32-bit instruction set that suits C language. Keil and Tasking both offer optimised ANSI-C standard compilers for the TSC80251A2 IC that produce approximately a 15 performance improvement over equivalent operations executing on 8051-µP cores. Temic estimates that the TSC80251A2 IC provides a 40% code-size saving over the 8051-derivative TSC8051A11 IC.
Real-time control applications such as engine and powertrain management demand 16- and 32-bit architectures. Currently, Intel architectures dominate 16-bit CAN µC IC designs. Now, Motorola is offering a 68000/020-based 32-bit CAN µC, the MC68376. Also, watch for announcements from Hitachi; the company plans CAN µCs based on its 16-bit H8 and 32-bit RISC SuperH designs. At the 1996 International CAN Conference, Temic proposed a 32-bit CAN µC that used a DSP core. Temic has since dropped the TSC721 device, but the concept illustrates yet another direction for CAN µC ICs. Using a DSP core in an embedded CAN µC IC opens the way to voice-activated real-time control—with safety and comfort benefits for automotive applications.
Standard 16-bit CAN µC architectures include Siemens’ 80186-based SAE C167R IC and SGS-Thomson’s similar ST10F167 IC. These µC ICs have a CAN 2.0B-compliant controller, two synchronous/asynchronous serial channels, a 16-channel 10-bit A/D converter, two 16-channel capture/compare units, and a four-channel PWM unit. Siemens’ SAE C167R IC has 32 or 128 kbytes of ROM, and a version with 128 kbytes of flash memory is sampling now (C167CR-16FM). SGS-Thomson’s ST10F167 IC integrates 128 kbytes of flash memory as standard.
Intel’s 16-bit 87C196CA and 87C-196CB CAN µC ICs combine the company’s MCS 96 µC core with the 82527 CAN controller-IC design. The MCS 96 µC core, designed for real-time control, has a register-to-register architecture that permits very fast context switching. The 16-bit MCS 96 family µCs have bit, byte, 16-bit, and some 32-bit operations. The 87C196CA and 87C196CB CAN µC ICs include MCS 96’s Event Processor Array, a dedicated I/O subsystem that performs capture-and-compare operations with 200-nsec resolution (20-MHz processor clock). Other µC features include a multichannel A/D converter, two 16-bit timer/counters, synchronous and asynchronous serial-communications ports, and general-purpose I/O pins. The 87C196CA and 87C196CB µCs differ principally in the amount of on-chip memory and in external addressing capability. CAN software for the stand-alone 82527 IC is compatible with the CAN controller that 87C196C µCs integrate.
Motorola’s 32-bit MC68376 IC uses Motorola’s "TouCAN" CAN 2.0B-compliant controller module. The TouCAN controller module features 16 configurable transmit/receive buffers, each of which accommodates up to 8 bytes of data. A 16-bit free-running timer timestamps buffer entries. Message-transmission priority logic provides a programmable "transmit first" mechanism based on the lowest value (highest priority) address identifier or the lowest physical buffer number.
The TouCAN controller module provides flexible 11- and 29-bit message acceptance filtering and communicates at network speeds up to 1 Mbps; it communicates with the MC68020 µP core via Motorola’s intermodule bus. The MC68376 IC’s intermodule bus links the µP core with peripheral subsystems, including a timer/processor unit with an independent microengine, a timer module that also provides four PWM channels, two intelligent serial I/O subsystems, and a 16-channel 10-bit A/D converter. The MC68376 IC integrates local memory blocks to support peripheral subsystem operations. Like the MC68376’s TouCAN module, the MC68376 IC’s peripheral subsystems operate largely independently of host-µP supervision.
CAN protocols do not define how to implement the CANbus physical layer. A CAN is most often a physical bus topology with up to 32 nodes, but the CAN protocols do not practically limit the number of nodes within a CAN. CAN 2.0A defines an 11-bit device identifier, or 2032 unique device addresses. CAN 2.0B provides a 29-bit device identifier, or 536,870,912 device addresses (see Reference 2). You can connect multiple CANs together or even connect a CAN with another networking system such as Ethernet. Practical CAN topologies include star-coupled and tapped bus networks for fibre-optic physical media, star-cabled topologies for awkward in-vehicle applications, and self-powering network topologies for industrial fieldbus systems (see Reference 3).
Most CANs use commodity transceiver ICs that comply with the de facto industry standard ISO-11898 CANbus physical-layer implementation (Reference 4). ISO-11898 format CANbuses use "dominant" and "recessive" transmission levels that reflect one or more nodes asserting and negating logic levels on a logical wire-OR transmission line. In an ISO-11898 CAN, the recessive signal level is VCC/2, or nominally 2.5V dc. In the recessive signal condition, both wires of a differential pair lie at the recessive 2.5V dc level.
In the dominant signal condition, the CAN_L wire approaches 0V dc while the CAN_H wire approaches VCC. Differential transceivers provide immunity to electromagnetic radiation and electrical disturbances such as ground shifts. Critically, the differential transmission scheme still works if one signal wire fails—network performance degrades gracefully in what automotive engineers term "limp home" mode.
CAN transmission speeds generally range from 125 kbps to 1 Mbps. Because CAN response speed is deterministic, you can opt for the lowest transmission speed that will meet your real-time needs. Choosing the lowest speed system might not seem natural, but important benefits include lessening electromagnetic emissions and loosening wiring and connector requirements. To suit low- and high-speed buses, CAN-transceiver-IC output driver stages have slope control—that is, controlled rise and fall times that minimise EMC concerns. CAN transceiver ICs are especially robust, withstanding automotive temperature extremes, electrical transients, and fault conditions such as shorts to battery voltage. New CAN transceiver ICs inform the network controller of local errors via an error status pin. ISO-11519 defines seven fault conditions that a CAN transceiver must tolerate and report: CAN_L or CAN_H line cut, CAN_L or CAN_H shorted to ground or to battery voltage, and CAN_L shorted to CAN_H.
Philips claims virtually 100% of the CAN IC transceiver market, with three CAN transceiver ICs (see Table 3). The 1-Mbps PCA82C251 IC is a version of Philips’ original PCA82C250 transceiver IC, with ±36V short-circuit high-voltage protection that suits the 24V dc systems used in commercial vehicles. The PCA82C251 IC drives more than 64 CANbus nodes. A node without power does not disturb the rest of the bus.
Philips’ latest family addition is the PCA82C252 IC, which drives as many as 32 nodes at up to 125 kbps. The PCA82C252 IC is designed to tolerate and report ISO-11519-type CANbus errors and to maintain communication if either CAN_L or CAN_H wires remain intact. Withstanding jumpstarts and +40V transients, the PCA82C252 IC has battery-voltage monitoring, overtemperature protection, and output-current limiting circuitry. A sleep mode reduces the PCA82C252 IC’s power consumption to less than 100 µA, waking when it receives a wake-up request over the bus or via an input pin. The PCA82C252 IC costs approximately $1.50 in volume.
Late entrants SGS-Thomson, Temic, and Texas Instruments will challenge Philips’ market share. SGS-Thomson cooperatively developed the L9615 CAN transceiver IC with Robert Bosch; both companies will market the device. The L9615 IC operates at up to 500 kbps at bus voltages from –5 to +36V. The L9615 IC includes slope control and short-circuit protection in an eight-pin SOIC package. Temic offers the Si9200 IC for ISO-11898 systems and the B10011S IC for 24V systems. The Si9200 IC operates at data rates from 1 kbps to 1 Mbps and withstands ±60V transients and bus-to-ground shorts. During abnormal conditions, the eight-pin SOIC Si9200 IC disables its transmitter, re-enabling the transmitter when fault conditions clear. Temic’s B10011S IC implements a 24V CANbus according to ISO-11992, a standard for buses and trucks. The B10011S IC drives 24V buses at up to 125 kbps, but you will need additional output filter and clamping circuitry for best results.
Texas Instruments described the SN75LBC032 CAN transceiver IC at last year’s International CAN Conference (Reference 5). The SN75LBC032 IC drives 32 nodes within ISO-11898 networks and incorporates ISO-11519 bus-error-management features. Current- limiting shutdown circuitry disconnects the bus drivers in the event of shorts to ground or battery voltage, or between CAN_L and CAN_H wires. A battery voltage monitor signals the system when power is applied for the first time, so that devices such as automatic-window winding mechanisms can calibrate their limit stops.
Combinational states on the Enable and Strobe inputs determine the SN75LBC032 IC’s operating mode. In standby mode, power consumption reduces to less than 200 µA. In sleep mode, internally shutting off VCC reduces power consumption below 50 µA at the expense of taking longer to wake up than from standby mode. In either case, the SN75LBC032 IC awakens when it senses activity on Wake-up or Strobe inputs or a dominant signal on the bus for at least 35 µsec. A combination of logic lows on the Error and RX pins informs the host CAN controller that the SN75LBC032 IC is on-line.
| Table 1—Representative stand-alone CANbus controller ICs | ||||||||||||||
| Manufacturer | CAN µC IC | CAN revision |
Onboard µC |
Clock freq (MHz) |
On-chip memory | External addressing |
I/O lines (max) |
Serial comms |
ADC resolution (bits) |
Channels | Timer/ counters |
Comments | Packaging | |
| Program (kbytes) |
Data | |||||||||||||
| Intel | 87C196CA | 2.0B, Full | 16-bit | 16, 20 | 32/OTP | 1 kbyte + 256 bytes | None | 38 | UART, SPI | 8/10 | 6 | 2 | Event processor array | 68-pin PLCC |
| 87C196CB | 2.0B, Full | 16-bit | 16, 20 | 56/OTP | 1.5 kbytes+512 bytes | 1 Mbyte | 56 | UART, SPI | 8/10 | 8 | 2 | Event processor array | -pin PLCC/ 100-pin PQFP | |
| ITT Intermetall | CCU 3010E | 2.0B, Full | 8-bit | 8 | 32/flash | 1.25 kbytes | None | 54 | 2× UARTs, SSS | 10 | 9 | 3 | 4×16-bit capture/ compare timers, PWA | 100-pin PQFP |
| Motorola | 68HC05X series |
2.0A, Basic | 8-bit | 4 | 4 to 32/ROM | 176 to 528 bytes | None | 16 or 32 | SCI | 8 | 8 | 4 | PWM, X16/32 has 255-byte EEPROM | 28-pin SOIC/ 64-pin QFP |
| 68HC08AZ series |
2.0B, Full | 8-bit CPU08 | 8 | 0 to 60/ROM | 512 to 2 kbytes | Up to 64 kbytes | SPI, SCI | 8 | 7 | Flash-memory version planned | 64-pin QFP/ 100-pin TQFP | |||
| 68376 | 2.0B, Full | 32-bit CPU32 | 20.97 | External | 4 kbytes+3.5k TPU RAM | 256k to 8 Mbytes | 18 | UART, SPI | 10 | 16 | 2 modules | Bus interface module (scheduled Q3) | 160-pin PQFP | |
| National Semiconductor | COP884BC | 2.0B passive | 8-bit | 10 | 2/ROM or OTP | 64 bytes | None | 18 | SPI | None | None | 1 | PWM controller | 28-pin SOIC |
| COP888EB | 2.0B passive | 8-bit | 10 | 8/ROM or OTP | 192 bytes | None | 58 | UART, SPI | 8 | 8 | 2 | Watchdog, clock monitor | 44-/68-pin PLCC | |
| Philips Semiconductor | XA-D3 | 2.0B, Full | 16-bit | 25 | 32/ROM or OTP | 1 kbytes | 1 Mbyte | 30 | UART | None | Not applicable | 3 | Watchdog, low-voltage detection (Q3) | 44-pin PLCC/ PQFP |
| SGS-Thomson Microelectronics | ST10F167 | 2.0B, Full | 16-bit | 20 | 128/flash | 4 kbytes | 64k to 16 Mbytes | 111 | USART, SPI | 10 bits | 16 | 2 modules | 4-channel PWM controller | 144-pin PQFP |
| ST7 family core | 2.0B passive | 8-bit | 4 | 32/ROM or EPROM | 1kbytes | Not specified | 32 | SPI | 8 bits | Not specified | 2 | Watchdog, 8-bit PWM controller (Q4) | ||
| Siemens | C167CR | 2.0B, Full | 16-bit | 20, 25 | 32 or 128/ROM | 4 kbytes | 64k to 16 Mbytes | 111 | USART, SPI | 10 bits | 16 | 2 modules | 4-channel PWM controller | 144-pin MQFP |
| C515C | 2.0B, Full | 8-bit | 10 | 64/ROM | 256 bytes+2 kbytes | 64 kbytes | 49 | USART | 10 bits | 8 | 3 | PWM capture/compare unit | 80-pin MQFP | |
| Temic | TSC8051A11 | 2.0B passive | 8-bit | 18 | 8 to 32/ROM or OTP | 512 bytes | 64 kbytes max | 13 | UART, SPI | 8 bits | 8 | 2 | 5-channel event/ waveform unit | 52-pin PQFP/ PLCC |
| TSC80251A2 | 2.0B, Full | 8-bit | 16 | 64/ROM or OTP | 4 kbytes | 16 Mbytes | 56 | UART, SPI | 10 bits | 8 | 3 | 8-channel PWM capture/compare (Q1/98) | 64-pin PQFP | |
| Texas Instruments | TMS-370C08D65 | 2.0B, Full | 8-bit | 5 | 4/ROM or 16/EPROM | 1 kbytes | Not specified | 33 | I2C, SCI, SPI | 8 bits | 8 | 2 | Watchdog, 3 external interrupts (Q4) | Not specified |
| Table 2—Representative CANbus µCs | ||||||||
| Manufacturer | Stand-alone CAN controller IC |
CAN revision | CAN object storage |
µP bus structure | CANbus speed | Uncommitted I/O pins |
Comments | Package |
| Hitachi | HCAN-1 | 2.0B, Full | 15 RX/TX buffers 1 RX buffer & mask |
8- or 16-bit nonmultiplexed |
(programmable) 1 Mbps |
None | Sleep mode (Q3) | 80-pin HQFP |
| Intel | i82527 | 2.0B, Full | 14 RX/TX buffers 1 RX buffer & mask |
8-bit nonmultiplexed, 8/16-bit multiplexed, & SPI serial interface |
(programmable) 1 Mbps |
16 | Sleep modes, comparator, programmable clock output | 44-pin PLCC 44-pin QFP |
| National Semiconductor | MM57C360 | 2.0B passive | 2 RX/TX buffers | None (SLIO device) | 125 kbps to 1 Mbps | 10 I/O; 4 O | 125-kbps CANbus PHY, | 28-pin SOIC |
| MM57C362 | 2.0B passive | 2 RX/TX buffers | None (SLIO device) | 125 kbps to 1 Mbps | 6 I/O | ADC & DAC | 20-pin SOIC | |
| Philips Semiconductors | 82C200 | 2.0A | 2 RX, 1 TX buffer | 8-bit multiplexed | (programmable) 1 Mbps |
None | Use SJA1000 for new designs | 28-pin SOIC/DIL |
| SJA1000 | 2.0B, Full | 3 RX, 1 TX buffer | 8-bit multiplexed | (programmable) 1 Mbps |
None | 82C200 compatibility mode (available Q2) | 28-pin SOIC/DIL | |
| Siemens | SAE 81C90 | 2.0B passive | 16 RX/TX buffers | 8-bit multiplexed & synchronous serial | (programmable) 1 Mbps |
2×8-bit ports | CAN 2.0A mode | 44-pin PLCC |
| SAE 81C91 | 2.0B passive | 16 RX/TX buffers | (programmable) 1 Mbps |
None | CAN 2.0A mode | 28-pin PLCC | ||
| Europe forms centre for CAN user group |
| “CAN in Automation” (CiA) is a European initiative with worldwide aspirations. Based in Erlangen, Germany, CiA coordinates and promotes every aspect of CAN technology, from producing CAN product guides to overseeing CAN standards development. CiA produces a CAN newsletter, which supplies information on CAN protocol developments, CAN development tools, and new CAN-related products. CiA also publishes the proceedings from the CiA’s annual conference, with sessions that focus on every area of CAN technology.Holger Zeltwanger, CiA’s director of the manufacturers and users group, summarises CiA’s development: “I formed the CiA international users and manufacturers group in January 1992. Two months later, eight companies officially founded the nonprofit CiA Trade Association. Currently, the Association has approximately 250 member companies. CiA provides technical, product, and marketing intelligence—information that enhances the prestige, improves continuity, and provides a development path for CAN technology.”Zeltwanger continues, “The CAN community is continually growing. The total number of installed CAN nodes now stands at more than 15 million, and another 10 million CAN nodes will be installed in 1997 alone. Most European car makers will be using CANs in engine management, and some will use low-speed CANs for car-body electronics. There is also talk of new applications, such as linking and controlling audio/video equipment with CANs.“Even low-volume applications help boost CAN’s image. A scenario for the near future is a world in which everyone makes use of CANs everyday, even if not everyone is aware of it. CAN in theatres, CAN in public transport, CAN in cars, and CAN in domestic appliances will be commonplace. This is a vision of a future that could be just around the corner.“CiA has technical and business committees that develop the general aims and discuss the results of CiA working groups and special-interest groups before endorsement by the CiA general assembly. CiA developed the CAN Application Layer specification, as well as the CANopen Profile family. CiA also supports the CAN-based higher layer protocols CAN Kingdom, DeviceNet, and Smart Distributed System.“CiA organises regional and national CAN forums, international application-specific workshops, and, since 1994, the International CAN Conference. The 4th International CAN Conference will take place in October in Berlin. In addition, CiA has plans for CAN roadshows in France and the USA, as well as CiA’s Swiss CAN Days events.” |
| How CAN works |
| CAN’s
automotive inheritance provides some unusual
characteristics that specially suit industrial-automation
applications. The CAN protocols arbitrate for bus access
using a Carrier Sense Multiple Access/Collision Avoidance
(CSMA/CA) technique that guarantees real-time response.
CANbus devices (nodes) communicate directly with other
nodes, rather than communicating via a master/slave
relationship that consumes unnecessary network bandwidth.
The CAN protocols also support broadcast transmissions.
Synchronising real-time processes is easy—CAN nodes
receive messages simultaneously. Nodes on a CANbus arbitrate for bus access by waiting for the network to become idle then transmitting a unique device identifier. The device identifier defines the node’s priority relative to all other nodes on the CAN. CANbus transceivers monitor the bus while they are transmitting. A node with higher priority transmits more dominant levels on the bus than a lower priority node. When the lower priority node recognises that the device identifier it is transmitting differs from the data that it reads back from the bus, the lower priority node relinquishes its attempt at bus access until the bus is idle again. CAN’s bus arbitration scheme allows a higher priority transmission to complete in competition with lower priority requests (the data is not "wasted" due to bus conflicts or collisions). With 100-bit average transmission packet sizes, message latencies lie in the sub-msec to 1-sec region for 250 kbps—1-Mbps CANbus systems.
The bit-coding technique CAN uses is binary nonreturn-to-zero (NRZ). Because successive runs of the same logic level cause dc offsets on the transmission line, CAN’s bit-stuffing rule inserts an opposite-polarity pulse following five same-polarity logic-level pulses. CAN transceivers check data for compliance with the bit-stuffing rule and transmit error signals for noncompliance. The size of the data packet (and transmission time) depends slightly on data values as well as the number of data bytes. Speed and reliability CANbus transmission speed depends on network length and bus transceiver response times. The signal must propagate throughout the network and settle, so that each CAN node can arbitrate for network access on each bus cycle. Most CANs use twisted pair cable that has a nominal impedance of 120 ohms and a propagation velocity approximately 0.65× the speed of light. IC CAN transceivers have typical propagation delays of 25 nsec. CANs provide 1-Mbps performance for up to 40m, falling to 40 kbps for a network 1 km long. CAN’s predictable transmission delivery allows the lowest transmission speed the application will tolerate, thus reducing electromagnetic emissions, hardware specifications, and cost. CAN 2.0’s protocol specification shows that the likelihood of a transmission error going undetected is less than the transmission error rate×4.7×10-11. In reliability terms, undetected CAN transmission errors are statistically unlikely within a vehicle’s lifetime. The likelihood of a CAN transmission error going undetected in a car’s antilock brake system is approximately one instance per 1000 years. CAN application interfaces
Simple applications can take advantage of the CAN protocol suite, often via a proprietary or application-specific low-level language that communicates with the underlying network hardware. But to provide a secure and economic development base, software developers need the highest level layer that the ISO/OSI model describes—layer 7, the "application layer." The application layer provides a standard interface for end-user applications to access network services. Because CAN nodes communicate directly with other CAN nodes on the same physical network, the ISO/OSI model’s intermediate function layers are redundant. Six application-layer standards compete for applications in today’s CANs:
CAN challenges Layer 7 lead Most CAN application-layer standards arise from specific industrial or automotive needs. One of the aims in forming the CiA manufacturers and users group was to produce a true open standard, application-independent, application-layer CAN protocol extension. Open standards encourage widespread support, providing developers with royalty-free protocols that benefit from formal development and maintenance. The CiA’s CAN Application Layer standard (CAL) originates from work at Philips Medical Systems. CiA published the first CAL specification in 1993, first revised in February 1996 in version 1.1 (Reference 1). CAL already has more than 200 users spread across industrial sectors; all indications suggest that CAL will predominate as the CAN application-layer standard of choice. CiA has also specified the CANopen "Profiles" standard that employs a subset of the CAL open systems application layer to target industrial fieldbus applications. CANopen builds on the automotive ISO 11898 physical network layer standard, capitalising on volume CAN transceiver ICs. CANopen Profiles defines standards for software modules that focus on specific, but common, industrial applications. Application-layer interfaces provide additional network services as well as standard application-programming interfaces. The CAN Application Layer specification extends link- and network-layer services that the CAN protocols provide to add four application-layer services: CAN message specification (CMS), network management (NMT), identifier distribution (DBT), and layer management (LMT). CAL’s CMS message-specification service is a language for communicating between CAN devices. CMS defines three classes of data communication "objects": Variable, Event, and Domain. CMS also defines various data types such as floating-point number, void, and string, as well as their data-encoding rules. CMS Variable and CMS Event objects support 8-byte data transmissions without any additional protocol overhead. Unlike CAN’s normal multimaster (peer-to-peer) network structure, CMS Variable and CMS Event objects model master/slave (client/server) relationships between responding CAN nodes. CMS Variable objects let CAN nodes read and write data to corresponding nodes on the network, while CMS Event objects signals events from one node to receiving nodes. Some CAN fieldbus implementations employ application-specific protocol extensions to transmit arbitrary-length data streams, rather than the CAN protocol’s single 0- to 8-byte data packet. The CMS Domain object provides a standard mechanism for transmitting arbitrary-length data streams that comprise multiple CAN message frames. The first CMS Domain message frame signals that it is a CMS object with four bytes of domain download information, then four bytes of user data. Subsequent communications to the same CAN node identifier carry one byte of domain download information (protocol overhead) followed by seven bytes of user data. The last CMS Domain frame carries an end-of-transmission signal. Because the CMS Domain service relinquishes the bus between each data transfer, higher priority CAN nodes can arbitrate and acquire the bus as normal. The CMS Domain service breaks and resumes as higher priority processes compete, so long data streams must tolerate variable delivery timing. The DBT identifier distribution service is central to CAL’s open-systems strategy. To allow modules from different suppliers to coexist and cooperate on a CAN, each node’s identifier must be unique and recognised throughout the network. The DBT service relies on a master/slave structure, where one station is the DBT master and all other nodes are DBT slaves. Depending on the hardware resources that individual nodes offer, a node might need configuration once (on installation) or every time that the network powers-up (dynamic identifier distribution). CAL’s NMT network-management service provides facilities to manage distributed applications across the CAN. Like the DBT service, efficient implementation dictates that one CAN node assumes the NMT master-station role while all other nodes are slaves with respect to NMT network management. The NMT master station recognises, initiates, and controls other CAN nodes and lets them communicate using the CMS message service. LMT is CAL’s network-layer management service. Like the DBT and NMT services, the LMT service employs one master station to set all other CAN nodes’ physical-layer network parameters, like the node’s identification number and the network’s baud rate. Like the DBT and NMT services, LMT is transparent to end-user application programs. Typically, the network configures once at power-up, and application programs assume control from that time.
|
| Table 3—Representative CANbus transceiver ICs | ||||
| Manufacturer | CANbus transceiver IC |
CANbus speed (max) |
Comments | Packaging |
| Philips Semiconductors | PCA82C250 | 1 Mbps | Original bus i/f circuit | 8-pin SOIC/DIL |
| PCA82C251 | 1 Mbps | ±36V dc protection | 8-pin SOIC/DIL | |
| PCA82C252 | 125 kbps | Highly fault tolerant | 14-pin SOIC | |
| SGS-Thomson Microelectronics | L9615 | 500 kbps | –5V to +36V bus voltage | 8-pin SOIC |
| Temic | Si 9200 | 1 Mbps | ±60V transient protection (Q4) | 8-pin SOIC |
| B10011S | 250 kbps | Suits 24V dc systems (Q4) | 16-pin SOIC | |
| Texas Instruments | SN75LBC032 | 125 kbps | ISO 11519 error reporting (Q4) | 14-pin SOIC |
| For more information… | |||
| When you contact any of the following manufacturers directly, please let them know you read about their products on EDN's website. | |||
| CAN in Automation (CiA) Erlangen, Germany +49 91 31 601091 E-mail: headquarters@can-cia.de WWW: http: www.can-cia.de |
Hitachi Maidenhead, UK +44 1628 585131 |
Intel Swindon, UK +44 1793 404900 |
ITT Intermetall Freiburg, Germany +49 76 1517 2810 |
| Motorola UK Response Centre Fax +44 1354 688248 |
National Semiconductor Fürstenfeldbruck, Germany +49 180 532 7832 |
Philips Semiconductors Eindhoven, The Netherlands +31 40 278 3749 |
SGS-Thomson Microelectronics Munich, Germany +49 89 4144 8065 |
| Siemens Munich, Germany +49 89 4144 4721 |
Temic Heilbronn, Germany +49 71 31670 |
Texas Instruments Paris, France +33 1 30 70 11 65 |
|
You can reach Contributing Technical Editor David Marsh via Internet at 101453.2302@compuserve.com.
| EDN Access | Feedback | Subscribe to EDN | Table of Contents |
