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 ...
1 – Wire® Devices Type # Table 6.3 FILHITx Bit Definitions. FILHIT2 FILHIT1 FILHIT0 Description 0 0 0 Perform A/D conversion on AN1. 0 0 1 Read Digital Input pins. 0 1 0 Write Value to Digital Output 1. 0 1 1 Write Value to Digital Output 2. 1 0 0 Change Node Address. 1 0 1 Turn off Digital Outputs 1 and 2. 1 1 1 Not Used # of CAN Nodes # of Receiving CAN Nodes Table 6.4 Test Results. CAN Bus Speed (kbps) 203 1 – Wire® Bus Speed (kbps) Hot- Swapped (1 – Wire®) Length of Test (min) Failures DS1996 3 2 1 10 14 Yes 60 No DS1996 3 2 2 10 14 Yes 60 Yes 2 DS1996 3 2 1 10 140 Yes 18 Yes 1 DS1996 3 2 2 10 140 Yes 11 Yes 1 DS1996 3 2 1 125 14 Yes 60 No DS1996 3 2 2 125 14 Yes 60 Yes 2 DS1996 3 2 1 125 140 Yes 14 Yes 1 DS1996 3 2 2 125 140 Yes 24 Yes 1 1 This failure resulted in loss of messages to the 1 – Wire® devices from the CAN bus. 2 This failure resulted in loss of messages to the 1 – Wire® devices, but did not require a hard reset. From Table 6.4, lost CAN bus messages are noted in all cases where running the 1 – Wire® bus in overdrive speed. As was the case with the test performed in Section 6.2.1.2, debugging the system found that if a CAN bus message came in while running the 1 – Wire® bus in overdrive and the 1 – Wire® devices were not all operating in overdrive speed yet, the present CAN bus message got dropped. Although, technically this is still not a failure in the sense of a catastrophic failure, it is still a problem in that if this had been a safety-critical system, any loss of data or messages could be catastrophic. When sending a 1 – Wire® command to multiple CAN nodes it was sometimes noted that the data received from the CAN nodes was not the data requested by the 1 – Wire® Master and stored by the 1 – Wire® slaves. For instance, consider the second test case in Table
6.4. There are two receiving CAN nodes and both the CAN bus and 1 – Wire® bus are operating at their slower speeds of 10 kbps and 14 kbps, respectively. Only in certain instances is data lost when it is requested from the CAN nodes. After inserting lines of debug code and recording the commands sent to the CAN nodes from the 1 – Wire® Master, no correlation is found between one particular command being sent to the CAN nodes from Table 6.4 and data loss. It was discovered, however, that in certain cases if both CAN nodes send their data before it can be fully processed by the 1 – Wire® Bus Master, data loss to the 1 – Wire® slaves occurs. This results in the first byte of requested data being overwritten by the second byte of data. The CAN node that transmits its byte of data first determines which byte of data is actually stored to the 1 – Wire® slaves. It is also discovered that there is no loss of data in the commands being send from the 1 – Wire® Master to the receiving CAN nodes. Again, a possible solution to this problem is to implement either a FIFO or a prioritized FIFO buffer to possibly prevent the data requested from the CAN nodes from being overwritten. As was mentioned in Section 6.2.1.2, another possible solution is to implement some type of handshaking or acknowledgement when the data byte requested from the CAN nodes are actually successfully stored in the memory of the DS1996 1 – Wire® devices. Even though this would impact the speed of the bus, the reliability gained by preventing data loss would greatly outweigh the reduction in data throughput. Finally, no conclusion is reached regarding the loss of data in the test cases (tests 3,4,7, and 8) where the 1 – Wire® slaves are operating at overdrive speed. It is unknown as to whether the data loss to the 1 – Wire® slaves is a result of all devices not operating in overdrive speed or if data loss is a result of both CAN nodes transmitting the requested data before the 1 – Wire® 204
- Page 177 and 178: that buffer is given to the CPU and
- Page 179 and 180: Acceptance Mask Registers (accepted
- Page 181 and 182: SJW1, SJW0: Synchronization Jump Wi
- Page 183 and 184: TSEG22 - TSEG10: Time Segment Bits.
- Page 185 and 186: The transmit clock (ttxclk) is used
- Page 187 and 188: 5.3.13 CAN Module Transmit Buffer I
- Page 189 and 190: Figure 5.28 CAN Transmit Data Segme
- Page 191 and 192: 5.3.20 CAN Node Overview As stated
- Page 193 and 194: Read Digital InputsRead the value o
- Page 195 and 196: the clock high time is either 5 µs
- Page 197 and 198: Yes Perform A/D Conversion on AN0 W
- Page 199 and 200: and GP2 and GP5 as outputs. With th
- Page 201 and 202: external INT pin, and then branches
- Page 203 and 204: Read MCP2515 Rx Buffer for Digital
- Page 205 and 206: When a valid message is received, t
- Page 207 and 208: Table 5.19 Resource Utilization. Re
- Page 209 and 210: For this test, only one CAN node wa
- Page 211 and 212: an Error Frame to be generated. Aft
- Page 213 and 214: messages, acknowledge messages, or
- Page 215 and 216: 5.3.21.4 Send Basic Frame Test (sen
- Page 217 and 218: going from one node to 30 nodes (se
- Page 219 and 220: Table 6.1 Resource Utilization. Rev
- Page 221 and 222: 6.2.1 Test Verification and Overvie
- Page 223 and 224: has read access to this register. T
- Page 225 and 226: system configuration used for this
- Page 227: or not depends on the number of rec
- Page 231 and 232: CHAPTER 7 CONCLUSIONS AND FUTURE WO
- Page 233 and 234: a communication bus reset will occu
- Page 235 and 236: For the synthesizable CAN Controlle
- Page 237 and 238: additional CAN nodes were added to
- Page 239 and 240: Fall-Through Stack A LOW level on t
- Page 241 and 242: In conclusion, the prototype system
- Page 243 and 244: REFERENCES [1] IBM ASIC Products Ap
- Page 245 and 246: [22] “CAN - a brief tutorial for
- Page 247 and 248: [44] Microchip MCP2515 - Stand-Alon
- Page 249 and 250: [67] K. Tindell and A. Burns, “Gu
- Page 251 and 252: [88] “Verilog - A Language Refere
6.4. There are two receiving CAN nodes and both the CAN bus and 1 – Wire® bus are<br />
operating at their slower speeds of 10 kbps and 14 kbps, respectively. Only in certain instances<br />
is data lost when it is requested from the CAN nodes. After inserting lines of debug code and<br />
recording the commands sent to the CAN nodes from the 1 – Wire® Master, no correlation is<br />
found between one particular command being sent to the CAN nodes from Table 6.4 and data<br />
loss. It was discovered, however, that in certain cases if both CAN nodes send their data<br />
before it can be fully processed by the 1 – Wire® Bus Master, data loss to the 1 – Wire® slaves<br />
occurs. This results in the first byte of requested data being overwritten by the second byte of<br />
data. The CAN node that transmits its byte of data first determines which byte of data is<br />
actually stored to the 1 – Wire® slaves. It is also discovered that there is no loss of data in the<br />
commands being send from the 1 – Wire® Master to the receiving CAN nodes.<br />
Again, a possible solution to this problem is to implement either a FIFO or a prioritized<br />
FIFO buffer to possibly prevent the data requested from the CAN nodes from being<br />
overwritten. As was mentioned in Section 6.2.1.2, another possible solution is to implement<br />
some type of handshaking or acknowledgement when the data byte requested from the CAN<br />
nodes are actually successfully stored in the memory of the DS1996 1 – Wire® devices. Even<br />
though this would impact the speed of the bus, the reliability gained by preventing data loss<br />
would greatly outweigh the reduction in data throughput.<br />
Finally, no conclusion is reached regarding the loss of data in the test cases (tests 3,4,7,<br />
and 8) where the 1 – Wire® slaves are operating at overdrive speed. It is unknown as to whether<br />
the data loss to the 1 – Wire® slaves is a result of all devices not operating in overdrive speed or<br />
if data loss is a result of both CAN nodes transmitting the requested data before the 1 – Wire®<br />
204