* Always clear the peripheral interrupt so we don't hang when full
* Store the ringbuf in the object so it gets collected when we're alive
* Make UART objects have a finaliser so they are deinit when their
memory is freed
* Copy bytes into the ringbuf from the FIFO after we read to ensure
the interrupt is enabled ASAP
* Copy bytes into the ringbuf from the FIFO before measuring our
rx available because the interrupt is based on a threshold (not
> 0). For example, a single byte won't trigger an interrupt.
Testing performed: That a card is successfully mounted on Pygamer with
the built in SD card slot
This module is enabled for most FULL_BUILD boards, but is disabled for
samd21 ("M0"), litex, and pca10100 for various reasons.
Ujson should only worry about whitespace before JSON. This becomes apparent when you are using MP stream protocol to read directly from input buffers.
When you attempt to read(1) on a UART (and possibly other protocols) you have to wait for either the byte or the timeout.
Fixes:
- Waiting for a timeout after you have completed reading a correct and complete JSON off the input.
- Raising an OSError after reading a correct and complete JSON off the input.
- Eating more data than semantically owned off the input buffer.
- Blocking to start parsing JSON until the entire JSON body has been loaded into a potentially large, contiguous Python object.
Code you would write before:
```
line = board_busio_uart_port.read_line()
json_dict = json.loads(line)
```
or reaching for fixed buffers and swapping them around in Python.
Code that did not work before that does now:
```
json_dict = json.load(board_busio_uart_port)
```
- This removes the need for intermediate copies of data when reading JSON from micropython stream protocol inputs.
- It also increases total application speed by parsing JSON concurrently with receiving on boards that read from UART via DMA.
- It simplifies code that users write while improving their apps.
Surely readline() "rtype" is string not int as stated (and not bytes as some might expect).
Also it is not totally unambiguous what happens on a timeout so it would help to clarify in docs that on a timeout
it does NOT return with what it has read so far, rather it leaves all that in the buffer ready for a future read and returns nothing.
Likewise clarify that if timeout=0 but there is no newline it DOES return what it has read so far (NOT None).
At least this is what I think it does and/or is supposed to do!
Python docs are generally not too explicit about what is the proper treatment, so perhaps all the more reason to
clarify the interpretation adopted?
ajs256
Scott Shawcroft
microDev
Dan Halbert
Lucian Copeland
Taku Fukada
dherrada
dherrada
Scott Shawcroft
Jeff Epler
Jeff Epler
Mark Olsson
warriorofwire
dherrada
AndrewR-L
Dave Marples