Using the tx/rx pins not for UART

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
HenningA
Posts: 5
Joined: Sat Sep 17, 2016 3:45 pm
Location: Germany

Re: Using the tx/rx pins not for UART

Post by HenningA » Wed Oct 05, 2016 9:29 am

Hi Brad,

I had some spare time an looked at your patch. The only thing I'm missing is where you set uart_os. That's in eps.debug I guess?

brad
Posts: 7
Joined: Sun Jul 17, 2016 12:36 pm

Re: Using the tx/rx pins not for UART

Post by brad » Wed Oct 05, 2016 11:54 am

When you call esp.osdebug(None), it sets uart_os = -1.
Within the esp8266 port, search for uart_os_config in modesp.c and uart.c.

My patch extends the existing meaning of (-1) to fully decouple UART from REPL.

User avatar
deshipu
Posts: 1388
Joined: Thu May 28, 2015 5:54 pm

Re: Using the tx/rx pins not for UART

Post by deshipu » Wed Oct 05, 2016 12:33 pm

I'm not sure it's a good idea. For instance, I normally disable the debug messages (because I have no use for them and they are annoying), but still want to use the UART REPL...

brad
Posts: 7
Joined: Sun Jul 17, 2016 12:36 pm

Re: Using the tx/rx pins not for UART

Post by brad » Wed Oct 05, 2016 12:40 pm

Agree, overloading the semantics of esp.osdebug(None) is not a good long-term solution. There are several alternatives, the simplest of which might be to create a new constant, e.g. NO_UART_REPL=(-2) and invoke esp.osdebug(NO_UART_REPL) instead. It's on my todo list to evaluate a better API for this - just haven't had time to look at it lately. Would love to hear suggested alternatives!

HenningA
Posts: 5
Joined: Sat Sep 17, 2016 3:45 pm
Location: Germany

Re: Using the tx/rx pins not for UART

Post by HenningA » Thu Oct 06, 2016 7:00 am

Wouldn't it be smart to set a flag when micropython-serial opens the UART? This could work automatically.

brad
Posts: 7
Joined: Sun Jul 17, 2016 12:36 pm

Re: Using the tx/rx pins not for UART

Post by brad » Thu Oct 06, 2016 1:03 pm

I like that idea - explicitly initializing the UART would disconnect the REPL from it. Nicely avoids the issue of inventing an API to do this. The drawbacks would be no way to change the baud rate for REPL, no way to reverse the operation (get the REPL back) without reboot, and no mixing "raw" UART I/O with REPL. Perhaps we could add an 'ioctl' to switch the REPL flag in case someone wants to mix modes.

HenningA
Posts: 5
Joined: Sat Sep 17, 2016 3:45 pm
Location: Germany

Re: Using the tx/rx pins not for UART

Post by HenningA » Fri Oct 07, 2016 7:54 am

Hi Brad,

I'm not 100% sure but I think in the ESP-toolchain (or in the LUA-Firmware?!) there is a function to swap the pins of UART 0 to 2 other pins. That could maybe also used, just disconnect REPL when using the UART on the other to pins. But this is also a rather dirty hack

Reconnecting the REPL to the UART at with your patch at the moment works by just setting esp.osdebug(True). I've just tested this. So it should be no big deal to reconnect the REPL

Is see two ways:
Is there an REPL module that can be accesed from python? Then we coul make some connect(UART01)/disocnnec(UART01) function

Other way: REPL always connected to STDIO an somewhow connection/disconnection STDIO via sys (?!)

mikronauts
Posts: 13
Joined: Thu Nov 03, 2016 10:12 pm

Re: Using the tx/rx pins not for UART

Post by mikronauts » Thu Nov 03, 2016 11:52 pm

I also need to decouple the hardware uart from REPL

Perhaps something like the following in boot.py

import repl

with one of:

repl.telnet(port)
repl.web(port)
repl.serial(bps)

with say port/bps=0 stopping it? Not really important for me, I just want to choose the repl interface in boot.py

Now of course Wifi would have to be enabled/set up before the telnet/web versions...

User avatar
ernitron
Posts: 89
Joined: Fri Jun 03, 2016 5:53 pm
Location: The Netherlands

Re: Using the tx/rx pins not for UART

Post by ernitron » Fri Dec 09, 2016 9:20 am

UP

I just would like to know what is the actual status of decoupling REPL from UART. This is fundamental to access peripherals that talk binary over uart/serial lines. I almost succeded to have meaningful replies from a PZEM004t power meter and the Control-C characters mess up with the communication (and just dont want to use C and Arduino sdk for esp!).

I also tried to apply the patch of @Brad (thank you btw), without success as probably that patch refers to to an old version of upython.

Besides I do think that a programmatic way to disable the repl from UART is needed (there always will be webrepl).

Thanks

User avatar
ernitron
Posts: 89
Joined: Fri Jun 03, 2016 5:53 pm
Location: The Netherlands

Re: Using the tx/rx pins not for UART

Post by ernitron » Sun Dec 11, 2016 9:18 pm

I solved it!
This is the ONE LINE solution.

Code: Select all

--- esp8266/uart.c	2016-12-09 16:16:43.936221129 +0100
+++ esp8266/uart.c.original	2016-12-09 11:06:36.377927859 +0100
@@ -171,7 +171,6 @@
         while (READ_PERI_REG(UART_STATUS(uart_no)) & (UART_RXFIFO_CNT << UART_RXFIFO_CNT_S)) {
             uint8 RcvChar = READ_PERI_REG(UART_FIFO(uart_no)) & 0xff;
             if (RcvChar == mp_interrupt_char) {
-                ringbuf_put(&input_buf, RcvChar); // Erni T.
                 mp_keyboard_interrupt();
             } else {
                 ringbuf_put(&input_buf, RcvChar);
One of the problem of my code was that 0x03 (the interrupt/control-c) was breaking the serial flow. It was not sufficient to trap the uart.read(), because the byte was missing from the serial line buffer. So the solution was simply to patch the uart.c routine in micropython to simply push it back into the serial line buffer. The Keyboard Event is still there and the try/except is simply to pass.

Now for those curious, this is the beast (yes, I am really proud of it!). It features:
- Power meter by means of the notorius PZEM004t (a hell of a chinese power meter)
- WeMos D1 Mini
- SSD1306 OLED Shield
- Independent Power Supply
- My own web server and code. Also it saves data on my personal IoT cloud server for nice graphics...
- A lot of work and swear and pain and joy... well you know ;)

Now few things:
- WeMos but also Lolin V3 are pretty robust when it comes to voltages. PZEM004 works with TTL levels and WeMos/Lolin work with 3.3. I did NOT use any ttl converter. Even the resistor suggested somewhere (https://wifi-iot.com/?m=wiki&id=15) was more harmful than useful.
- You might say that I am very close to fry my chip but I am positive they won't ;)
- I haven't seen any other binary data messing up with uart repl. I made a lot of trials disabling debug, sending Control-A to go in raw mode, but nothing was necessary.
- I didn't even connect to ground anything (). SO I guess there are some floating voltage around. But I think I will try to ground the circuits.
- I think the key to stability is the independent power supply.
. I didn't get the KWh but just followed the instructions from chinglish.

After all I think this works with some magic. For those interested I think I will put all on github... and no, I will not publish anything on instructables or hackster.. or anything. Just bewteen the few of this community and me...;)
Attachments
2016-12-11 21.29.19.jpg
screenshot
2016-12-11 21.29.19.jpg (66.53 KiB) Viewed 10487 times
2016-12-11 21.29.19.jpg
power meter
2016-12-11 21.29.19.jpg (148.02 KiB) Viewed 10487 times

Post Reply