asyncWait()request. When the second request is issued (assuming
timeout1 < timeout2and existing wait mustn't be stopped), the Driver must prevent the completion of the currently scheduled timer countdown being reported in interrupt context while interfering with an update to internal data structures. The interrupts are disabled by calling
suspendWait()member function of the Device. The call to the
true, which means the interrupts are successfully disabled and it is safe to update internal data structures. If the call to
false, it means that the interrupt has already occurred and there is no existing wait in progress, i.e. the second
asyncWait()actually becomes a first one in the new sequence.
timeout2 < timeout1which means the order of the timeout requests must be re-evaluated, and new wait re-programmed.
InterruptCtx()tag parameter passed to the
startWait()member function of the Device. It indicates that the request is executed in interrupt context, while the same request used
EventLoopCtx()as the tag parameter to specify that the call was performed in event loop (non-interrupt) context.
allocTimer(). It is used to allocate the
Timerobject. All the wait and/or cancel requests are issued to this timer object directly, which is declared to be a
friendof the Driver class, i.e. it is able to call private functions of the latter using the handle it has. The destructor of the
Timermakes sure that the handle is properly invalidated.
WaitTimeUnitDuration) is declared to be 1 millisecond. Please note that
startWait()member function expects to receive number of wait units, i.e. milliseconds as its first parameter.
asyncWait()member function of the Driver may be defined like this:
embxx::driver::TimerMgris defined like this:
TDevicetemplate parameter is Platform specific control class for timer peripheral.
TMaxTimerstemplate parameters specifies the maximal number of timer objects the
TimerMgrwill be able to allocate. This parameter is required because
embxx::driver::TimerMgrwas designed to be used in the systems without dynamic memory allocation. If dynamic memory allocation is allowed, then it is quite easy to implement similar functionality without this limitation.
embxx::driver::TimerMgrexposes the following public interface:
embxx::driver::TimerMgrexposes only one public function:
Timer allocTimer();. This function returns simple
TimerMgr::Timerobject which can be used to schedule new wait as well as cancel the previous wait request. Also note that
TimerMgr::Timerclass is declared to be a
TimerMgr. This is required to allow seamless delegation of the wait/cancel request from
TimerMgrwhich is responsible for managing multiple simultaneous wait requests and delegating them one by one to the the actual hardware control object.
embxx::driver::TimerMgris a generic Driver class that does most of the work of managing and scheduling independent wait requests. It requires support from low level timer Device object to program the actual hardware of the platform the code runs on. The
embxx::driver::TimerMgris defined to receive the Device class as template parameter as well as reference to the Device timer object in the constructor. The Driver doesn't know the exact Device type, but expects it to expose certain public interface:
WaitTimeUnitDurationtype as variation of std::chrono::duration that specifies duration of single wait unit supported by the Device.