Closed borancar closed 5 years ago
Simpler option: add success return value to existing ECALL_SEND() / ECALL_RECEIVE()
Added to multizone-sdk v1.1.0
hexfive-kern a77b8ec4 hexfive-lib 51ee472 hexfive-conf afccb61
Enhanced ECALL_SEND() / ECALL_RECEIVE()
ECALL_SEND() return 1 if the inbox was empty and the message written to the inbox return 0 if the inbox was not empty the message not written to the inbox
ECALL_RECEIVE() return 1 if the inbox was not empty and the message written to memory return 0 if the inbox was empty and the message not written to memory
Note: inbox is not empty when a message was sent but not yet received inbox is empty when no message was sent or the message was sent and received
Note: traps messages are always delivered even if there is an unread message in the inbox ECALL_RECEIVE() no longer clears the inbox with zero values
EXAMPLE (blocking):
Zone1 (producer):
int msg[4]={'T','E','S','T'};
while (!ECALL_SEND(2, msg)) ECALL_WFI();
Zone2 (consumer):
int msg[4]={0,0,0,0};
while (!ECALL_RECEIVE(1, msg)) ECALL_WFI();
To provide guaranteed streaming delivery in https://github.com/hex-five/multizone-secure-iot-stack, we needed to create mzmsg, examples https://github.com/hex-five/multizone-secure-iot-stack/blob/master/zone1/mzmsg.c and https://github.com/hex-five/multizone-secure-iot-stack/blob/master/zone2/main.c#L171.
mzmsg adds complexity and performance overhead and will need to be reinvented for every case. It would be simpler to provide send and recv methods that return success/failure. This could be used to offer queue sematics. E.g.
for send
for recv
Having these available makes the whole concept of mzmsg redundant and eliminates the need for decoupling queues, saving RAM in the zones.