Tool/software: TI-RTOS
Dear Community,
I have the following problem that I would like to solve somehow. (RTOS is the latest, and the device is EK-TM4C129EXL)
The uC has different threads that deals with ADC and other IO port management. The ADC generating data and IO is receiving jobs from the outer world. In order to interact with the device MQTT protocol is selected for the latest release but in the previous one, I had a standard TCP/IP protocol with custom packet format. The problem that I would like to handle is how to manage the network communication with the inter thread communication without losing significant time pending on Mailboxes or blocking socket operation.
In the previous design I had a connected socket I shared that in two tasks one is for reading and the other for sending data. The model looks like this one:
socketReaderThread{
// blocking socket read operation
int count = recv(sharedSocket, ..., ...);
// send the request to the right Task based on the request code
Mailbox_post(myTaskMailbox, request, BIOS_WAIT_FOREVER);
}
socketSenderThread{
// waiting for any task response
Mailbox_pend(myTaskMailbox, taskResponse, BIOS_WAIT_FOREVER);
int count = send(sharedSocket, ..., ...);
}
The solution above has a huge advantage, I can send and receive messages immediately as they occurred.
Now I would like to update the communication for MQTT and I have ported the paho C example code ( MQTTPacket) to TI RTOS and here is my problem:
while(1){
// wait for task response, and handle BIOS_NO_WAIT
if(Mailbox_pend(myTaskMailbox, mbResponse, BIOS_NO_WAIT)){
mqtt_pub(socket, mbResponse, ...)
}
// this call blocks the entire task
mqtt_sub(socket, sub_buffer, ...);
}
In the above code the mqtt_sub blocking the entire task based on SO_RCVTIMEO parameter. According to my understanding the value of SO_RCVTIMEO should be large enough to wait for PUB_ACK for my PUB request. (Handle network uncertainty) But 1 second is very long time to block my whole task.
How can I achieve that not to block so long on mqtt_sub?
I don't think that changing the SO_RCVTIMEO is the key for my problem....
Looking forward you kind reply.
PS.: I have implemented a solution where the uC makes 2 mqtt client connection one for publish and one for subscribe. That works very well, but this model results two mqtt clients with duplicated auth, client_id, and displayed as two device in an IoT platform.
Update: I think the non blocking implementation of mqtt for TM4C would be the best. But As I saw there is none.
