Time triggered PDOs.

diff --git a/vca/index.mdwn b/vca/index.mdwn
index e0da886850c12ac5f95270df900dfe0ec0b72a39..9b61b14d061f2c379bb073942ae1c74bf9a2930f 100644 (file)
--- a/vca/index.mdwn
+++ b/vca/index.mdwn
@@ -82,3 +82,32 @@ There are some examples of its use in other project of our department
 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.