Changes between Version 8 and Version 9 of Developer/Simulators/QEMU/CANEmulation

Timestamp:

06/03/13 00:57:51 (11 years ago)

Author:

C Rempel

Comment:

Developer/Simulators/QEMU/CANEmulation

@@ -2 +2 @@
 
 =  Device Requirements  =
+
+# sends CAN packets from a guest OS.
+=  Use Cases / Testing  = 
+the best option is to implement that as simple
+device
+  -device can-kvasser-pcican-q
+or 
+  -device pcican,model=kvasser-pcican-q
+and use Linux mainlined SocketCAN API to connect virtual device
+to real CAN hardware (SocketCAN allows multiple applications access)
+or to SocketCAN Virtual CAN (vcan - TCP/IP lo equivalent).
+This is straightforward and would result in minimal overhead and latency.
+
+The OS will be Linux and the current CAN driver to test will be Socket CAN (as it's maintlined into Linux)=  Excerpts from the email chain  =
 
 '''Stefan Weil''': PCI (and USB if they were supported with LinCAN) CAN controller boards
@@ -57 +71 @@
 '''Paulo B''':
 Ok, learnt a bit more...  You could probably implement this in two ways:
-1) "-netdev socket" would probably work as a CAN->UDP gateway; 2)
+1) "-netdev socket" would probably work as a CAN->UDP gateway; 
+
+2)
 connecting to a virtual CAN interface in the host, created using
 SocketCAN (similar to "-netdev tap", e.g. "-netdev cantap").
@@ -77 +93 @@
 several CAN buses.
 
-Each CAN controllerwas a TCP client connected to the CAN bus emulation.
+Each CAN controller was a TCP client connected to the CAN bus emulation.
 
 The TCP clients sent CAN data packets (length, packet type and data)