[[!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/)
+It can be used with [[LinCAN|lincan]] and [SocketCAN][socketcan]
Linux drivers. The CANopen part can be used as base for
implementation of CANopen devices as well as CANopen
master/monitor nodes.
+## VCA Library Quick Build Instructions
+
+The build from GIT repository is recomended. The next commands are used to obtain
+sources
+
+ git clone git://ortcan.git.sourceforge.net/gitroot/ortcan/ortcan
+ cd ortcan/
+ git submodule update --init
+ make default-config
+
+The build components selection and configuration is controlled by "config.omk"
+file which overrides "config.omk-default". The default sources configuration
+builds VCA support for [[LinCAN|lincan]] and [[LinCAN|lincan]] driver is build as well.
+The option for building library sources relinkable into shared objects (DLLs)
+is required for example modules building on x86_64 and PowerPC targets
+
+ echo 'CFLAGS+=-fpic' >>config.omk
+
+Next configuration options should be specified in "config.omk" file
+to build VCA library with [SocketCAN][socketcan] support only
+
+ CONFIG_OC_LINCAN=n
+ CONFIG_OC_ULUTKERN=n
+ CONFIG_OC_CANVCA_IFC=socketcan
+
+The VCA library can be build even with runtime selectable CAN bus
+access support. This is enabled by option "multi" and list of
+interfaces which are compiled into library
+
+ CONFIG_OC_CANVCA_IFC=multi
+ CONFIG_OC_CANVCA_IFC_lincan=y
+ CONFIG_OC_CANVCA_IFC_socketcan=y
+
+The whole tree of sources includes generic CANopen slave
+device implementation ("canslave" executable) which mimics
+standard CANopen nodes implemented by dedicated hardware.
+The OD (CANopen Object Dictionary) is specified at program
+startup by specifying which standard EDS file should be
+parsed to build index and subindex structures of OD.
+The build is controlled by next "config.omk" option
+
+ CONFIG_OC_CANDEV=y
+
+The "canslave" executable can be used not only to provide
+OD behavior for CAN bus remote access but can be used
+without need of recompilation to connect OD data
+with real or simulated hardware data sources. The connection
+is realized by specifying interconnection between
+OD index and subindex entries and named data access
+information structures (DINFO) provided by loadable
+modules. Example of simple example of such module which
+provides two mutually interconnected data items is provided
+in "app/candev/nascanhw/nascanhw.c" source file which is
+build into "libnascanhw.so" module. The build of that example
+module is controlled by next "config.omk" line
+
+ CONFIG_OC_CANSLAVE_NASCANHW=y
+
+The actual build of the libVCA is specified GNu make program
+invocation
+
+ make
+
+The result binaries are found in "\_compiled/bin" after successfull
+build. More information about possible make targets provided
+by underlaying [OMK make system][omk] can be found on its [home page][omk].
+
## VCA CANopen Functionality
### Standard EDS and VCA Hardware Connection Configuration HDS Files
./test-can-in-konsole
-The script test native build of LinCAN in the KDE konsole window.
+The script test native build of [[LinCAN|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.
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
+is missing.
+
+On the other hand for simple applications, [CANfestival](http://sourceforge.net/projects/canfestival/)
+is probably faster and simpler implementation.
+There are some examples of its use in other project of our department
+<http://dce.felk.cvut.cz/waszniowski/>.
+On the other hand, if application is expected to be runtime configurable,
+then OrtCAN approach is better suited for such use. CANfestival is not
prepared nor intended to allow dynamic dictionary operations.
+
+## Time Triggerred CANopen PDO Messages
+
+The VCA code places infrastructure there, but not all features
+are finished. It is waiting to some spare time, project funding,
+students diploma thesis work or contributors.
+
+The PDO can be sent as response to the source value change notification
+over event connectors. This is tested, works and is probably most
+complicated mode if should be done without polling.
+The SYNC driven and time driven modes needs to be implemented.
+The function \_pdo_hub_event() should be divided into part processed
+at variable change notification, which only marks fields requiring
+update and PDO should be moved on list of Tx PDOs which require
+more processing. The second part should do real update and sending.
+Then PDO processor should take PDO from the list, update it and send
+it to the CAN bus. SYNC response would mean only connecting
+of SYNC filer and new rx_hub on PDO processor through
+vcaNet_msg_rec_connect(). SYNC processing would mean only marking PDO
+as requiring to be sent. Each PDO should contain timer field and then
+periodic mode could be implemented as marking PDO to be sent
+in timer call-back.
+
+The function vcaPDOProcessor_processMsg() is alternative to use
+of the full vcaNet_msg_rec_connect() infrastructure.
+So yes, above mentioned functionality of marking
+SYNC triggered PDOs for Tx could be added there.
+The key is to refactor \_pdo_hub_event() function and addition
+of list for PDOs with pending requests.
+
+[omk]:http://rtime.felk.cvut.cz/omk/
+[socketcan]:http://developer.berlios.de/projects/socketcan/
projects / ortcan-www.git / blobdiff