Higher-layer protocols

10 May

Higher-layer protocols: So far we have only talked about the lower-layer details of CAN. For CAN to be used in any complex applications, it is necessary to work with one of a number of higher- layer protocol details such as:

•  Message ID assignment
•  Network management
•  Message ID meaning
•  Method of exchanging data (assigning meaning to data)

While we won’t go into any detail on higher-layer protocols, as the TINI API does not implement any, there are a few popular protocols based on CAN, listed in Table 12-2.

How TINI Does CAN
The TINI hardware and TINI API effectively implement CAN 2.0B. In fact the TINI CPU, the 80C390, has two on-board CAN controllers, allowing the possibility for TINI to be used on two separate CAN networks or as a smart bridge connecting two CAN networks.

First we will look at how the TINI CPU supports CAN, and then we will discuss the necessary hardware to support CAN on the TINI stick. We’ll examine the TINI API and the CAN classes before we end this chapter with a few examples.

80C390 CAN controllers
The DS80C3903 microcontroller incorporates two CAN controllers that are compliant with the CAN 2.0B specification. These CAN controllers support both 11-bit standard or 29-bit extended message identifiers and support 15 message centers for each controller. Global controls and status registers in each CAN unit allow the microcontroller to evaluate error messages, generate interrupts, locate and validate new data, establish the CAN Bus timing, establish identification mask bits, and verify the source of individual messages. The specifics of the CAN controller are discussed in the DS80C390 datasheet and the DS80C390 User’s Guide Supplement4.

Random Posts

Comments are closed.