Pycom board: gpy with pytrack 2.0
Firmware version: release='1.20.2.r4' version='v1.11-ffb0e1c on 2021-01-12'
Exact steps to cause this issue:
Create python program with one thread blinking the on board LED once a second and a second thread that uses the LTE class to send an AT command that takes a significant amount of time for a response. A good example is the AT+SQNINS=0 command:
While the AT+SQNINS=0 command is running and awaiting the AT command response, observe that the thread blinking the on board LED is stalled until the AT command completes. This is because the LTE class send_at_cmd holds the MicroPython global interpreter lock through all of the execution of waiting for the response from the LTE modem.
Solution:
Modify lte_send_at_cmd in esp32/mods/modlte.c to release the GIL while waiting for the modem response:
Pycom board: gpy with pytrack 2.0 Firmware version: release='1.20.2.r4' version='v1.11-ffb0e1c on 2021-01-12'
Exact steps to cause this issue:
Create python program with one thread blinking the on board LED once a second and a second thread that uses the LTE class to send an AT command that takes a significant amount of time for a response. A good example is the AT+SQNINS=0 command:
lte = LTE() lte.init() lte.send_at_cmd('AT+SQNINS=0')
While the AT+SQNINS=0 command is running and awaiting the AT command response, observe that the thread blinking the on board LED is stalled until the AT command completes. This is because the LTE class send_at_cmd holds the MicroPython global interpreter lock through all of the execution of waiting for the response from the LTE modem.
Solution:
Modify lte_send_at_cmd in esp32/mods/modlte.c to release the GIL while waiting for the modem response:
--- modlte.c.original 2021-09-24 15:28:29.000000000 -0600 +++ modlte.c 2021-09-24 15:34:58.000000000 -0600 @@ -1280,7 +1280,9 @@ if (MP_OBJ_IS_STR_OR_BYTES(args[0].u_obj)) { size_t len;