Depending on the message architecture, the full and extended full configurations can coexist in a single module, in order to implement high-level message priority and improve received message handling for the CPU. For example, a module receiving fail-safe information in one message (for example, ID = 0x250) and temperature sensor information in another message (such as ID = 0x3FF) may configure the CAN controller as full for the first, and extended full with four buffer FIFO for the second: CPU is interrupted when each fail-safe message is received, and once every fourth temperature sensor message is received. Figure 3 illustrates such a CAN controller configuration with a visual CAN controller customizer for fast implementation of complex message-handling schemes where all three types of CAN controllers coexist:
• Message 5--Basic CAN mailbox.
• Message 0x250--Full CAN mailbox.
• Message 0x3FF--Extended full CAN mailbox.
In addition to its functional capabilities, CAN has been widely adopted for its high fault tolerance. With bit rates up to 1 Mbps, or bus length up to 1000m (at 50 Kbps), CAN bit timing must be implemented to allow functionality in an electrically noisy environment while maintaining a high level of failure detection and correction.
To guarantee a high level of fault tolerance, sub–bit-timing configuration has been introduced with CAN to allow tighter control of determining the correct bus state for each CAN bus.
A single CAN bit is represented by four segments:
• Sync_Seg: Used to synchronize the various nodes on the bus.
• Prop_Seg: Compensates for any physical delays (propagation delay on the physical bus and the internal CAN node.
• Phase_Seg1, Phase_Seg2: Used to compensate for phase edge errors. These segments are shortened or lengthened during resynchronization.
It's also common to find CAN controllers with only three segments, where the Prop_Segtime is added to the Phase_Seg1 time.
Figure 4 shows the bit-timing representation, with all parameters necessary for its implementation.
It's important to note that all CAN bit-timing calculations are based on time quanta (TQ), defined as a fixed unit of time derived from the oscillator with a value between 8 and 25. In terms of time, a TQ is equivalent to as low as 1/25th bit or 40 ns for a 1-µs bit length at 1 Mbps bus speed.
As an overly simplified rule of CAN bit timing, the following list could be setup to govern the values of the 4-bit time segments:
• Sync_Seg = 1TQ
• 1TQ ≤ Prop_Seg ≤ 8TQ
• 1TQ ≤ Phase_Seg1 ≤ 8TQ
• 2TQ ≤ Phase_Seg2 ≤ 8TQ
• 1TQ ≤ SJW ≤ MIN(Phase_Seg1, 4)
• SJW--Synchronization jump width, defined as the time length by which Phase_Seg1 may be lengthened and Phase_Seg2 may be shortened
The above relationships generate a large range of possible values for each of the parameters they involve, and selecting the right combination is crucial to the successful implementation of a robust CAN communication. Designers must not only account for oscillator accuracy and propagation delays within the node in question, but also account for other system nodes with which communication must be established.
Based on the system clock, the baud rate required, and possibly the required sample point of the bit (in other words, the CANOpen sample point required at 87.5%), configuring the bit timing for CAN becomes a challenge many designers are reluctant to undertake. This perceived complexity is causing many new embedded systems to reuse legacy MCUs and even software stacks rather than adopting new products that might address the overall system requirements a better way. Unfortunately, it puts CAN in the "It's working; I don't want to touch it" category of embedded peripherals.
Figure 5 shows a sample bit-timing configuration for CAN, where creating new timing analysis or modifying a baud rate of an existing node configuration is no longer a risky task for an already operational CAN bus. By providing all specified and verified combinations of parameters to achieve a robust CAN timing implementation, designers can focus on the more complex tasks of the module's main functionality.
Although available for decades now, CAN is still perceived as a complex peripheral in an embedded systems design, especially in research and development area (R&D). R&D activities involve multiple iterations of the system configuration, with CAN being a component in the overall system. CAN drivers and CAN stack development can be outsourced to specialized companies providing these services for a fee, some with limited post-delivery change and configurability. Lately, semiconductor companies are providing tools to bridge that gap and allow quick in-house development that promises to speed time to market for complex embedded systems.
No comments:
Post a Comment