ESP8266 Community Forum

- Fri Apr 05, 2019 7:56 pm #81592 Hey Erik,

How are you running your UARTs? Are you using hardware/software interrupts or tasks or some other method?

I guess because it was working nice and fast before the network code change, that must be where the problem is... was just thinking out loud

- Sat Apr 06, 2019 2:09 pm #81597 What do you mean by software interrupts?

The problem is not in the UART, it's in the networking code (due to the switch to direct LWIP API). And the problem has been solved about a week ago.

There are two reasons I am not releasing the current state of the code:
- it's very much in flux, due with even more LWIP work, I am trying to get it working from a static memory area instead of using the SDK's pvPortMalloc and friends. I don't trust these (like most code from Espressif) and also, when using static memory, there will never be surprises.
- at the moment I am rewriting the config code, which is quite a task, but the end result will give me an additional 8 kbytes of RAM to work with, which I need to run stable.

The code at this moment is not always stable, I don't think it's wise to use it.

For your information, the UART is used as efficiently as possible. When the internal receive FIFO of 128 bytes is filled for a few bytes and/or no data has entered for a few UART clocks, the UART interrupts and the complete FIFO is fetched into a round-robin queue of 1024 bytes. This is to keep interrupt code as small as possible. Then a task is "posted" and the task will read all of the round-robin queue and send it in chunks as large as possible to the TCP or UDP address.

For sending on the UART, the network code will put anything it receives into another 1k round-robin queue, which is transferred into the UART internal 128 byte send FIFO until it's full. When there is some space available, the UART sends an interrupt and the FIFO is once again filled with more data from the round-robin queue.

As said, the extra layer of round-robin queues (which are very efficient and low overhead) is required to make the interrupt service routines finish as soon as possible. The design of this has not changed for a long time.

I now have TCP and UDP data throughput at 250-450 kbytes per seconds which I think will be sufficient for your purpose and also will be at least as fast as before, but probably faster.

If you're very adventurous you might want to do a compile run yourself and try it out.

- Mon Apr 08, 2019 9:20 pm #81630 I'm likely missing some simple documentation somewhere, but I was hoping you could quickly point me in the right direction.

I'm currently unable to get a persistent output from a pin set to autostart. My desired result is to have the equivalent of a `iw 0 0 1` at boot/startup.

I'm using an "ESP-01S Relay v4.0" (https://github.com/IOT-MCU/ESP-01S-Relay-v4.0). I've tested on multiple ESP-01s

At startup:

Code: Select allconfig-dump
flags=258 (258/258)
wlan.mode=0 (0/0)
wlan.client.ssid=XXXX (0/0)
wlan.client.passwd=xxxxxxxx (0/0)
io.0.2.mode=1 (1/1)
io.0.2.llmode=1 (1/1)
io.0.2.flags=0 (0/0)
io.0.0.mode=3 (3/3)
io.0.0.llmode=3 (3/3)
io.0.0.flags=1 (1/1)

slots total: 160, config items: 10, free slots: 150

im 0 0
io[0]: Internal GPIO@00
  pin:  0, mode: digital output       [hw: digital output] flags: [autostart], output, state: off, max value: 1, info:


Manually after startup:

Code: Select alliw 0 0 1
digital output: [1]
im 0 0
io[0]: Internal GPIO@00
  pin:  0, mode: digital output       [hw: digital output] flags: [autostart], output, state: on, max value: 1, info:

- Tue Apr 09, 2019 1:05 pm #81640 Yeah, the documentation... I stopped to bother when nobody cared

The basics from the documentation are still valid, but I've change a few things here and there.

Your approach to what you're trying to achieve is sound, I don't see a problem, this should work (setting I/O to digital output and setting autostart on it).

What is it exactly what you're experiencing? There may be a very short spike/glitch when powering on, due to SDK booting code doing all kinds of weird things with the hardware. That's something I can't prevent. Does it come "on" at all, or only after the spike?

If we can't get it to work this way, we could always try the (built-in) sequencer But this is very basic functionality, it should simply work. What version are you using? The current "pre-release" version isn't really release-ready, there are lots of open ends that need fixing (and most of them already are, in the code, in the meantime).