
CHAPTER 5 SYNCHRONOUS COMMUNICATION MANAGEMENT
User’s Manual U14833EJ2V0UM
50
5.3
Event Flags
In multitask processing, an intertask wait function is required in which other tasks wait to resume execution of
processing until execution of a given task is complete. To support this function, event flags are provided in the
RX4000 to allow other tasks to judge whether or not the “processing complete” event has occurred.
An event flag is a set of data consisting of 1-bit flags that indicate whether a particular event has occurred. The
event flags used in the RX4000 are 32 bits, which are handled as a set of information with each bit or a combination of
bits having a specific meaning.
5.3.1
Creating event flags
Event flags can be created either by issuing the service call (a)cre_flg, or by specifying the static API CRE_FLG,
which performs equivalent processing to (a)cre_flg when the system is initialized.
If (a)cre_flg is issued, the attribute, initial counter value, and maximum counter value (etc.) are stored in the block
corresponding to the ID number that specifies the event flag control block area secured as an array, and that control
block is then initialized.
The event flag ID number consists of a unique number of a value 1 or higher. The maximum value that can be
specified is the one defined in the system information table, up to a maximum of 0x7fff numbers.
Any 32-bit value can be specified for an event flag’s initial bit pattern.
5.3.2
Deleting event flags
An event flag is deleted by issuing the service call del_flg. When del_flg is issued, the kernel invalidates the
specified event flag control block and puts the target event flag in the non-existent state.
Even if a task exists that has satisfied the wait release conditions for the deleted event flag, that event flag will still
be deleted. In this case, all the waiting tasks are released from the waiting state and the error code E_DLT indicating
that the event flag has been deleted is returned as the return value of the service calls wai_flg and twai_flg.
After an event flag is deleted, an event flag with the same ID number as the deleted event flag can be newly
created.
5.3.3
Waiting for events
To wait for the establishment of an event using an event flag, the required bit pattern is specified for either wai_flg,
twai_flg, or (i)pol_flg, which is then issued.
When one of these service calls is issued, the kernel compares the bit pattern of the event flag when the service
call was issued with the specified bit pattern, and determines whether an event has been established based on the
wait conditions described later.
If an event has already been established, the service call is immediately terminated normally, allowing task
processing to continue. If an event is not established, wai_flg and twai_flg make the task wait: until the event flag
satisfies the wait release conditions in the case of the former, and until either the event flag satisfies the wait release
conditions or a specified time has elapsed in the case of the latter. The issuance of (i)pol_flg results in a service call
error, and the task is informed that an event was not established.
Note that event flags have two attributes: TA_WSGL and TA_WMUL, and those with the former attribute cannot be
simultaneously held by multiple tasks (whereas those with the latter attribute can). Accordingly, if wai_flg, twai_flg, or
(i)pol_flg is issued for an event flag with the attribute TA_WSGL already being held by a waiting task, an error occurs
unconditionally, regardless of whether an event was established or not, and the error code E_OBJ is returned.
Because event flags with the attribute TA_WMUL can be held by multiple tasks, waiting tasks with event flags are
registered in the waiting task queue, either in FIFO or priority order (TA_TFIFO and TA_TPRI attribute respectively). If
(i)set_flg is issued, the kernel determines the wait release conditions of the tasks in the order of this waiting task
queue.