|Home > Iris APIs > Semihosting > Semihosting input interface|
Semihosting input is implemented using event sources and functions.
Enabling semihosting input typically involves the following steps:
IRIS_SEMIHOSTING_INPUT_UNBLOCKEDevent sources using
eventStream_create(). This step tells the global instance that this client is able to provide semihosting input. If multiple clients activate these event sources, they all receive these events, and also they all might provide input that is interleaved and unsynchronized.
IRIS_SEMIHOSTING_INPUT_REQUESTevent. The client might read from the console or open a terminal window UI, for example.
read()call, the semihosting implementation issues an
IRIS_SEMIHOSTING_INPUT_UNBLOCKEDevent. The client can then close the terminal window or simply ignore this event.
semihosting_provideInputData()at any time, even if the running application is not waiting for data. This can happen before an
IRIS_SEMIHOSTING_INPUT_REQUESTor after an
IRIS_SEMIHOSTING_INPUT_UNBLOCKEDevent. In these cases, the semihosting implementation must buffer the data for subsequent reads. Sending user input to the model before the first
IRIS_SEMIHOSTING_INPUT_REQESTmust assume that the
RAWfield is False. This means user input should be fed into the model when the user presses the
Enterkey, in other words terminal cooked mode.
The following rules apply to buffering the data that is provided by
semihosting_provideInputData(). They are only relevant when the semihosting implementation must handle megabytes of input data, for example from streams or files. For interactive user input, they are not relevant and can be ignored:
IRIS_SEMIHOSTING_INPUT_REQUESTevent. After receiving an
IRIS_SEMIHOSTING_INPUT_REQUESTevent, the client can send a maximum of
SIZEHINT+ 1MB of data, because this event indicates that all previous data has been consumed. This ensures that the model only needs to buffer at most 1MB in addition to the currently requested data size, assuming only a single client is pushing data. The client effectively controls the buffer size in the model. The advantage over the model limiting the data size is that the client can choose a suitable behavior when more data becomes available. For example, it can block the thread that produces the data, or it can discard unwanted data.