Clearing UART buffers

[sprasad]

Hello,
I have connected a GPS module to GPy board and reading NMEA strings from it. My code flow is such that the GPS module keeps on sending data continuously on UART. When I need the GPS data in my application, I read the buffer, parse the buffer for a specific NMEA message and read out the data.
Here, I want to clear the buffers after each successful GPS read. How can I achieve that?
I'm already using uart.deinit() and seems that it is not clearing the buffers.

[jmarcelino]

Hello @sprasad
Can you do a uart.readall() and just ignore the results?

[catalin]

hi @sprasad, if you're using uart.read([nbytes]), or uart.readall() the UART internal buffer is "consumed" and cleared. Isn't this what you want to achieve?

I would call uart.readall() and wait 1 sec (probably NMEA messages are coming 1Hz), so after 1sec I would have in uart buffer the latest messages.

[sprasad]

@jmarcelino @catalin Thank you for the suggestions! Will try this.

[EasyRider]

@catalin

Wipy3 with most recent firmware.
uart.readall()

returns AttributeError: 'UART' object has no attribute 'readall'

is readall() supported in Wipy3 UART class? or am I missing something?

[johand]

@easyrider
Don´t know what the rest of your code does, but this is working just fine for me.

from machine import UART
uart = UART(1, 9600)  
uart.readall()

Johan

[EasyRider]

@johand
Thanks,
I used the same code to test.
Did not work on development version (latest) Pycom MicroPython 1.19.0.b4 [v1.9.4-50f84dd] on 2018-07-13; WiPy with ESP32.

But works on latest stable version 1.18.1.r1.

Would be good to get some clarification as to what is happening on the development version firmware.

[PaulM]

@easyrider I also just isolated, after much painful debugging and wasted time, than my whole system was crashing because of the new "UART' object has no attribute 'readall'" error in the newest firmware on GPy.

This is pretty crazy, since it is a documented function that has always been supported: https://docs.pycom.io/firmwareapi/pycom/machine/uart.html

I do like the vision and philosophy of Pycom boards, but randomly disabling perfectly normal functions is not bound to behoove the success of this product.

[crumble]

Yes, there are may little quirks, which makes life hard.

I ask myself why a simple flush method does not exists. Most people are used to such a simple method. If the micropython guys want to be compatible, implement the f*ing flush parameter of the print statement.

I miss a simple log functionality as well. print shall be able to tee into a file. Or at least the Atom plugin shall do this.

If everyone shal create with the pycom devices, a simple way to debug is needed. Especially on the devices without SPI RAM a well integrated solution is needed too keep the memory footprint low.

[robert-hh]

@crumble That's interesting, especially since the code for readall still exists. It's just the QSTR definition for that API that disappeared.
Reactivating it was not that much of work (just 3 definitions added in 3 files, mods/machuart.c, py/uart.c, py/uart.h). However, uart.read() does the same thing. So at least readall could be kept as an alias to read (1 definition in 1 file to be added, mods/machuart.c).

[bitvijays]

@Gijs Hope you are doing well. Few question.

1. uart.readall function is documented UART. However, as pointed in this discussion, it is not activated. Any particular reason for this?

2. Could uart.readall be activated?

3. Probably a stupid question, What's the size of the buffer of UART? For instance, If I am sending a message of 40000 bytes which ends with a \newline. Does it read it all? or it kinda breaks? Asking, because we need to implement a functionality of receiving large messages without breaking.

Thank you

[johand]

@bitvijays You should use uart.read() instead now, same functionality.

Johan

[robert-hh]

@bitvijays the default rx buffer size us 512. But you can set it when instantiating the uart object with the parameter rx_buffer_size=nnn
Whether that can be set to a value like 40000 has to be tested.

[bitvijays]

This post is deleted!