ESP8266 Community Forum

- Thu Mar 21, 2019 10:58 am #81245

My first try to bring up the UART bridge and struggling a bit. Using lastest Release 19 (bin), Can open bridge port configured under bp with putty, switching local echo to off, but get no echo via bridge, so UART bridge seem not to work. I connected in RAW mode of putty.

As @holopaul already discovered, there seems to be bug in the current version regarding network bridging. I am going to look into it soon. Much of the code needs to be rewritten anyway due to my change from the netconn to the raw lwip interface. It probably got broken when I implemented the led pixel interface, which is quite demanding on the UART (and control code). You might want to try an older version, that does not yet have led pixel support.

Oberservations:
1) bp was initial not set to default 23. It was 0. Could be changed and stored by cw and accessed after reset.

That is intentional. It saves frequent polling and data moving code to be run if the bridge is not used. So you need to enable it explicitly. This may not be reflected in the documentation.

3) ct default was initial set to 90 not 0 as desribed. Setting to 0, cw, but command port closing after 90sec!

That's interesting. I was under the impression the timeout (for both) wasn't used anymore. If it's not already out, I am will probably remove it soon. The rationale is that UDP doesn't have a concept of connection and TCP does, but you can always replace an existing connnection with a new one, so it doesn't hurt if an existing connection is hogged by some runaway device.

4) command like s, wcc, sc working. sc-task uart posted increased by two when pressing key+CR in bridge port terminal. task uart failed stuck at 643. uart updated counted frequently.
5) using uw 0 123456 but no reception on putty terminal.

That will probably the aforementioned bug.

Maybe the new inverting function does have also wrong default and one of RX / TX is inverted? How to check or to be configured in non inverting mode?

Improbable, I tested it. Check the flags with "fs".

- Thu Mar 21, 2019 11:15 am #81246

Please tell me if i can send same command to different ledpins with "ism" command? so i can preset some led animation without sending individual led commands.

That is an interesting idea. Something more general indeed, to address multiple pin's from one I/O in one go. It would need some sort of mask though, or multiple combos of pin=value. Added to the todo list

I was thinking, you might be interested in the built-in sequencer. It may not be documented at all.

The concept is like this:

• you can store instructions into flash memory, combination of I/O, pin, value and wait-time
• these "programs" can be terminated using a NULL instruction (use entry "delete" command)
• this way you can make multiple programs at different "addressess" (sequencer entry number)
• you can start a program at any entry number and the entry at #0 can be selected as auto-run after startup

You could make a "program" for setting some of the I/O's to certain values and use that instead of discrete "io-write" commands. Or maybe the whole program can be written to the sequencer. The sequencer uses four pages of flash, every entry is 8 bytes, so in theory you could use up to 2048 entries...

Related commands:

• sequencer-clear (sec): clear / initialise flash memory for use by sequencer (no parameters)
• sequencer-remove (ser): remove one entry, specify the entry number
• sequencer-add (sea): add one entry, parameters <entry number> (-1 = autoincrement) <io> <pin> <value> <duration>. Note that the value is NOT reverted after the duration, so if you only need to set a value, just specify 0 for duration.
• sequencer-list (sel): list the 20 sequencer entries from last requested entry (no parameter) or specify the entry to start
• sequencer-start (ses): start sequencer, specify the starting entry and the amount of repeats
• sequencer-stop (set): stop sequencer
• sequencer-stats (ss): list stats

- Thu Mar 21, 2019 11:26 am #81247

My post about UART bridge stucked a bit in the forum.
In meanwhile I managed to work the UART bridge.
For all other with same problem to start UART bridge:
im 0 1 uart and im 0 3 uart configuration was missing. This should be mentioned in any documentation.
Anyway, it works perfect and stable also with port 24 open in parallel.

As said, the documentation is not up to date, due to lack of interest. What you "discovered" is completely true and intentional. The UARTs are no longer by default connected to the relevant I/O pins. That's because you may want to use them for other purposes (which is very well possible) and you don't want the interference of the UART.

Interesting fact is that I ran into this "feature" myself not so long ago, and had myself wondering for a few hours why the UART didn't work (for a debugging session). Most of the time I do have other I/O stuff connected to GPIO 1 and GPIO 3, though, like PWM or I2C.

BTW: during RX/TX measurement (all flags set to "no", so ne debung etc), i observed during startup some bytes on TX, which is o.k for my application but in general not very optimal.

Yes I am aware of that. Unfortunately that is unavoidable. The ESP boot loader changes the pins to UART mode and starts sending some data (the well-known ets,jan 2013 stuff). Only after that my application is started and the UART is disconnected or hushed from SDK debugging output.

If you really need to avoid any bogus output on the UART, you'd need a hardware solution, like an analog mux that disconnected the output for a few milliseconds after powerup and reset.

- Sun Mar 24, 2019 5:21 am #81310 Thanks for response.
Unfortunatly my application still not work with UART bridge (just the local loop with wire works).
I am reading an electric meter of house installation by orange Pi zero and want to exchange it by ESP-01.
The electric meter require 300bd 7E1.
So, I start debugging and find out, that UART is correctly configured with 7bit, even parity, one stop bit but the TX send 8bit!
Sending ASCII 1234 resulting in:
01000110011 00100110011 01100110001 00010110011
In bold the unwanted 8th bit.

According http://bienonline.magix.net/public/esp8266-faq/8E-ESP8266__Interface_UART__EN_v0.2.pdf the 8266 supporting 7bit mode.

I changed the configuration to 6 and 8 bit with cw and r, re-check after restet, but data format on TX is always the same - so I guess it will not be configured at all. Can you please check?