UDP request buffer protocol

[krishnak]

 client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    data = b'\x1b' + 47 * b'\0'
    
    client.sendto(data,socket.getaddrinfo(addr,123)[0][4])

    data = client.recvfrom(1024)
    if data:
        t = (struct.unpack('!12I', data)[10])

I get the following error when unpacking TypeError: object with buffer protocol required

Can you please suggest a solution

[davefes]

Maybe a similar issue:
https://github.com/orgs/micropython/discussions/9291

[krishnak]

I have tried the following but it was still complaining with the same error - I had made sure to copy the files to ESP8266 using rshell. However rshell occassionally doesn't copy the files nor display error. And it appears that the file was NOT copied.

This file copy fail happens when the previous python code has exited with some uncaught exception, I have noticed after this the ESP8266 kind of resets several times even when in REPL. I am not sure whether the underlying REPL holds some flag which results in hardware resetting. This reset is a consistent behaviour when there is an uncaught exception.

 data= client.recvfrom(1024)
    strdata = str(data)

[krishnak]

just for clarity this problem has been resolved with the above change.

[davefes]

I often have that behaviour, which is only rectified by an erase and flash a new image.
How you tell it is due to an uncaught exception?

[krishnak]

Do you also have RST crashes when you are connected via REPL

[davefes]

Sorry I don't understand. RST is reset? REPL do you mean webREPL? I only use rshell.

[krishnak]

from rshell do you run the command REPL, are we talking about ESP8266/32?

[davefes]

! I always type repl at the prompt. Yes,ESP32 I gave up on ESP8266 a year or so ago.
What do you see when you get one of these RST crashes?

[krishnak]

RST 2

[davefes]

Ah, after a POWERON_RESET or CTRL-D in rshell. I probably have had many of them, but don't know what it means.

[krishnak]

The RST is mainly due to do with the UART port being connected. I have 3 different ESP32 boards one with ESP32 V3 chip and another 2 with ESP32 V1 chip - all cloned of nodemcu, one of the V1 and V3 RST even when nothing is running but UART/terminal is connected. They don't seem to have any issues if UART is disconnected. I have tested them with plain ESP-IDF C code - it resets irrespective of code.

However I am running micro python on ESP8266 as I didn't want to setup two different build systems in C.

This ESP8266 is a Weimos board - I have not run C code on it as I don't have a build setup for it.
This is more stable than ESP32 in my opinion under the following conditions

1. STA is not active - RST is prominent if STA is inactive and trying to become active, if it was previously active and if you just reenable no resets but if you do sta.active(False) and then do sta.active(True) - it will reset 2 times before stabilising
2. AP is active
3. you have handled asyncIO properly.
4. Don't use gc.collect() this keep triggering RST as some asyncio resource gets garbage collected.

[robert-hh]

@krishnak recvfrom() returns a tuple consisting of data and addr. So you could change your script for instance to:

client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
data = b'\x1b' + 47 * b'\0'
    
client.sendto(data,socket.getaddrinfo(addr,123)[0][4])

data, addr_s = client.recvfrom(1024)
if data:
    t = (struct.unpack('!12I', data)[10])

[krishnak]

Hi it works with the changes I have posted above, it was an issue of the changed file not getting copied to the device which resulted in this thread.