本文介绍了TTCAN评估芯片，它是时间触发CAN设备，采用LQFP44封装，功能与博世TTCAN IP模块相同。该芯片支持CAN协议2.0 A、B部分及TTCAN，比特率达1 MBit/s，有32个消息对象等。还提到了开发套件及获取应用笔记和代码示例的方式。
TTCAN definition
The TTCAN (time-triggered communication on CAN) protocol is a higher layer protocol on top of the CAN (Controller Area Network) data link layer as specified in ISO 11898-1. It may use standardized CAN physical layers such as specified in ISO 11898-2 (high-speed transceiver) or in ISO 11898-3 (fault-tolerant low-speed transceiver).
Time-triggered communication means that activities are triggered by the elapsing of time segments. In a time-triggered communication system all points of time of message transmission are defined during the development of a system. A time-triggered communication system is ideal for applications in which the data traffic is of a periodic nature.
TTCAN benefits
TTCAN provides mechanisms to schedule CAN messages in a time-triggered way as well as in an event-triggered way. This allows using CAN-based networks for closed-loop control. Also the real-time performance in CAN-based in-vehicle networks increases with the use of TTCAN.
In vehicles data traffic must usually be both event-triggered (e.g. a temperature change in the cooling mechanism) and time-triggered (e.g. the status of the brakes). In order not to have to develop two different network systems the ISO defined the TTCAN protocol.
Basic TTCAN functionality
The TTCAN protocol is realized in software in a higher layer on top of CAN. This is why in a TTCAN network messages can be transmitted both event-triggered as well as time-triggered. The transmitted frames do not need any additional overhead in the CAN frame. The time-triggered control and thus the synchronization of the involved control units within the network is done via a reference message. All participants of the TTCAN network identify the reference message by its identifier. As soon as the first bit of the frame, the Start of Frame, is recognized, the local time unit is synchronized. The accuracy of the local time units depend only on the physical signal propagation of the bus line and is thus neglectable. The individual TTCAN participants are configured to know when to send their frames after having received the reference frame.
The time between two reference frames is called the basic cycle. Basic cycles are not always identical in order to be able to transmit messages at different periodic frequencies. The system matrix comprises several basic cycles and is repeated indefinitely until the vehicle is turned off.
For some applications it is necessary that the reference frame is sent corresponding to an event. For these cases a bit is inserted in the basic cycle, which discontinues the periodic transmission of messages until the event has taken place. This is done e.g. to synchronize communication and motor rotation.
Within a basic cycle there are exclusive windows, during which only one node may send a frame. Apart from that there are free windows and arbitrating windows, for which the nodes compete for bus access just as in the regular CAN communication. Several arbitrating windows can be merged (merged windows). The end of an arbitrating window is always predictable. Thus the advantages of event-triggered communication can be combined with those of time-triggered communication.
This is especially interesting for off-highway vehicles such as forestry vehicles or forklifts.
These vehicles often use the higher-layer protocol CANopen. Therefore there are intentions of implementing TTCAN-specific objects in the CANopen standard. Also a specific TTCAN transmit mode for process data objects (PDO) is planned. CANopen networks are also used for separate vehicle add-ons such as firefighting equipment, cranes and add-on devices for municipal vehicles.
The sending of CAN frames in TTCAN (level 1) between two reference frames is triggered by the local time units. Since there may be minimum time differences despite the initial synchronization, a system designer may implement a level 2 TTCAN network. In level 2 TTCAN a reference frame includes a time-stamp (Master_Ref_Mark). This means that after at least two times receiving of the reference frame the nodes can resynchronize according to the time-stamp. Thus a synchronization accuracy of 1 µs is achievable. This should suffice even for high requirements of vehicle builders.
Should the sender of the reference frame fail, another node automatically takes over the task of sending it. Up to eight potential time givers are installable. In case a higher-ranking time master has been replaced by a lower ranking time master but returns to the network, it automatically tries to become time master again. The TTCAN specifications provide the procedure of the return/take over of a time master.
If the time stamp is provided by an external clock (e.g. GPS), the time is given as part of a second. An internal time base in regular operation depends of the baud-rate of the CAN network. With an external time base even several TTCAN networks of other systems may be synchronized with a TTCAN network.
The TTCAN protocol also defines an error status machine as well as several error modes. The corresponding ISO standard draft also defines all "visible" interfaces. Scheduling tables are locally implemented in every node and must be configured before system start-up.
TTCAN implementations
After the ISO had submitted their TTCAN standard proposal for international standardization the first few manufacturers started implementing the TTCAN protocol. Bosch had already implemented it in an FPGA successfully and presented it at a TTCAN workshop of the CAN in Automation (CiA) international users and manufacturers group. Due to market responses Bosch has by now implemented the TTCAN module in a chip. The TTCAN stand-alone chip with integrated TTCAN level 1 and level 2 (with time correction) is pin-compatible to the company's CAN controller CC170 and Intel's 82527. It is available for the evaluation of TTCAN interfaces and for the development of TTCAN-compatible control units and software tools (e.g. bus analyzers and configurators). The controller provides different interfaces to host controllers by Intel and Motorola. Samples have been available since July 2003.
Basically all CAN controllers that support single-shot mode or are able to support the cancellation of a transmission request are able to support level 1 of TTCAN in software. For level 2 they additionally require the ability to time-stamp the Start of Frame-bit and send the time-stamp within the very same frame. For reasons of performance enhancement it makes sense to realize the protocol functions in hardware.
First CAN controllers with partial TTCAN support have been announced by Atmel. The 8-bit T89C51CC01/2 provides 15 message objects that are adjustable via filter masks. The message objects may optionally be transformed to a FIFO, which prevents the erasure of received but not yet processed data.
The NEC CAN micro-controller family has provided the hardware requirements for TTCAN since the mid-nineties with the patented SOF-synchronization, which is necessary to implement TTCAN. The company is still working on a hardware version of a standalone TTCAN module.
Hitachi has implemented the protocol in a chip, which is being tested by an independent institute for conformity to the standard.
CiA members are currently working on extending the CANopen standard in order to enable the usage of TTCAN hardware within CANopen networks. This entails the definition of a further transmission mode for PDOs and a new communication object (TREF). The CANopen extensions are due for publication with the official release of the TTCAN standard.
The TTCAN (time-triggered communication on CAN) protocol is a higher layer protocol on top of the CAN (Controller Area Network) data link layer as specified in ISO 11898-1. It may use standardized CAN physical layers such as specified in ISO 11898-2 (high-speed transceiver) or in ISO 11898-3 (fault-tolerant low-speed transceiver).
Time-triggered communication means that activities are triggered by the elapsing of time segments. In a time-triggered communication system all points of time of message transmission are defined during the development of a system. A time-triggered communication system is ideal for applications in which the data traffic is of a periodic nature.
TTCAN benefits
TTCAN provides mechanisms to schedule CAN messages in a time-triggered way as well as in an event-triggered way. This allows using CAN-based networks for closed-loop control. Also the real-time performance in CAN-based in-vehicle networks increases with the use of TTCAN.
In vehicles data traffic must usually be both event-triggered (e.g. a temperature change in the cooling mechanism) and time-triggered (e.g. the status of the brakes). In order not to have to develop two different network systems the ISO defined the TTCAN protocol.
Basic TTCAN functionality
The TTCAN protocol is realized in software in a higher layer on top of CAN. This is why in a TTCAN network messages can be transmitted both event-triggered as well as time-triggered. The transmitted frames do not need any additional overhead in the CAN frame. The time-triggered control and thus the synchronization of the involved control units within the network is done via a reference message. All participants of the TTCAN network identify the reference message by its identifier. As soon as the first bit of the frame, the Start of Frame, is recognized, the local time unit is synchronized. The accuracy of the local time units depend only on the physical signal propagation of the bus line and is thus neglectable. The individual TTCAN participants are configured to know when to send their frames after having received the reference frame.
The time between two reference frames is called the basic cycle. Basic cycles are not always identical in order to be able to transmit messages at different periodic frequencies. The system matrix comprises several basic cycles and is repeated indefinitely until the vehicle is turned off.
For some applications it is necessary that the reference frame is sent corresponding to an event. For these cases a bit is inserted in the basic cycle, which discontinues the periodic transmission of messages until the event has taken place. This is done e.g. to synchronize communication and motor rotation.
Within a basic cycle there are exclusive windows, during which only one node may send a frame. Apart from that there are free windows and arbitrating windows, for which the nodes compete for bus access just as in the regular CAN communication. Several arbitrating windows can be merged (merged windows). The end of an arbitrating window is always predictable. Thus the advantages of event-triggered communication can be combined with those of time-triggered communication.
This is especially interesting for off-highway vehicles such as forestry vehicles or forklifts.
These vehicles often use the higher-layer protocol CANopen. Therefore there are intentions of implementing TTCAN-specific objects in the CANopen standard. Also a specific TTCAN transmit mode for process data objects (PDO) is planned. CANopen networks are also used for separate vehicle add-ons such as firefighting equipment, cranes and add-on devices for municipal vehicles.
The sending of CAN frames in TTCAN (level 1) between two reference frames is triggered by the local time units. Since there may be minimum time differences despite the initial synchronization, a system designer may implement a level 2 TTCAN network. In level 2 TTCAN a reference frame includes a time-stamp (Master_Ref_Mark). This means that after at least two times receiving of the reference frame the nodes can resynchronize according to the time-stamp. Thus a synchronization accuracy of 1 µs is achievable. This should suffice even for high requirements of vehicle builders.
Should the sender of the reference frame fail, another node automatically takes over the task of sending it. Up to eight potential time givers are installable. In case a higher-ranking time master has been replaced by a lower ranking time master but returns to the network, it automatically tries to become time master again. The TTCAN specifications provide the procedure of the return/take over of a time master.
If the time stamp is provided by an external clock (e.g. GPS), the time is given as part of a second. An internal time base in regular operation depends of the baud-rate of the CAN network. With an external time base even several TTCAN networks of other systems may be synchronized with a TTCAN network.
The TTCAN protocol also defines an error status machine as well as several error modes. The corresponding ISO standard draft also defines all "visible" interfaces. Scheduling tables are locally implemented in every node and must be configured before system start-up.
TTCAN implementations
After the ISO had submitted their TTCAN standard proposal for international standardization the first few manufacturers started implementing the TTCAN protocol. Bosch had already implemented it in an FPGA successfully and presented it at a TTCAN workshop of the CAN in Automation (CiA) international users and manufacturers group. Due to market responses Bosch has by now implemented the TTCAN module in a chip. The TTCAN stand-alone chip with integrated TTCAN level 1 and level 2 (with time correction) is pin-compatible to the company's CAN controller CC170 and Intel's 82527. It is available for the evaluation of TTCAN interfaces and for the development of TTCAN-compatible control units and software tools (e.g. bus analyzers and configurators). The controller provides different interfaces to host controllers by Intel and Motorola. Samples have been available since July 2003.
Basically all CAN controllers that support single-shot mode or are able to support the cancellation of a transmission request are able to support level 1 of TTCAN in software. For level 2 they additionally require the ability to time-stamp the Start of Frame-bit and send the time-stamp within the very same frame. For reasons of performance enhancement it makes sense to realize the protocol functions in hardware.
First CAN controllers with partial TTCAN support have been announced by Atmel. The 8-bit T89C51CC01/2 provides 15 message objects that are adjustable via filter masks. The message objects may optionally be transformed to a FIFO, which prevents the erasure of received but not yet processed data.
The NEC CAN micro-controller family has provided the hardware requirements for TTCAN since the mid-nineties with the patented SOF-synchronization, which is necessary to implement TTCAN. The company is still working on a hardware version of a standalone TTCAN module.
Hitachi has implemented the protocol in a chip, which is being tested by an independent institute for conformity to the standard.
CiA members are currently working on extending the CANopen standard in order to enable the usage of TTCAN hardware within CANopen networks. This entails the definition of a further transmission mode for PDOs and a new communication object (TREF). The CANopen extensions are due for publication with the official release of the TTCAN standard.
TTCANTTCAN is an extension for CAN which is being standardized currently. TTCAN is compatible to the greatest possible extent to the well-known CAN standard and offers additional options for event timing. Within a master-slave system, messages can be sent with a defined timing and the control units can be synchronized individually.To reach a higher reliability, several backup masters can perform the master function in an emergency. The data communication can also take place synchronized with external events. Existing Vector products such as CANalyzer and CANoe can easily be used for the observation of TTCAN networks. Sending requires an individually adapted hardware. Vector develops both hardware and specialized software adapted for TTCAN with additional analysis functions. |  |
TTCAN Evaluation Chip
The TTCAN evaluation chip is a Time Triggered CAN device. It comes in a LQFP44 package. The TTCAN functionality is identical to that of the BOSCH TTCAN IP module. For details see TTCAN IP Module. The TTCAN testchip is available in packages of 5 pieces at a price of 600 Euro per package. Note: The TTCAN testchip is delivered as unqualified sample. It is intended for evaluation purposes only.
Features- Supports CAN Protocol Version 2.0 Part A, B and TTCAN (ISO 11898-4)
- Bitrates up to 1 MBit/s
- 32 Message Objects, each Message Object has its own Identifier Mask
- Programmable FIFO mode for Message Objects
- TTCAN protocol level 1 and level 2 completely in hardware
- Event synchronized time triggered communication supported
- Maskable interrupt
- Programmable loop-back mode for self-test operation
- LQFP44 package
- Interfaces: 8-bit and 16-bit parallel, 8-bit and 16-bit multiplex
The Rapid Development Kit TTCAN Expansion Board KPCM-984 is available from PHYTEC. For more information please contact PHYTEC. For TTCAN application notes and C-Code examples please use the contact Form sheet under "Contact".
扫一扫
1253
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
