Feedback on uart_swap implementation
Posted: 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
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