diff -r 000000000000 -r 4472ee7c6c3e doc/canfestival_scheduling.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/canfestival_scheduling.svg Wed May 10 16:59:40 2006 +0200 @@ -0,0 +1,855 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + CanFestival Scheduling + + + + + + Alarm A value + + + + + + + + + + + Alarm Bvalue + Alarm Bperiod + + Alarm Bperiod + + + + + Alarm Bperiod + Alarm Bperiod + + + Clock range + t0 + t1 + t2 + t3 + t4 + t5 + t6 + t7 + t8 + Clock value + Time + + A CanOpen must be able to take delayed actions. As exemples, periodic sync emission, heartbeat production or SDO timeout need to set some alarms that will be called later and do the job.µC generaly do not have many anough free timers to handle all the CanOpen needs directly. Moreover, CanFestival internal data may be corrupt by reentrant calls. CanFestival implement a mini-scheduler (timer.c). It uses only one timer to mimic many timers. It manage an alarm table, and call alarms at time.Scheduler can handle short clock value ranges limitation found on some µC. As an example, value range for a 16bit clock counter with 4µs tick is crossed within 0.26 seconds... Long alarms must be segmented.Chronogram illustrate a long alarm (A) and a short periodic alarm (B), with a A value > clock range > B value. Values t0...t8 are successive setTimer values. t1 illustrates an intermediate call to TimeDispatch, caused by a delay longer than clock range. At the end of t1, TimeDispatch call will not trig any alarm callback. + + + HW interfaces + + + + + SCHEDULINGtimer.cSetAlarmDelAlarmTimeDispatch + + + + SYSTEM TIMERSINTERFACE(timers_xxx.c)setTimergetElapsedTime + + + + + + + + + + + + + + + + + + + + + + CanFestival Library + + + + + + + + + + + + Application + + + Callbacks + + + + + + +