|Home > Iris APIs > Semihosting API > Enabling semihosting input|
Enabling semihosting input typically involves the following steps:
IRIS_SEMIHOSTING_INPUT_REQUESTevent source and optionally
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. The input that they provide might be interleaved and unsynchronized.
IRIS_SEMIHOSTING_INPUT_REQUESTevent. The client might then read from the console or open a terminal window UI, for example. Applications that do not require input do not issue these events.
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 application is not waiting for data, in other words 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 passed to 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 this event, 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.