From 71d007c92096eba4e70889fa2a523cebf592f372 Mon Sep 17 00:00:00 2001 From: Pavel Pisa Date: Thu, 21 Oct 2010 15:49:22 +0200 Subject: [PATCH] Some notices about VCA library. Signed-off-by: Pavel Pisa --- index.mdwn | 11 +++++-- vca/index.mdwn | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 90 insertions(+), 3 deletions(-) create mode 100644 vca/index.mdwn diff --git a/index.mdwn b/index.mdwn index ce13147..c14ab3d 100644 --- a/index.mdwn +++ b/index.mdwn @@ -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 index 0000000..aecb5a5 --- /dev/null +++ b/vca/index.mdwn @@ -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 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. -- 2.39.2