ESP8266 Community Forum

- Mon Mar 18, 2019 11:41 am #81178 My first try to bring up the UART bridge and struggling a bit. Using lastest Release 19 (bin), ESP1 successfully flashed and it is in my networks as client. I can access the command port 24.
On ESP1 the TX and RX are wired (expected loop function for test).
Configured each parameter of UART 0 and cw & r. 300e71
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.
Tried a lot, but now I run out of ideas.

Oberservations:
1) bp was initial not set to default 23. It was 0. Could be changed and stored by cw and accessed after reset.
2) bt set to 0 and bridge link is endless open
3) ct default was initial set to 90 not 0 as desribed. Setting to 0, cw, but command port closing after 90sec!
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.

Is it normal, that defauls are not correct (e.g. bp and ct)? Timeout of port 24 normal? Could it be a flash issue?
Any idea how to debug the bridge behavior?
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?

Did not observed any hang-up of command port beside that port closing after 90sec inactivity. Maybe this is interpreted as hang-up.

- Tue Mar 19, 2019 8:15 am #81203

Works wonderful ! i will post a video if anybody is interested.
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

At the moment I am busy ditching the espconnect stuff and replacing it with direct lwip access. It's going along quite fine, but not yet ready. After that I'll probably try to add own-compiled lwip instead of the Espressif pre-compiled one.

Also , i can't figure out pwm and pwm2. i use four gpio pins to control two motors. With all four gpio set as "pwm2" i get nothing. With only two as "pwm2" i get both motos running when i send a "iw 0 4 255" to only one of the pins.
I use gpio 4,5,12,14 on the esp. Are there other "pwm2" capable pins? My "pwm width" is set to 8 bit.

"primary pwm" is working as it should but it has such a low refresh rate. Not ideal for motors.

I never tried the PWM's on motors I must say, only on lighting. Please note that the PWM implementation is not frequency nor phase correct. That means a single period with a higher frequency (glitch) may occur when changing the duty cycle. Lights don't care but motors/driving may do mind. The ATmels worked around this (in their hardware implementation) by mirroring the period, slicing the refresh frequency in half.

PWM can be used on any of the "primary" GPIO's (0-15), not on 16 because that's on the RTC module. PWM2 is using the sigma-delta hardware generator. Sigma-delta (or better: PDM) is not really well-suited to create PWM waveforms, it's created for audio applications where only the density of the pulses is significant and not the frequency. This means there are only 256 duty cycles (8 bit) and the frequency is always 312 kHz (or multiples). Such a high frequency is mostly not suitable for driving motors or power lighting. It can drive all primary GPIO's though. I think it's only suitable to e.g. dim the backlight of a LCD, very low power requirements. If you'd go any higher power, you'd blow the output transistor (e.g. mosfet) very easily. Also note the ESP8266 only hase ONE sigma-delta generator, so all selected pins share the same output.

I think the software PWM (primary) will be much more useful for most purposes. It offers independend duty cycles on all pins (frequency is shared though). And the frequency/width can be configured, where 18 bits = something like 15 Hz (not really useful), 16 bits = 63 Hz and for every bit less, the frequency doubles. Use the "pw" (pwm width) to select.

- Tue Mar 19, 2019 8:18 am #81204

Meanwhile i stumbled upon a bug. I use the bridge to get sensor data. And if i listen with a terminal to the bridge port (23) and send to the command port (24) commands like "l" log or "?" help , the bridge freezes. I have to hard reset in order to get it working again, "r" command it's not doing the trick.
Sometimes it freezes on the first command sometimes i have to send multiple commands but the result is the same.
I tried different bauds 57600 to 250000, no change.
Can you confirm this find?
Thanks

I must say I nearly never use the bridging feature, but I try to test it once in a while. As soon as I am finished with the lwip stuff, I'll try it and possibly fix it, because the changes to the network interface, also have impact on the bridge. Thanks for reporting!

- Wed Mar 20, 2019 5:07 am #81219 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.

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.