[Feature]:Review changes to sdsWrite

[ReinhardKeil]

This change should be reviewed.

6310dae

sdsWrite delivers SDS_NO_SPACE - that should trigger a thread switch at the level of sdsWrite - not at the level of the user application.

At least documentation needs to be updated.

This is related with: #268

[MiloradCvjetkovic]

Since sdsWrite is a non-blocking function, it may return the SDS_NO_SPACE error if the I/O transfer rate is insufficient or the available buffers are too small to absorb transfer latency.

When this occurs, the application must either wait until sufficient buffer space becomes available to write the next record or discard the record. Because discarding a record would break the synchronization between input and output records, the application instead stalls until enough space is available.

Under normal operating conditions, where the I/O throughput is sufficient and the buffers are adequately sized, sdsWrite should never return SDS_NO_SPACE.

Currently, all sdsWrite calls in the application handle this condition in the same way by waiting until space becomes available, see:

• SDS-Framework/template/algorithm/sds_main.c

  Line 191 in 6310dae

  ret = sdsWrite(sds_data_in_id, timeslot, algo_data_in_buf, sizeof(algo_data_in_buf));

• SDS-Framework/template/algorithm/sds_main.c

  Line 209 in 6310dae

  ret = sdsWrite(sds_data_out_id, timeslot, algo_data_out_buf, sizeof(algo_data_out_buf));

This is only a template implementation, the user is free to change it.

What solution do you propose @ReinhardKeil ?

[ReinhardKeil]

I believe a osThreadYield should do the job.

But this depends on #268
We should therefore know how the priorities are defined.