MicroPython Forum (Archive)

ESP UART lacks deinit method, but documentation states it exists?

>>> from machine import UART
>>> dir (UART)
['__class__', '__name__', 'any', 'read', 'readinto', 'readline', 'write', '__bases__', '__dict__', 'init']
>>>

Reference https://docs.micropython.org/en/latest/ ... .UART.html...

UART.deinit()¶

Turn off the UART bus.

Using the stable image...

>>> import os
>>> os.uname()
(sysname='esp8266', nodename='esp8266', release='2.2.0-dev(9422289)', version='v1.19.1 on 2022-06-18', machine='ESP module with ESP8266')

It seems that uart.deinit() exists for most ports except ESP8266. Maybe because the one UART of the ESP8266 is used for REPL. What did you want to achieve using uart.deinit()?

P.S: There is a discplaimer somewhere at the beginning of the documentation that not all documented properties apply to all ports. But sometimes it might be better to just implement a dummy method.

Nothing specific, just happened to setup a WiFi class that I planned to use across various device types, ESP, Pico, etc., and since I wrote the class testing on Pico first, when I tested the class on ESP, kaboom. This is another of several now, deltas that I have found that is not expected per expectation set by the published documentation. And thus I have documented as issues. So just raising awareness of the issue. It really does seem the official documentation fails to itemize exceptions consistently.

Either a dummy method, or just footnote the documentation, which is already there for some features, that say 'This feature is only applicable to ports X, Y, Z.'

I suggest, at a minimum the documentation should be corrected. Frankly, the noted disclaimer is bad form, a cheap and easy excuse not to be accurate over time. Strongly believe, good and accurate documentation is important to open-source survival. If the only documentation that is consistent is commercial source/solutions this really does hurt open-source.

I worked as a QA/QC engineer for years, and routinely kicked back bad documentation to peers, and often took heat for it. But 99% of the time I got the documentation corrected, or even worse the code corrected as needed. Thus, believe strongly in accurate documentation, meaning if you take the time to write it, take the time to update it, IMHO. I understand that best efforts are often done, but strongly suggest such disclaimers should not be used at all, or even as a fall back.