Im doing a project where im using tcp sockets on the openMV - that actually works quite well but the usocket.recv() is a blocking operation.
Following general suggestions online in how to do non blocking tcp in python i found the “select” session - and found the uselect library in openMVs micropython - i was happy! but!
Everytime i do anything regarding uselect and usockets the openmv board simply reboots … doesnt even matter HOW simple a piece of code i write is this a known bug/thing?
Or am i missing something?
Like even doing a poll with socketEvent = poller.poll(100) resets the board - no matter the length of the timeout
hmm, doesnt seem im allowed to write the script here - i tried commenting with it - but i keep getting an error about “/posting.php”
But anyways - the code ive attached is just a test script that connects to a wifi then to a tcp server (i wrote one in nodejs - but any tcp server should do)
as soon as the line
fdVsEvents = pollObj.poll(1000)
is run - the board reboots - ive tried this with two separate openMV boards both running firmware 3.2.0
Okay I see the problem, actually we don’t implement select/poll in the WINC1500 driver. The ioctl function is not even set (it shouldn’t crash the cam however, I’ll debug this). You can’t use this module for now, but you can use the set timeout function to zero instead to set the socket to non-blocking (it’s basically the same effect).
i cant for the life of me make this nonblocking - neither settimeout or setblocking commands are doing anything
the openmv cam is the client and server is written in nodejs, do i need something on the server side to fix this?
i might have misunderstood something basic about tcp sockets
i got the timeout to work but now i get access denied when attempting to read from the socket again
do i need to open the connection again to keep reading from the socket? the funny thing is that if i disable the timeout i can keep communicating via the socket
but the program will hang until it gets data from the server
okay, so the plot kind of thickens
I rewrote my code to use MQTT - whenever i use
client.check_msg()
the code hangs like when im doing my own TCP stuff - it seems that something is broken in the way OpenMV handles tcp sockets …
as far as i can tell the mqtt check_msg function should return immediately if there is no message pending from the server - but it doesn’t
okay - so my thinking is that the ping → response cycle is returning something that makes the
socket.recv()
function do it’s thing and allowing the code to progress while still accepting actual messages from the server with data in it - im still pretty new at the whole python and networking thing so this might be wrong or actually the right way to do it - i don’t know - but basically its working as intended now - thx for your help btw
Hi, just wanted to let you know that there were bugs in the WINC1500 driver wrapper, specifically the way timeouts were handled, which affected recv/recvfrom on non-blocking sockets, and check_msg in turn. These bugs are fixed now, setblocking(True/False) should work as expected and you shouldn’t need to call ping before check_msg(). I’ve also added another MQTT example showing how to subscribe to a topic. Thanks for bringing this to my attention.
Note: There fixes will be available in the next release.