1 / 39

A Controller Area Network Layer for Reconfigurable Embedded System

A Controller Area Network Layer for Reconfigurable Embedded System. Nithyananda Siva Jeganathan Masters Thesis Defense Department of Electrical and Computer Engineering University of Kentucky Lexington, KY October 3, 2007. Outline. Thesis Motivation Reconfigurable Architecture background

morr
Download Presentation

A Controller Area Network Layer for Reconfigurable Embedded System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Controller Area Network Layer for Reconfigurable Embedded System Nithyananda Siva Jeganathan Masters Thesis Defense Department of Electrical and Computer Engineering University of Kentucky Lexington, KY October 3, 2007

  2. Outline • Thesis Motivation • Reconfigurable Architecture background • Thesis Objective • CAN Background • CAN Applications • CAN Hardware Overview • CAN Protocol Overview • C_CAN Controller overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

  3. Thesis Motivation • All safety-critical distributed systems need a reliable network for communication • The embedded network should also be fault-tolerant • Operate with limited services during faults and degrade gracefully in case of failures

  4. Background • Reconfigurable distributed Apps. • Ideal platform for fault-tolerant systems • Faults will always occur • system should detect/isolate faults • Ardea is the reference framework • IDEAnix Framework • ENDURA network layer IDEAnix Framework

  5. ARDEA Background Direction Graph • ARDEA Architecture • Framework for dynamic reconfiguration using Direction Graphs (DGs) • Supports Graceful degradation • Relies on Broadcast network for sending data between nodes • IDEAnix Framework • Provides application layer with features for reconfiguration • Location Transparency of Tasks/data • Handles packet routing between nodes/ modules

  6. Thesis Objective • Embedded Network Driver for Use on Reconfigurable Architecture (ENDURA) • Broadcast type network with dynamic registering or unregistering of messages • Network Interface task using Controller Area Network (CAN) • ENDURA layer implementation is generic • Designed to match standard API calls • CAN layer can be replaced by any broadcast type network • Reusability of modules and dynamic addition of functionalities • Reduction of system complexity • Modules can be developed and tested independently

  7. Outline • Thesis Motivation • Reconfigurable Architecture background • Thesis Objective • CAN Applications • CAN Background • CAN Hardware Overview • CAN Protocol Overview • C_CAN Controller Overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

  8. CAN Applications Overview • Small Vehicle Applications • Light Electric Vehicles (LEVs) • Marine Applications • SeaCAN architecture • NAUTILE • Space Applications • SMART-1 satellite of ESA • SOFIA • Galileo Projects

  9. CAN Background • CAN standard invented by Bosch GmbH for Automobiles in 1980s and widely used in embedded systems • ISO standardized the protocols • ISO 11898-1:CAN type A (11 bit Msg Ids) • ISO 11898-2:CAN type B (29 bit Msg Ids) • ISO 11898-3:Time Triggered CAN (TTCAN) • CAN protocol standardized in Data Link layer and MAC layer • Maximum Payload of 8 bytes • Maximum Bandwidth 1 MBits/Sec (upto 40m)

  10. CAN Protocol Overview • CAN is broadcast type network • All nodes receive all the messages • Message filtering option on processors • Different Physical Layers as a rule, cannot interoperate • CAN bus is Wired-AND logic • Dominant bit is 0V & Recessive bit is +5V • If one node is transmitting 0, then the network is in that state (All other processors transmit a 1) • Acceptance Filtering is key to message Rx • Based on Message identifiers and network Tx is Big-Endian • 4 types of Packet Formats • CAN Data Frame, Remote Frame, Error Frame, Overload Frame

  11. CAN Frame Format

  12. Outline • Thesis Motivation and background • Objective and Problem statement • Embedded Network background • CAN Background • CAN Applications • CAN Hardware Overview • CAN Protocol Overview • C_CAN Controller overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

  13. Silicon Laboratories C8051F04x • 8051 based 8-bit Microcontroller platform for ENDURA implementation • Implements CAN protocol using Bosch’s C_CAN protocol controller chip • Has 32 Message Objects that can be configured for Rx/Tx • Supports speed upto 1 Mb/s and 9 pin D-sub connectors are used

  14. C_CAN Processor Block diagram

  15. C_CAN Overview • C_CAN controls all CAN communication • C_CAN configurations are done through Registers • Protocol Control Registers • Control setting up of Bit-timing, Init sequences • Message Interface Registers • Msg Obj Configuration • Rx/ Tx control (Identifier Masks) • Reading/ Writing Data, ID • Message Handler Registers • Status of Msg Obj (NewData, Interrupt, Tx Rqst)

  16. ENDURA Block Diagram

  17. ENDURA Design Details • The ENDURA layer is a generic network implementation for Reconfigurable architecture • ENDURA layer for CAN is modularized as: • Initialization API • API Prototype: Void Init_network(void); • Initializes the bit-timing, BRP registers • Allocates and initializes the Data-structures for ENDURA • Sets the Init bit to 0 and starts CAN engine • This API has to be invoked before the node can start communicating on the network

  18. Register Module Flow chart

  19. Register Module • API Prototype: uint8 reg_pkt(ulong msg_id); • Verifies if the Message Id entered is valid or not been registered already (Msg ID 0 is invalid on CAN bus) • Locates a vacant Message Object number for config • Sets the Arbitration bits on IF1 ARB1 and IF1 ARB2 registers • Sets MsgValid bit on IF1 ARB2 Register • Sets UMask values in MSG Control Register to register for range of Msg ids • Enables the Interrupts for the Msg Obj when successful RX of a packet in MSG Control Register • Writes into IF1 Command Req Reg with the Msg Obj Number

  20. Unregister Module • API Prototype: uint8 unreg_pkt(ulong msg_id); • Verifies if the Message Id entered is valid or not been unregistered already (Msg ID 0 is invalid on CAN bus) • Locates the corresponding Msg Obj number configured for receiving the packet • Clears the IF1 Command Mask register values • Clears the Arbitration bits on IF1 ARB1 and ARB2 registers • Clears the MsgValid bit on IF1 ARB2 Register • Clears the MSG Control Register • Writes into IF1 Command Req Reg with the Msg Obj Number

  21. Send Packet API

  22. Send Packet Module • API Prototype: uint8 send_pkt(ulong msg_id, ulong msg_data); • Send_pkt API sends a packet of given message id (11 or 29 bits) and payload on to the CAN bus • Send_Pkt API uses IF2 Registers for Msg obj config • Pre-defined Msg obj is chosen for sending packets : • Sets the IF2 Command mask register to write • Sets the Arbitration bits on IF2 ARB reg to 11 or 29 bit ids • Sets the MsgValid bit on IF2 ARB2 Register • Writes into IF2 Command Req Reg with the Msg Obj Number to send the packet on the network

  23. Receive Packet Module • API Prototype: uint8 get_pkt(ulong *msg_id, ulong *msg_data); • get_pkt API fetches the latest message identifier and payload • The Get_pkt API reads the new Data registers to identify the message object that has been updated • Returns the message Id and Payload from the software buffer for the message object

  24. CAN ISR Flow chart

  25. Interrupt Service Routine • CAN Controller when configured correctly can trigger an interrupt (#19) • After successfully sending a packet • After successful reception of packet • If Error packet is received on CAN bus or error in Tx • Receive packet interrupt handling: • Clear the Status interrupt • Reads the data from NewData Registers to identify the message object that has the latest data • Copies the Message Object information onto Software Buffer or Send to queue • Transmit Packet interrupt handling: • Clear the Status interrupt • Optional can be used in fault-tolerant implementations • Error Interrupt handling • Clear the Status interrupt • Can be used by network fault-detection/ isolation modules

  26. ENDURA Translation Module Translates A CAN 2.0 A type packet to 2.0B type and vice-versa

  27. ENDURA Validation • ENDURA layer subjected to following tests: • CAN Conformance test • Performance Tests • Bandwidth Tests • Latency Tests • Endurance Tests • Sporadic packet Tests

  28. ENDURA Performance Data • CAN Conformance test • All modules meet the CAN protocol conformance • Performance Tests • Endurance Test • No dropped packets at 10ms delay in packets • Pkts sent = 14,406,543 Pkts dropped = 0 • Sporadic Packet Tests • Packets sent at 1000ms, 500ms, 100ms, 50ms, 10ms rate • Bandwidth Tests • Maximum Bandwidth measured with IDEAnix = 100 KBPS • Bottleneck due to OS context switching time • Latency in sending a packet through the CAN controller

  29. BW Analysis- Packets Received rate Packet Rate Vs Packets Rxd

  30. BW Analysis- Packets Drop rate Packet Rate Vs Packets Dropped

  31. Latency Test Measurement

  32. Latency Test Data • Latency Tests • RX packet latency in ENDURA layer (T1) = 110 μSecs • RX MeRL processing latency (T2) = 756 μSecs • RX packet latency in CAN application(T3) = 856 μSecs • TX packet latency in ENDURA layer (T4) = 924 μSecs • TX packet latency in CAN application(T6) = 9 mSeconds • Time taken by C_CAN processor to TX a pkt = 110 μSecs • Max Bandwidth that can be realized = 120 KBits/Sec

  33. Latency Test Timing Diagram

  34. Outline • Thesis Motivation and background • Objective and Problem statement • Embedded Network background • CAN Background • CAN Applications • CAN Hardware Overview • CAN Protocol Overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

  35. Future Enhancement • CAN Bandwidth can be improved • By improving the OS Time Tick from 10 ms • By varying the No. of OS ticks per sec from 100 • CAN Send Packet Latency can be improved • By routing the inter-module packets through the ENDURA layer instead of IDEAnix • This improves latency by 10 times • Implement CAN Gateway nodes capable of communicating to other embedded networks • CAN to Wireless Network gateway (for extending CAN network) • For forming Ad-hoc networks

  36. Conclusion • Provides a fault-tolerant platform for communication between nodes • Generic network task framework that can be ported to any broadcast type embedded network • Provides an infrastructure for reconfigurable architecture to perform dynamic reconfiguration • Realization of soft real-time distributed system made possible

  37. ?

  38. Thank you!

  39. Fin!

More Related