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

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

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

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

 _______ 
(  ___  )
| (   ) |
| |   | |
| |   | |
| |   | |
| (___) |
(_______)
         

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 communicate with the HW CAN controller, upto 1 MBit/s * a CAN transceiver might be added to v3.x so at90can128 can be used for 1Mbit/s with the HW CAN controller * VemsFrontier/Networking/Caraca does not allow small uC with UART but without CAN controller HW (most notably atmega88/168) to talk CAN at any reasonable bitrate, especially with executing useful functions at the same time. '''Physical layer overview: why we like CAN transceivers everywhere''' * 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 on physical layer.''' * '''ARM processors with CAN controllers''' and onboard '''CAN transceivers are preferred''' (because they are real CAN, upto 1Mbit/s ). On ARM uCs, we add CAN transceiver also on an UART (besides the CAN controller ports). * on small uCs, without CAN controller, but with HW UART (most notably atmega88/168) '''CAN transceiver is added to the UART TX/RX'''. This allows a 115200 bit/s networking (naturally not compatible with the 1Mbit/s CAN buses), that is identical to CAN from the application's point of view (but firmware driver layer is different). Datalink layer is similar to modbus over serial so UARTs are used efficiently. * '''most minimal designs: FBUS is freely available with any uC''' we use * bigger boards will also feature connectivity solutions (max232 or similar on a HW UART) 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''' - dropped 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''' ---- '''I2C and I2C-CAN''' * I2C I guess I2C would work the same way (between boards) as 1-wire. Very well with good grounds. Trash with ground-problems. If someone makes proper GND and GND5 network, I2C would work. But there is high risk people would tend to power big boards (unintentionally) through the SDL/SDC lines (like they not-so-rarely forget GND5 and power from GND5 despite all bold warnings) * I2C over CAN phy to remote MAX7313 or 6956 seems good first, but 2xCAN transceivers needed, MAX GPIO is expensive (compared to say atmega168, or even AT91SAM7A3) and trash logistics. I2C would need same software as the CAN-UART implementation (which needs only 1 CAN-transceiver). ---- '''LIN protocol''' - an alternative '''TODO: reevaluate it''' * 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, IMHO. ---- '''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. '''Any decision on this?''' ---- '''Conclusion''' It's very important to understand: '''having''' the displays (GBA, IPAQ, round see note below) that only support UART, we really have no other options: '''we must make CAN-UART work'''. * If we had to make CAN-UART without dedicated master, especially in 3..5 kbyte flash, we'd be in deep problem. Fortunately the CAN-UART with a minor restriction (one ARM-master required per bus) is only a tiny bit more complex (firmware-wise) than using real CAN: * in the network, '''we'll require to have an ARM device on the CAN-UART bus. The CAN-UART bus will not be operable without this master'''. This relieves us from the extreme stress to roll the bus-master-code (or even worse, a token-bus like arbitration protocol) in 3..5 kbyte flash on AVR core. This is not a serious drawback, we can use a powerful ARM-based boostcontrol dongle or VemsFrontier/ArmUfo to be master (we'll design these anyway). * we'll need to be smart with the pricing (of course): price of network install of 4 ECM-s shouldn't cost more than 2.5 x price of 1. The only way this can be handled technologically is '''relatively cheap HW and suitable software licencing'''. Notes: * even if we were fast to roll new displays (which we are NOT, remember?), most chips that are optimal for displays simply have no CAN. While they have all have UART (1 Mbit/s capable). So the displays not having CAN is by no means an accident. Also, the packet-length of CAN (8 byte payload) is a bit restrictive for displays, CAN-UART beats real CAN in this manner. * the IPAQ also has USB '''device''' connection, but '''not USB-host'''. So connecting to another chip with only USB-device is out of the question. ---- '''See also''' * VemsFrontier/Networking/Caraca * http://en.wikibooks.org/wiki/Robotics:_Computer_Control:_The_Interface:_Networks * http://en.wikibooks.org/wiki/Embedded_Systems/Common_Protocols
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.