DESIGN OF A CUSTOM ASIC INCORPORATING CAN™ AND 1 ...

DESIGN OF A CUSTOM ASIC INCORPORATING CAN™ AND 1 ... DESIGN OF A CUSTOM ASIC INCORPORATING CAN™ AND 1 ...

acumen.lib.ua.edu
from acumen.lib.ua.edu More from this publisher
15.08.2013 Views

Whenever a new CAN node is added to the network and powered up, it should wait for a random amount of time and transmit a message with an address assignment pending status (Reserved bits = 01). The CAN Controller should start claiming addresses from zero and the message transmitted should have the highest priority CAN message ID which is stored in the Highest Priority ID register. The Address Claim Unit should monitor the CAN bus for the successful transmission of an address claim message. If there is a bus error which prevents this message from being successfully transmitted then the node should wait for a random amount of time before attempting retransmission (i.e., automatic retransmission disabled). After a successful transmission of an address claim message, the CAN node should monitor the bus for the response from other CAN nodes possibly having the same source address. If the CAN node does not receive a response within a specified amount of time, it can assume that it has successfully claimed the address. If it receives a message from another CAN node with the same source address, then the address status bits are checked. If the status bits indicate an address claim override and the newly received CAN ID has an equal or higher priority than the new CAN node, then the new node will try to claim the next available valid address. If the override/normal Tx message comes from a lower priority CAN ID, then the address claim message is retransmitted with override information so the other CAN node will release its address. The CAN node should continuously monitor the data bus to check for address claim messages and if any CAN node has the same address as its own, take appropriate action. The above procedure will result in a sequential address assignment to networked CAN nodes. For example, if there are 25 CAN nodes at the start of the first address claim 91

procedure, then the address claim process will result in addresses being assigned from zero to 24. If a new higher priority node is added to the CAN bus at a later time, all of the existing 25 CAN nodes will be bumped off to a lower priority address resulting in a complete reassignment of CAN node addresses. This problem can be avoided by reserving some addresses at regular intervals. These addresses can be claimed by the CAN nodes only if they are being bumped out of a valid address claimed status and cannot be claimed during the initial configuration [40]. The reader is referred to [40] for a complete state machine diagram of the address claim process. The last proposed method to solve the issue of bridging message ID-based and address- based protocols such as CAN and 1 – Wire® would require that the PIC® microcontroller and CAN Controller used in the prototype system be CANopen® compliant. One of the biggest challenges in developing the hardware for a CANopen® compliant node can be selecting the right part, as some 20 chip manufacturers produce microcontrollers with CANopen® compliant CAN interfaces. CANopen® is a CAN - based higher layer application protocol conceived for process control and automated manufacturing environments that, at present, is knowing widespread diffusion all over the world and, in particular, in the European countries. CANopen® requires that each device in the network be assigned a unique node address (Node – ID) before the normal operations are started. To this extent, the CANopen® specifications provide a means to remotely configure the addresses of the slave devices attached to the CAN bus. This technique, however, requires that each device has to be connected separately to a configuration tool. CANopen®, in fact, does not have a mechanism to identify, in an efficient and reliable way, the 92

procedure, then the address claim process will result in addresses being assigned from zero to 24.<br />

If a new higher priority node is added to the CAN bus at a later time, all of the existing 25<br />

CAN nodes will be bumped off to a lower priority address resulting in a complete<br />

reassignment of CAN node addresses. This problem can be avoided by reserving some<br />

addresses at regular intervals. These addresses can be claimed by the CAN nodes only if they<br />

are being bumped out of a valid address claimed status and cannot be claimed during the initial<br />

configuration [40]. The reader is referred to [40] for a complete state machine diagram of the<br />

address claim process.<br />

The last proposed method to solve the issue of bridging message ID-based and address-<br />

based protocols such as CAN and 1 – Wire® would require that the PIC® microcontroller and<br />

CAN Controller used in the prototype system be CANopen® compliant. One of the biggest<br />

challenges in developing the hardware for a CANopen® compliant node can be selecting the<br />

right part, as some 20 chip manufacturers produce microcontrollers with CANopen® compliant<br />

CAN interfaces.<br />

CANopen® is a CAN - based higher layer application protocol conceived for process<br />

control and automated manufacturing environments that, at present, is knowing widespread<br />

diffusion all over the world and, in particular, in the European countries. CANopen® requires<br />

that each device in the network be assigned a unique node address (Node – ID) before the normal<br />

operations are started. To this extent, the CANopen® specifications provide a means to remotely<br />

configure the addresses of the slave devices attached to the CAN bus. This technique,<br />

however, requires that each device has to be connected separately to a configuration tool.<br />

CANopen®, in fact, does not have a mechanism to identify, in an efficient and reliable way, the<br />

92

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!