###   
  ## ##  
  ##     
 ####    
  ##     
  ##     
 ####    
         

    ###  
   ##    
   ##    
 ######  
   ##    
   ##    
   ##    
         

 _____ 
(  _  )
| (_) |
|  _  |
| | | |
(_) (_)
       
       

 _   _ 
( ) ( )
| `\| |
| , ` |
| |`\ |
(_) (_)
       
       

     #   
         
    ##   
     #   
     #   
     #   
 #   #   
  ###    

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Overview''' CAN stands for Controller Area Network. It is a high reliability network typically used for connecting microcontrollers, in the industrial and transportation fields. VEMS v3 has SPI_CAN since the very beginning. It's used for BMW S65 and S68 CAN-bus of DBW throttles and idle valve (the termination resistor differs between S65 and S68, but otherwise the protocol is same). CAN bus is also useful for dashes. The [https://shop.vems.hu/catalog/stm32f103mcp2515-p-213.html VEMS STM32 Aim to CAN] (2nd CAN interface via 2nd serial => AIM, see AimToCanBusPinout ) is used in general to send data to dash. '''To specify your requirement, on your project page, use''' * [http://vector.com/vi_candb_en.html CAN-db format] * or say BMW S65 or BMW S68 DBW ETC-throttles+idle * or exact hexdump example with annotated values (CAN-ID, units, resolution, min/max, ...) ** CanBusSniffer * BmwCanEFortySix - BMW E46 can messages * SimpleCanMessages - example: CAN messages for Audi A4 B5 chassis/dash (2001 A4 AWM 1.8t specifically) ---- '''Using CAN bus involves:''' * connecting the bus the proper way, with appropriate terminating resistors and CanBias ** more demanding than RS485; without proper connection, reliable operation will not be achieved * sending the right messages (often not exactly known by the installer) * often logging and analyzing sniffed data, preferrably together with other data (runtime data, and perhaps synchronously logged audio and video stream) ** orange PI PC with CAN bus is most appropriate for this. Perfect during setup. However it boots in >3 sec (depends on several factors but min 5..10 sec usually), and needs cooling heatsink (even at 60C, even if downclocked) so perhaps suboptimal for long-time production operation. ** even if finally the messages will be sent by VEMS v3 (or some VEMS or non-VEMS STM32F... board: the "C state-machine" code is basically the same), a PC (or orange PI PC) based tool is useful during setup ---- See VemsFrontier/NetWorkHardWare for other ways to connect microcontrollers. '''Important notes''' * 3 layers of compatibility: ** physical: sounds easy to meet: use a CAN transceiver and cable terminated properly. Not sure if 3V and 5V transceivers can communicate over the same segment reliably (IMHO yes: texas 3V transceiver claims to like 5V input and the 5V should in no case break because of low signal level) ** datalink: speed and real CAN or CAN-UART (CAN connected to UART or "FBUS" with a certain arbitration protocol) ** network: CAN ID-s: there are 11-bit and 29-bit ID-s used. The big problem of compatibility with other manufacturers is knowing their ID-s and their meanings. It usually just costs too much to find out. If 2 devices are incompatible on the physical or datalink layer, it does not make sense to talk about making them more compatible or "standard". But bridging these segments is possible of course. Even real CAN devices are incompatible if (configured to) different speed ! With different speeds, they must be on different segments. * For the smallest devices (even when CAN physical layer transceivers are used!), compatibility with real CAN is not aimed, and is not a design target. The high-end devices with real CAN can also talk to these (and provide bridge functionality) through their UART(s). * the physical requirements for the segment must be met. Terminations must be ** placed on (and only on) both ends of the segment ** matching the cable wave-impedance (min 100 Ohm, but 120 Ohm preferred). ** the transmitters should not break because of 100 ohm terminations (that is 50 Ohm load because there are 100 Ohm parallel on the 2 ends) ---- '''Time Triggered messages''' - messages are transmitted even when there is no event (so network disconnects can be detected and handled more gracefully) * the lastest CAN variant appears to be '''Time Triggered CAN''', or TTCAN. This allows for time triggered CAN messages as opposed to the event triggered messages used by regular CAN. * FlexRay * TTA (Time Triggered Architecture) Read about the [http://www.embedded.com/showArticle.jhtml?articleID=9900596 war between standards] that is reaching it's climax soon. '''Network model''' '''Higher layer protocols''' Although the lower level CAN protocols are well documented with freely available information, we need a higher layer protocol to actually define the data we are using. It is possible to design this from scratch, but this work has already been done before many times. A free standard would be ideal, and it should be compatible with existing autmotive systems and tools. Some applicable standards are :- * ISO 11898 - Road vehicles -- Controller area network (CAN) parts 1 to 4 (part 3 is still under review). * ISO 15765 - Road vehicles -- Diagnostics on Controller Area Networks (CAN) parts 1 to 3. * ISO 16845 - Conformance test plan. To make sure the above is kosher. * SAE J1939 - Designed for heavy and off-highway vehicles, and includes lots of engine and drivetrain specific messages. Not free, but very complete and allows interaction with 3rd party tools if needed. * CANaerospace - Designed for aircraft usage, but free, and does have some basic engine messages defined. '''Controllers''' As CAN useage grows in non-automotive areas, more microcontrollers are available with CAN networking built in. The ATMega128 doesn't have this however, so an external CAN controller must be used. Any future ARM controller used will include at least one CAN networking module. More modules are useful, to allow different speed buses to be used for different tasks. For a Genboard 3.x add-on, we need an SPI or similar interface to talk to a standalone CAN controller. Some applicable parts are : * LPC2119 has 2 CAN controllers onboard * Microchip MCP2515 - Standalone CAN controller IC, with an SPI communication interface. * An universal FPGA with apropriate IO can use http://opencores.gds.tuwien.ac.at/projects.cgi/web/can/ Open Source Core license free for non comercial application (so licensing is on the edge for us). Is this useful when 2 CAN controllers from the ARM is not enough, but there is an FPGA onboard (with costly parallel interconnection to the main uC for this verilog model) ? If it works for first try, it's fine, but debugging such a gizmo (or CAN related competibility problems) is very hard. (don't take it Personal this is just a collection of Information Marcell! There won't always be the cost of designated Microcontrollers, FPGA's Rule ;-) (lets remove this Noise soon ok!) '''Transceivers''' * Microchip MCP2551 - CAN transceiver. Not compatible with 3.3V IO (sigh, microchip....) * we know many transceivers (most are soic8 and pin-compatible !), texas seems to be the leader (better than philips) * AT90CAN128 (atmega128 with CAN contoller) * http://www.google.com/search?q=%22CAN+bus+transceiver%22&ie=ISO-8859-1 '''Media''' 2 wire sheilded twisted pair is the ideal media for high-speed CAN usage. In an automotive environment there is electrical noise all over the place, so the added cost of this wire is worth it. Wire should have an impedance of 120 Ohms, and a resistance of up to 70 mOhm/m. The bus should have 120 Ohm termination resistors on each end, while the plugs used for connection should have 120 Ohm impedance and a 70 mOhm resistance. Connectors are commonly 9 pin D-Sub type, however for automotive use, a smaller circular connector may be desirable. Several purpose designed heavy-duty connectors are available from Deutsch, AMP/Tyco, and Amphenol, among others. ---- ( move to VemsFrontier/NetWorkHardWare ) '''Alternatives''' If CAN is overkill for a given application, that don't need the reliability or overhead (and speed) of CAN: * Local Interconnect Network or LIN may be used. This would be appropriate for ancillary devices * CAN transceivers can be used with simple UARTS (the only option with the smallest dongles and displays with atmega168). Advantages over RS232: ** multi-drop (many devices on a bus). Similar to RS485, but without the collision problem and extra IO for direction control. ** higher speed and segment length ** more tolerant to noise ** buzzword "wow" effect Note that a segment like this would not be compatible with a real CAN segment (had to be separated). '''Future directions''' An even higher-reliability replacement for the CAN network are the Flexray and ByteFlight networks. These allow higher datarates. ---- '''CAN links''' :http://www.can.bosch.com/content/Links.html :http://groups.yahoo.com/group/CANbus :http://www.port.de/cgi-bin/CAN (CAN Wiki) :http://www.mjschofield.com/ :http://www.port.de/software/can4linux.3.0.tgz :http://www.algonet.se/~staffann/developer/frames.htm :http://www.racelogic.co.uk/downloads/app_Notes/CAN%20Bus%20Parameters%20by%20manufacturer.pdf :http://www.esacademy.com/myacademy/ (A few online CAN courses) :http://caraca.sourceforge.net/ SW CAN with small AVR! (Even if we have the LPC2119 big guy, small CANcapable units might be nice for simple tasks, eg. lights and alike). :http://en.wikipedia.org/wiki/Controller_Area_Network "Devicenet" is a higher-layer protocol on top of CAN hardware ( http://en.wikipedia.org/wiki/DeviceNet ). ---- ( move to VemsFrontier/NetWorkHardWare ) '''CAN substitute''' CAN is not a miracle. There is nothing about CAN that couldn't be implemented with simpler HW (network-protocols) and smart software. CAN is just a standard so some commonly used features are implemented at low level, and licence-fees is guaranteed to be paid to ... whoever ... instead of other parties. The good side is interoperability, and that engineers with less skills can also design powerful and reliable systems. Features CAN helps in: * framing (generation of frames and detection of frame boundaries) * error detection * unit addressing (and message routing) * TTCAN, TTA and FlexRay helps to detect lost frames also Here's a decent list of automotive bus alternatives... CAN is only one of many, but has been adopted outside the automotive industry so is relatively easy to work with now. http://www.interfacebus.com/Design_Connector_Automotive.html GenBoard/VerThree needs a small addon board for CAN, and Jörgen ruled out the possibility to add CAN to first production AfreshTiny, I think we should play a bit with homebrewn solutions of digitally connecting boards. options: * the 2nd RS232 is there * using '''twisted pair and symmetrical drive''' would allow longer cables or higher bandwidth. This can be achieved by a differential input, and 2 outputs, one inverted, the other noniverted. Max freq for midOPA would be around 1MHz, but serial comm over 230kbaud is not really useful with v3. In any case, error checking with checksum is a must. See GenBoard/BinaryProtocol. ---- '''CAN to nonCAN''' see CommMatrix unfortunately (thanx to intel's revenue-hunt) the technically very very very bad USB became the standard in the PC world (instead of some modified Ethernet, to include power supply; or firewire or CAN). We need to connect to the PC. We will have * CAN on every board and * FBUS or RS232 on every board. RS232 (RS232 is the combination of all disadvantages of every network standard: short distance, non-bus capable, -+ signal, low baudrates) can be used to talk to PC, and FBUS can be used to talk to anything ( RS232 / CAN / USB / 1-wire transceiver in DSUB9 housing; this is a small simple cheap unit, FBUS-RS232 and FBUS-USB are already stocked !!!) Making/buying an interface board/cable could work. options: * http://www.everythingusb.com/hardware/index/Delkin_USB_Bridge.htm * http://www.cypress.com/products/datasheet.cfm?partnum=CY7C67200&familyid=A6B8BB1A-BDB2-4175-8B47D1F27AEDBD27&errataid=B197CA6A-7D02-4ACE-9B69E13D879B8D51 but we try to avoid BGA. * CAN - USB: http://www.kvaser.com/prod/hardware/usbcan2.htm * http://www.semiconductors.philips.com/buses/usb/products/otg/ * USB - CAN logger: http://www.kvaser.com/prod/hardware/memorator.htm * schematics for CAN - USB: http://www.circuitcellar.com/flash2002/First/abstractM250.htm <richb> the kvaser product looks ideal for development. i don't think it's sensible for end users though guys, please when you discuss on irc, please, please someone take 3 minutes, and put the result to wiki, so others won't need to search for hours to find the same. thanx. ---- '''An implementation plan:''' CAN is good, but what's more useful right now is something we can implement quickly. How about this: * KWP-2000/ISO-14230 for starters. This is a serial specification that doesn't use CAN. It's used on a range of vehicles such as VW Toureg and Phateon, BMW E60 5 and 7 series, and Mercedes Benz... also Hyndai and Suzuki. The main competitor is ISO-9141. See http://www.etools.org/i4a/pages/index.cfm?pageid=1866 '''Jason, can you buy the data-link layer of this from vems money ?''' - appr. $50. It's OK licensed to you, easier to buy that way (since paid from your account). But Marcell will read it, and might ask Richard Barrington to help understand it :-) * When this is stable, move to KWP-CAN/ISO-15765. The is basically KWP-2000 on a CANbus. Used on a similar stable as above, but from around '05 onwards. If we've got good inter-node networking, we can simplify each component *a lot*. This can give us faster time to market, and improve QA. ---- The OBD-II (On-Board Diagnostics) plug is required by law on every car sold in the US. http://www.pcmag.com/article2/0,1895,2012389,00.asp http://en.wikipedia.org/wiki/On_Board_Diagnostics http://en.wikipedia.org/wiki/Talk:On_Board_Diagnostics * Is this OBD-II a kind of CAN bus ? ** IIRC no, OBD-II is rather a weird type of UART (serial port) with at least 2 different (incompatible) type physical layers used (for different cars). Some data representation is standardized, some (most) is factory specific (proprietory, often hard to find out). ----
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.