Giovanni wrote:1) It can be extended with more error codes.
Agreed; however at present this is potentially random. I suggest it would help avoid potential confusion if there were defined blocks of values for specific purposes; in particular a block for user-specific error values. And within Chibi itself, it may be possible to have standard error meanings in some cases.
Giovanni wrote:2) It is a "start" operation, errors should happen during operation. I would not make checks at runtime about parameters etc, code size would go up for no added value.
I was not intending to suggest that checks of no added value were done anywhere; more I was suggesting that checks which do add value are done in the start operation where reasonable; both to give the advice to the caller as soon as reasonable, and to avoid the overhead of starting then aborting an operation.
Giovanni wrote:3) I prefer to keep it simple and do not pass extra parameters, this API would have 2 parameters max, which is very efficient on ARM.
Fair enough (although IIRC for GCC at least, up to 4 parameters are efficient).
Giovanni wrote:5) The config structure would be const, this is why it is in the driver currently, just a note, mutexes do not support timeouts, there is a reason for that (priority inheritance complexity).
It makes sense for the driver to expect a 'const' structure, but obviously that doesn't mean it has to be 'const' outside the driver; I've got code which generates some details of the driver structure at run-time. (Nor does a const driver structure preclude adding a pointer to a mutex).