Main Page | Directories | Namespace List | Class Hierarchy | Alphabetical List | Class List | File List | Namespace Members | Class Members | File Members | Related Pages | Examples

Central Scheduler of IsoAgLib

All periodic activities of the IsoAgLib are controlled by the class IsoAgLib::iScheduler_c. This strategy is independent from any timers and timer interrupts of the target system, so that the application designer can use all interrupts of the CPU for the application specific stuff.

Timing of Execution for Scheduled Activities

Avoid Parallel Calls of IsoAgLib API Functions

Important:
Please don't call the function IsoAgLib::iScheduler_c::timeEvent() from interrupts, which could be triggered during the procession of API functions which are called from the normal application context. The API functions of the IsoAgLib can only guarantee that the internal state of the library is consistent after the function returns. If an interrupt function ( i.e. higher level function context ), calls another API function of the IsoAgLib inbetween, this function can't work correct. Moreover it will probably lead to an undefined state of the complete library. If you ultimatively want to call API functions of the library from different execution levels ( parallel tasks which could interrupt each other ), please implement some semaphor function on your own.

Valid Stop of Execution of Scheduled Events

If yout just want to stop the execution of the periodic scheduled activities, to perform some very important work, you can call IsoAgLib::iScheduler_c::forceExecStop(). The IsoAgLib will then return from the timeEvent() triggered functions to the earliest possible time - while leaving everything in a valid state. This is provided by a central timestamp, which tells all timeEvent functions within the IsoAgLib when the execution must be returned back to the caller. The call of forceExecStop() simply resets this timestamp, so that the nearest point for valid stop of execution will be used.

Define Time of Return from Scheduled Event Execution

But this call of IsoAgLib::iScheduler_c::forceExecStop() shouldn't be the standard way to control the end of execution in the IsoAgLib. The preferred way for strictly scheduled return from execution in the IsoAgLib::iScheduler_c::timeEvent() action cycle is the use of the optional argument ri32_demandedExecEnd in IsoAgLib::iScheduler_c::timeEvent( int32_t ). The given timestamp will be stored in the above mentioned timestamp variable, which will be checked by each scheduled function on each execution point, where the IsoAgLib will stay in a valid state. These decision points are distributed with a fine granularity, as the time check is implemented with a quick access on a global variable. If no execution end is specified, all periodic actions are performed, and all received CAN messages are processed.

Overview on Scheduled Activities

The IsoAgLib is designed to deliver several internal background services, which can be controlled and stimulated by API function calls. This allows the concentration of the application developer on the specific topics, while all standard activities are realized as automatic as possible.

Processing of Received CAN Messages

All received CAN messages, which should be stored by the target specific HAL implementation in ( circular ) puffers, are interpreted by the __IsoAgLib::CANIO_c::timeEvent() and the internal called __IsoAgLib::CANIO_c::processMsg() function. After delegating each message to the corresponding communication class, the individual reaction os performed.

Periodic Activities for Local Identities and Monitor Lists

Especially the DIN 9684 protocol requires the periodic send of some preparing messages before adress claim and the contiuous send of alive messages after adress claim. Additionally all dead node entires are erased from the monitor lists, if they didn't send their alive message for more than three seconds. Similarly the ISO monitor IsoAgLib::iISOMonitor_c can optionally erase all nodes from the monitor list, which didn't answer the last "request for claimed adress" call within the standard time interval.

Periodic Send of Base Data

If IsoAgLib::iBase_c was configured to send some base data types , the timeEvent() call is used provide the periodic data send. But as long as the default configuration isn't actively changed after the start of the IsoAgLib, no periodic action is scheduled for IsoAgLib::iBase_cc_c.

Periodic Send of Process Data

If a remote system starts a measurement program, which requires the send of current data on some individual events ( time or distance proprotional, etc. ), this is provided by the scheduling function of the IsoAgLib. Thereby the application developer doesn't have to cope with the possibly parallel measurement program requests from several other ECUs for different process data types. All the application has to do for local process data instances is to update the measurement value, and react on received setpoints.

Continue Data Stream Upload

A running data stream upload is feeded by the scheduled timeEvent() calls. On each activation the current send state is evaluated and the possibly needed send of next CAN messages is triggered.

Select and Activate DIN Terminal Mask Upload

As the IsoAgLib enables the parallel registration of individual binary mask pools for different "LBS+" terminals ( f.e. old pre ISO 11783 version of AGCO Fendt Varioterminal ), the library must decide after the complete address claim of the local DIN 9684 identity and based on the monitor lists, which registered mask pool must be activated. This activation is realized by the creation of the process data variables, which are requested by the terminal before starting the upload. As identical ( corresponding to WERT/INST definition ) process data variables can use individual values for different terminals, and as the creation of all possible process data would cause too much RAM overhead, the activation is eprformed selectively.

Spool Attribute Changes

The IsoAgLib tries to send the attribute change CAN messages immediately after the corresponding change function is called. But as the procotol standard demands the wait for ACK of the last change command, before the next can be sent, a circular puffer is used to spool the updates in FIFO order.
Generated on Wed Oct 13 15:16:14 2004 for IsoAgLib by  doxygen 1.3.8-20040913