Feedback on uart_swap implementation

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
torwag
Posts: 220
Joined: Fri Dec 13, 2013 9:25 am

Feedback on uart_swap implementation

Post by torwag » Tue Jul 04, 2017 8:15 am

Hey,
I just added and tested a function uart_swap for the esp8266 port. Was wondering what is the usual rule of implementation... should the python function map the original function of the SDK, in e.g. naming and functionality? Should I check how it is done in other ports (e.g. Arduino) to make sure there is some sort of consensus?

The branch can be found here:
https://github.com/torwag/micropython/tree/uart_swap

This implements at the moment two functions within the esp module

Initially at boot and after esp.uart_de_swap():
U0TXD=>pin:U0TXD GPIO1
U0RXD=>pin:U0RXD GPIO3
U0CTS=>pin:MTCK GPIO15
U0RTS=>pin:MTDO GPIO13

After esp.uart_swap():
U0TXD=>pin:MTDO GPIO13
U0RXD=>pin:MTCK GPIO15
U0CTS=>pin:U0RXD GPIO3
U0RTS=>pin:U0TXD GPIO1

This is how it is implemented in the ESP8266 NONOS SDK. I was thinking of having a single function esp.uart_swap(True|False), as I find the esp.uart_de_swap() kind of stupid. This lead me to the above question.

I tested the function by connecting a second FTDI serial module to the ports 13 and 15 on a D1 mini. I can switch forth and back and transfer the REPL successfully on both settings. However, more intensive tests might be necessary to see what happens, e.g. if the IOs are switched in the middle of a uart communication.

The benefit:
1. One can "mute" the USB communication including esp debug messages, which might become handy 2.
2. The usual on-board uart chip does not interfere with a second uart device connected to GPIO 13 and 15.

One problem:
It seems GPIO15 has to be pulled down during boot. Connecting an UART device to GPIO15 might interfere with the boot process. This requires some more testing.


And yes if you give it a try and call esp.uart_swap() the usual REPL over USB is dead by design as it is now swapped ;)

Damien
Site Admin
Posts: 647
Joined: Mon Dec 09, 2013 5:02 pm

Re: Feedback on uart_swap implementation

Post by Damien » Sun Jul 09, 2017 6:28 am

The way that this functionality would be exposed on the Python side is through the UART constructor, being able to specify explicitly the tx and rx pins. The usual way to access the UART peripheral is via:

Code: Select all

uart = machine.UART(0, 9600)
This will configure the UART on the default pins. To put it on other pins one uses:

Code: Select all

uart = machine.UART(0, 9600, tx=machine.Pin(13), rx=machine.Pin(15))
Using the uart swap feature one can implement this for the esp8266. The restriction is that the tx/rx pins must be either 1/3 (the default) or 13/15.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Feedback on uart_swap implementation

Post by pythoncoder » Sun Jul 09, 2017 6:45 am

Using pin 15 for rx may cause problems when connected to an external device because RS232 idles high and ESP8266 boot requires pin 15 to be low. A solution is to ensure that the device is powered up after the ESP8266 has booted. This may be done with a transistor/fet driven by another pin - but the detail depends on the application.
Peter Hinch
Index to my micropython libraries.

torwag
Posts: 220
Joined: Fri Dec 13, 2013 9:25 am

Re: Feedback on uart_swap implementation

Post by torwag » Sun Jul 09, 2017 8:33 pm

@Damien:

Thanks that was exactly the feedback, I was looking for.
I discussed this already with deshipu on IRC and he suggested to add this to the Uart init function as well.
As people can basically switch forth and back at will during execution and as this is only about IO swapping (not buffer), I was wondering, does a uart init call reflect this correctly to the end user? Most people consider to call uart init right at the beginning and only once a time.

I also would like to check how the internal hw-uart buffers behave, performing the swap via init, it makes sens to reset the buffer after each swap (if not done already), as most user would expect a clean buffer after calling init.

I will try to poke around in the esp uart code, see if I could add it there and submit it as a patch proposal, which pfalcon hopefully like ;) . It also requires some explanation in the docs.

@Peter:
Yep, that is exactly what I observed. Not much we could do about it, beside of mention it in the docs.
What a silly choice to combine boot-pin and alternative UART pin on a single GPIO.

qrobot
Posts: 2
Joined: Wed Apr 24, 2019 8:21 am

Re: Feedback on uart_swap implementation

Post by qrobot » Wed Apr 24, 2019 8:24 am

[quote=Damien post_id=20686 time=1499581693 user_id=2]
The way that this functionality would be exposed on the Python side is through the UART constructor, being able to specify explicitly the tx and rx pins. The usual way to access the UART peripheral is via:

[code]
uart = machine.UART(0, 9600)
[/code]

This will configure the UART on the default pins. To put it on other pins one uses:

[code]
uart = machine.UART(0, 9600, tx=machine.Pin(13), rx=machine.Pin(15))
[/code]

Using the uart swap feature one can implement this for the esp8266. The restriction is that the tx/rx pins must be either 1/3 (the default) or 13/15.
[/quote]
I found this configuration method in BBS and the documentation but why did I get an error
bbs:viewtopic.php?t=3533
>>> uart=machine.UART(0,115200,tx=machine.Pin(13),rx=machine.Pin(15))
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: extra keyword arguments given

qrobot
Posts: 2
Joined: Wed Apr 24, 2019 8:21 am

Re: Feedback on uart_swap implementation

Post by qrobot » Wed Apr 24, 2019 9:00 am

I found this configuration method in BBS and the documentation but why did I get an error
bbs:viewtopic.php?t=3533
>>> uart=machine.UART(0,115200,tx=machine.Pin(13),rx=machine.Pin(15)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: extra keyword arguments given

Post Reply