]> rtime.felk.cvut.cz Git - ortcan-www.git/commitdiff
Some notices about VCA library.
authorPavel Pisa <pisa@cmp.felk.cvut.cz>
Thu, 21 Oct 2010 13:49:22 +0000 (15:49 +0200)
committerPavel Pisa <pisa@cmp.felk.cvut.cz>
Thu, 21 Oct 2010 13:49:22 +0000 (15:49 +0200)
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
index.mdwn
vca/index.mdwn [new file with mode: 0644]

index ce13147ee954ab4e63d0e0937f17a0d1fda22661..c14ab3d8875401a10291d30c1410a0a4eb2aa114 100644 (file)
@@ -5,16 +5,21 @@ What is this?
 
 A collection of [CAN][wp] related tools developed at
 [Czech Technical University in Prague][rtime].
+The development of these components started in frame
+of IST-2001 35102 [OCERA][ocera] European project.
 
 The access to CAN bus requires supported hardware
-inrerface. The project provides CAN device driver
+interface. The project provides CAN device driver
 for Linux and other embedded environments to gain
-acces to the network. The driver is named [[LinCAN|lincan]].
-
+access to the network. The driver is named [[LinCAN|lincan]].
 
+The common interface to access different CAN interfaces
+and library to build higher level layers in implemented
+in Virtual/Versatile CAN API library - [[libVCA|vca]].
 
 [wp]:http://en.wikipedia.org/wiki/Controller_area_network
 [rtime]:http://rtime.felk.cvut.cz/
+[ocera]:http://sourceforge.net/projects/ocera/
 
 News
 ====
diff --git a/vca/index.mdwn b/vca/index.mdwn
new file mode 100644 (file)
index 0000000..aecb5a5
--- /dev/null
@@ -0,0 +1,82 @@
+[[!meta title="libVCA (OrtCAN Virtual/Versatile CAN API library)"]]
+
+The library providing common API for CAN/CANopen bus protocol.
+It can be used with [[LinCAN|lincan]] and [SocketCAN](http://developer.berlios.de/projects/socketcan/)
+Linux drivers. The CANopen part can be used as base for
+implementation of CANopen devices as well as CANopen
+master/monitor nodes.
+
+## VCA CANopen Functionality
+
+### Standard EDS and VCA Hardware Connection Configuration HDS Files
+
+The most comprehensive OCERA RT CAN/CANopen components documentation
+is part of WP7.4 deliverable. But it is quite dated and not fully
+complete, same for some code features. The basic CAN part and river
+has been in production use and is tested and documented in separate file.
+Because OCERA project code base is not maintained as whole for
+some time, we are in process of separation of the parts which
+have been maintained and has potential for future.
+
+As for OCERA CANopen stuff, it has been designed as highly dynamic
+with possibility to mimic different hardware devices and to develop
+complete CANopen master to build dictionary proxies to multiple
+devices for multiple higher level clients. The base infrastructure
+is laid out, we use canblaster to access devices dictionaries
+from Java based CANmonitor and to analyze CAN traffic from Qt based tool.
+
+On the device side, the capability to mimic device dictionary according
+to EDS file is implemented. The HDS is additional description,
+which allows to load shared libraries (DLLs) and map object dictionary
+objects into generic CANopen device binary. This way it is possible
+add new I/O capability without need to rebuild base binary.
+The HDS file maps object dictionary index and subindex to named
+data I/O descriptor DINFOs which are exported by shared library
+object. You can find example of implementation of such module
+in the file
+
+    ortcan-top/app/candev/nascanhw/nascanhw.c
+
+The "nascanhw.so" implements two integer I/O variables (DINFOs)
+"input01" and "output01" which are connected together to copy
+"input01" to "output01" variable. The copy action is then notified
+back into "canslave" generic code. This allow to even map these object
+into PDOs and request to sent PDO on its values changes. The "hardware"
+provided variables are mapped into object dictionary by device
+(Hardware Description File) HDS. The "nascan.hds" is simple example,
+which interconnects the first digital outputs group with with
+the first digital inputs group for DS401 profile device.
+
+    6000:01 /nascanhw/input01 6200:01 /nascanhw/output01
+
+You can test most of build components by script
+
+    ./test-can-in-konsole
+
+The script  test native build of LinCAN in the KDE konsole window.
+This script uses command DCOP scripting capabilities of konsole
+and if it is started from already running console, scripting has
+to be enabled.
+
+Parameter "--script" is required when konsole has been started.
+
+    konsole --script
+
+You can run individual commands by hand as well.
+
+As for whole OrtCAN CANopen implementation, I believe still,
+that it is right way to go to have something generic with possibility
+to integrate into SCICOS or Matlab-Simulink models. There is potential,
+but we have not found project to fund some faster progress
+in the attempt. Basic CANopen infrastructure works but mapping
+is updated only when device is switched from and back to CANopen
+OPERATIONAL state.
+
+The full implementation of all PDO time triggered transfers modes
+is missing. For simple applications, CANfestival is probably
+faster way to go.
+
+You can find some examples even in other project of our department <http://dce.felk.cvut.cz/waszniowski/> On the other hand,
+if you want something runtime configurable, then work with
+OrtCAN sources worth to be considered. CANfestival is not
+prepared nor intended to allow dynamic dictionary operations.