micropython-async icon indicating copy to clipboard operation
micropython-async copied to clipboard

StreamReader sreader.read() not works on asyncio v3.

Open beyonlo opened this issue 5 years ago • 2 comments

Hi Piter.

I have this code already perfect working in my application running on MicroPython 1.11.0, using asyncio v2 of course:

async def uart_receive():
    sreader = asyncio.StreamReader(uart)
    while True:
        await asyncio.sleep(1)
        res = await sreader.read()
        print('Received from UART: {}'.format(res))

Now I trying to port it to v3 (using MicroPython 1.12) , but this code not works anymore on uasyncio v3. I have this error:

Task exception wasn't retrieved
future: <Task> coro= <generator object 'uart_receive' at 3f8200e0>
Traceback (most recent call last):
  File "uasyncio/core.py", line 1, in run_until_complete
  File "umain.py", line 177, in uart_receive
TypeError: function takes 2 positional arguments but 1 were given

Ps: if I change from sreader.read() to sreader.readline() works on uasyncio v3, but I want to continue to use sreader.read().

Thank you so much.

beyonlo avatar Aug 20 '20 14:08 beyonlo

Looking at the source, the MicroPython implementation requires a value n being the number of characters to read. However the CPython docs has:

coroutine read(n=-1) Read up to n bytes. If n is not provided, or set to -1, read until EOF and return all read bytes. If EOF was received and the internal buffer is empty, return an empty bytes object.

Given that uasyncio V3 is intended to be CPython compatible, in my opinion the absence of a default is a bug. I have raised this issue.

The meaning of EOF depends on context. In the case of input from a file it's self-evident, but in the context of a communication link it is less so. I avoid relying on EOF in communications contexts.

peterhinch avatar Aug 21 '20 10:08 peterhinch

@peterhinch

The meaning of EOF depends on context. In the case of input from a file it's self-evident, but in the context of a communication link it is less so. I avoid relying on EOF in communications contexts.

Yes, exactly that's my goal to continue to use read(), because I have no EOF on my UART communication.

Thank you so much to open the issue.

Have a nice weekend!

beyonlo avatar Aug 21 '20 12:08 beyonlo

This was fixed by the maintainers.

peterhinch avatar Nov 25 '22 10:11 peterhinch