1 / 21

CAN-Bus Logger Final Presentation Jan , 2011

CAN-Bus Logger Final Presentation Jan , 2011. Elad Barzilay Idan Cohen-Gindi Supervisor: Boaz Mizrahi. Abstract.

ping
Download Presentation

CAN-Bus Logger Final Presentation Jan , 2011

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. CAN-Bus LoggerFinal PresentationJan , 2011 Elad Barzilay Idan Cohen-Gindi Supervisor: Boaz Mizrahi

  2. Abstract The goal of this project is to produce A Real-time Data Logging system which connects to a vehicle’s CAN-Bus, An External GPS device and Analog sensors, for reach data storage and analysis.

  3. Overview • The project continues the PCD project. • The CAN interface is developed on a designated module which integrates to the main PCD platform. • The device will posses advanced functions such as: • Advanced diagnostic. • Real time monitoring of the vehicle’s operation. • Access and control of other control units on the vehicle. • The device will be able to support various applications and will allow analysis on board a PC.

  4. CAN Protocol - Reminder

  5. Objectives • Preliminary Design • Block Diagram • Design Concepts • Architecture & Platform • Detailed Design • Main Components • Electrical Design – Pin to Pin • Integration & Platform Adjustments • Mechanical Design • Layout , Manufacturing & Electrical Test • Software\Firmware • Debugging • Operating

  6. Block Diagram CAN Module Processing Unit Data Link Layer Physical Layer • Physical Layer : • Maintaining CAN electrical requirements • Protecting the device • Processing Unit : • Manage CAN applications • Control peripheral devices • User interface • Data Link Layer- • Protocol implementation • Basic message filtering

  7. On-Board User Interface LCD & Key-Pad CAN Bus network CAN Module PC MCU Flash Memory Analog Devices Block Diagram

  8. CAN Module SPI To MCU MCP2515 Controller MCP2551 Transceiver RX CANH TX CANL CAN Module Components • CAN Transceiver – MCP2551 • Transform the TX,RX lines to CAN_H , • CAN_L required for the connector • to the bus. • Supports 1 Mb/s operation • Suitable for 12V and 24V systems • fault-tolerant & high buffering protection • CAN Controller – MCP2515 • Implementing the CAN protocol engine • Receiving and transmitting buffers. • Filtering and masking capabilities for • message analyses and acceptance. • Error detection and handling and bit • timing.

  9. Electrical Design

  10. Pinout Description • Voltage supply – • 3.3 Volt for the operation of the MCP2515 CAN controller. • 5 Volt for the operation of the MCP2551 CAN transceiver. • Gnd • SPI Interface – • SPI Data In • SPI Data In • SPI Clock • SPI CSn • CAN Communication – • MCP2515 Interrupt – request for attention from the MCU. Connectors on-board the PCD board: Connectors on-board the CAN board:

  11. Integration & Platform Adjustments • Add/Remove HW and fix problems spotted during the first debug • Making suitable Adjustments for the CAN Module integration • Bring up and power up of the new Board – electrical test were made but bring up and code testing were not – because of un preparedness of the main platform.

  12. Mechanical Design • The CAN board is placed on four 100mil • connectors, for robustness. the card’s • outline goes around high components • on the PCD board. • All large components and • connectors are located on • the bottom side of the CAN • board.

  13. Mechanical Design The CAN board dimensions: length: 22 mm, width: 32 mm, height: 8 mm Top view: Bottom view:

  14. Layout & Manufacturing Top view: Bottom view:

  15. Layout & Manufacturing • 30 boards were sent to manufacture, both the revised PCD platform and the CAN board. Date: 20/12/09 Offshore supplier (china): MakePCB Ltd. Total cost including tax and shipment: 275 Euro.

  16. Software Outline • Operating code changes : • Upgrading the Main Menu – CAN_Menu.c which contains the functions: Menu(), Start_Menu() , QS_Menu() example: CAN_Menu QS_Menu 1. Quick Start 2. set test Duration 3. set Sampling Rate 4. set Output 5. Files 6. Exit SPD & RPM & FUEL -------&-------&------- TMP & CO2 & OIL_P -------&-------&------- & & -------&-------&------- * Next & 0 Clr & # Prev

  17. Software Outline • CAN module operating code: • MCP Operative – MCP2515.C and MCP2515_Defs.h which includes all the functions and definitions for a complete operation of the CAN Module: void MCP_Reset(void); void MCP_Modify( unsigned char Address, unsigned char Mask, unsigned char Data ); void MCP_Write( unsigned char Address, unsigned char Data ); unsigned char MCP_Read( unsigned char Address); unsigned char MCP_Read_Status( const unsigned char Address ); unsigned char MCP_SetCANCTRL_Mode(const unsigned char newmode); unsigned char MCP_ConfigRate(const unsigned char canSpeed); void MCP_Read_Can_Id( const unsigned char rxb_sidh_addr , bool* ext, unsigned int* can_id ); void MCP_Read_CanMsg( const unsigned char rxb_sidh_addr, CanMessage* msg); void MCP_Write_Can_Id( const unsigned char txb_sidh_addr, bool ext, unsigned int can_id ); void MCP_Write_CanMsg( const unsigned char rxb_sidh_addr, const CanMessage* msg); void MCP_Start_Transmit(const unsigned char txb_sidh_addr); unsigned char MCP_GetNextFreeTXBuf(unsigned char *txbuf_n); void MCP_InitMCPBuffers(void); unsigned char MCP_Init(const unsigned char canSpeed);

  18. Software Outline • PIC – MCP Interface - SPI_MCP.C which includes all the pin-out definitions and functions for the SPI interface between the MCU and the CAN module’s MCP. // Enable Pin #define SSPEN SPICON1bits.SSPEN // Description: The main SPI control register #define SSPCON SSP1CON1 // Description: The SPI status register #define SSPSTAT SSP1STAT // Description: The SPI buffer #define SSPBUF SSP1BUF // Description: The bitwise define for the SPI control register (i.e. _____bits) #define SSPCONbits SSP1CON1bits // Description: The write collision detect bit in the SPI control register #define CON_WCOL SSP1CON1bits.WCOL // Description: The write collision detect bit in the SPI control register #define CON_CKP SSP1CON1bits.CKP // Description: The bitwise define for the SPI status register (i.e. _____bits) #define SSPSTATbits SSP1STATbits // Description: The receive buffer full bit in the SPI status register #define STAT_BF SSP1STATbits.BF // Description: The receive buffer full bit in the SPI status register #define STAT_SMP SSP1STATbits.SMP // Description: The receive buffer full bit in the SPI status register #define STAT_CKE SSP1STATbits.CKE

  19. Software Outline • CAN Message interface code – CAN.C which includes a complete set of function the send / receive / store / check errors of can messages and can message struct : typedef struct { // identifier CAN_xxxID uint8_t extended_identifier; // either extended (the 29 LSB) or standard (the 11 LSB) uint32_t identifier; // data length: uint8_t dlc; uint8_t dta[CAN_MAX_CHAR_IN_MESSAGE]; // used for receive only: // Received Remote Transfer Bit // (0=no... 1=remote transfer request received) uint8_t rtr; // Acceptence Filter that enabled the reception uint8_t filhit; } CanMessage; uint8_t can_init(uint8_t speedset); void can_initMessageStruct(CanMessage* msg); uint8_t can_sendMessage(const CanMessage* msg); uint8_t can_checkReceive(void); uint8_t can_readMessage(CanMessage *msg); uint8_t can_checkError(void);

  20. Done So Far… • Preliminary Design • Block Diagram • Design Concepts • Architecture & Platform • Detailed Design • Main Components • Electrical Design – Pin to Pin • Integration & Platform Adjustments • Mechanical Design • Layout , Manufacturing & Electrical Test • Software\Firmware • Debugging • Operating

  21. Need to be done… • Software\Firmware – • 90 % of the code is written . • To be written: Oscillator timing for the MCP , small fix-up in the CAN.c code, “envelop functions” and documentation of the code. • Debugging • Software Debugging. • CAN_H , CAN_L scope analyze • Transmit and receive testing between 2 devices • Operating : • OBD-II Testing : request, receive, validate and store. • GUI on PC. • Final Integration: VEHICLE -> OBD -> MCP -> PIC -> SD > USB -> PC GUI

More Related