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

_________
\__   __/
   ) (   
   | |   
   | |   
   | |   
___) (___
\_______/
         

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

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

  ______ 
 |  ____|
 | |__   
 |  __|  
 | |____ 
 |______|
         
         

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:
'''Developer corner: find a good way for networking the ARM and AVR boards''' This is hardware related. VemsFrontier/Networking is about software/logical issues. * the ARM ( eg. VemsFrontier/ArmEfi and IonSense ) will work nice with CAN * a CAN transceiver might be added to v3.x so at90can128 can be used * CAN is also possible with ATMEGA88/atmega168 with the help of http://caraca.sourceforge.net but speed is limited and CPU overhead is significant '''Physical layer overview: why we like CAN''' * FBUS point-2-point for very short distance. This is the most cost efficient to connect to most recent notebooks, that only have USB, not RS232. Many devices only support FBUS because of space constraints: ** round small display ** mobile phones ** Nintendo Gameboy * RS232 point-2-point for short distance. This is the traditional connection, so connectivity solution required for psychological reasons. Cost to connect to most notebooks (USB) is higher than FBUS, but still relatively low. * '''[[http://www.st.com/stonline/prodpres/standard/interfc/rs42285.htm RS485] differential push-pull driven bus''' for networks upto 32 nodes (and beyond) on a segment. The most cost efficient high performance network solution. The only cost efficient automation network solution in buildings, where >40m segment lengths are required. Because of the push-pull drive, a "transmit enable" signal is needed between uC and the [http://focus.ti.com/docs/prod/folders/print/sn65176b.html transceiver] besides the GND/RX/TX. A (possibly elected) master controls bus arbitration. Most designs of professional networks are based on this (eg. profibus). * '''CAN is a differential bus''', that is not push-pull, but open collector driven, and pullup/down applied to maintain the "inactive state". So smaller line lengths are allowed (than RS485) for the same baudrate, but 40m segment is usually enough in a car. Bus arbitration takes place based on priority word at the beginning of each frame (using the open-collector bus, the "lower" priority wins). Because the drive is not push-pull, "transmit enable" signal is not needed between uC and transceiver just GND/RX/TX (TX=high will disable any transmitting) * LIN and 1-wire are connectivity solutions. Worse spec than CAN or RS485, and higher cost than RS485. 1-wire is even higher cost than CAN, but the only way to talk to the nice ButtonImmobilizer authentication devices. '''For the above reasons, CAN was chosen as our primary network solution.''' ARM processors with CAN controllers and onboard CAN transceivers are preferred except the most minimal designs. FBUS is freely available with any uC we use, and bigger boards will also feature connectivity solutions like RS232 for some time. Fortunately, [http://zone.ni.com/devzone/conceptd.nsf/webmain/F9F58CBF78A3D1ED86256C06007AF286?opendocument&node=dz00000_us bridging ]either of these to USB is simple and cheap. It is normally just a "cable" with some circuitry inside. RS232 and FBUS not only needs bridging to notebook, but also needs a HUB when more than 2 nodes are used. [http://www.rs485.com/pfaq.html converters] [http://www.modbus.org/ modbus] goes hand in hand (as a practical upper layer) with RS485 (see modbus over serial), although RS485 is just the physical layer and modbus is not a requirement. Modbus over serial would work with CAN transceivers also (not just RS485); advantage would be less overhead on small uC-s but possibly incompatibility with real CAN segments (the same way as different speed CAN segments are incompatible as well). ---- '''RS485 on VemsFrontier/ArmEfi''' We have CAN anyway. Would we want to use RS485 or CAN transceiver on one of the UARTs ? * 2 UARTs with LPC... is costlier than we thought, because every UART robs 2 PWM channels, so 2 UARTS means 4 out of 8 PWM is lost. We are sortof short of PWM on VemsFrontier/ArmEfi (although 4 should be enough), but not on other boards: mostly softpwm is good, HW PWM is nice for: ** WBO2 pump (for each WBO2 channel) ** injector PWMing (2 preferred for 8 injectors) ** SMPS (switching supply, eg. for CDI) ** misc analog output (softpwm is usually OK, but soft+HW pwm can do 12+ bits with high freq). This is available everywhere, since VemsFrontier/ArmEfi has only 1 WBO2 and no SMPS and IonSense has no injector PWMing. * CAN to anything (RS485; or RS232 that is only used for PC; or parallel bus like LBUS that is only good onboard) is cheaper than we thought: http://caraca.sourceforge.net/candongle/index.html but software implemented CAN is very limited in baudrate and costs many CPU clocks. '''Conclusion''' We probably want CAN on as many boards as possible, including the 9343 display. I'm afraid that 2 networks '''both CAN and RS485) would be costly to support originally'''. When we sell 10000 boards, we can maybe rethink this and invest in some development and use 2 networks from than on. The only difference this makes is that smaller sensor-controller boards (made from LPC2129) will have more IO than if they were atmega88 based. But the connector (and supply-connection!) costs dictate the same anyway. '''Also, CAN is a sales pitch''' ---- '''LIN protocol''' - an alternative * Transceiver like [http://ww1.microchip.com/downloads/en/DeviceDoc/21730d.pdf Microchip LIN transceiver] connects to UART with no other components needed (like RS485) * more expensive than RS485 - but still on the cheap side (unlike CAN) * lower bitrate than RS485 * shorter distance than RS485 (would not be showstopper) * similar, but even lower cost solution is a resistor for RX and an NPN (with internal base resistor) and slight pullup for TX. For above reasons, RS485 woule be the 2nd after CAN (the chosen primary network). LIN will only be supported if it comes "free" for some reason. I'd (sloppily) say that * '''LIN is a low cost version of Dallas 1-wire'''. But we only use 1-wire when we have no other choice (eg. authentication button). Between boards it's suboptimal, IMNSHO. ---- '''CAN transceiver and CAN voltage''' MCP2551 and Texas CAN transceivers are competing, but they are both SOIC8 and pin and function compatible. Both support 3.3 or 5V IO to the uC (eg. MCP2551 thresholds are guaranteed ViH above 2V, and ViL below 0.8v) power: * 5V CAN might be more tolerant to noise ? * 3.3V CAN. Since onboard IO will be 3.3V in the future, this eliminates an extra supply. Fortunately the Texas transceiver works with both buses, but it's better to decide about the voltage now. ---- '''See also''' * VemsFrontier/Networking/Caraca
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.