Huh!

Things I Don't Completely Understand.

This is going to be a collection of topics and hints at possible answers that I cannot find authoritative answers to. Or haven't looked long enough. Hints come from various sources such as issues postings, discussions, etc.

Frequent reboots

From time to time I read about stability problems that are resolved by adding pull-up resistors or making existing resistor value smaller or adding caps.

• One person's noise handling mod.
  • 100nF from the reset pin to the GND near the reset pin (WROOM).
  • 10nF at the Reset switch (from reset to ground)
  • 2.2KOhm at the backside from the reset via to the 3.3V via nearby.
  • Short connections. No other wires.
• Some schematics show a 480 Ohm resistor between the Reset pin and the reset switch.
• One site also indicated that adding a pull-up resistor to the Rx Data pin resolved their problem, the presumption being that noise was generating spurious interrupts.
• GPIO-15 is another pin that deserves more scrutiny. Most module schematics I have looked at used a lightweight 12K pulldown resistor. When you consider that the built-in pull-up can be as low as 30K, which is active on powerup and reset, the resulting voltage on the pin is at or just above the minimum for a logic 0. This leaves no room for noise immunity. An exception was Adafruit's feather Huzzah schematic showed a 4.8KOhm pull-down, good job.

Interesting Note on ESP8266 programming

ESP8266 contention during programming Found this from this posted issue

Also interesting GPIO-0 behavior during normal boot

Statement from an Xpressif person on GPIO-0 behavior

GPIO-0 outputs the clock frequency of the external crystal(e.g. 26MHz) by default, which cannot be modified. While you can modify the function of GPIO0 in your code, before the program starts to run, GPIO-0 will still output the clock frequency of the external crystal.

RESET is level trigged and the hold time of low voltage needs to be at least 100us.

To do list:

• Look at ways to use the presence of 26MHz signal on GPIO-0.
• Can we detect when the driving signal starts.

The correct situations to use: delay(0), delay(1), yield(), and optimistic_yield().

delay() and yield() are basically understood; however, there appear to be some finer details to be understood. I cannot find any formal description of optimistic_yield() and its use.

Develo - devyte posted:

Note: if the code here must yield, the correct way is with a delay(0) as originally proposed. That will yield when in CONT, and do nothing when in SYS. In contrast, optimistic_yield() only skips yield when called too soon after loop() entry.

Develo - devyte posted:

The wifi callbacks execute in the SYS context, and you can't yield/delay in there. If you need to do that, I suggest to use the wifi callback to schedule another callback with your code that requires yield/delay. Scheduled functions execute as though they were called from the loop, I.e. in CONT context.

Same thing as the Ticker callback, etc.

In general, you should not do heavy operations in any callback. There are timing restrictions to observe.

delayMicroseconds(1000) is not interchangeable with delay(1). delayMicroseconds() does not call yield(); delay() will call yield().1

How delay() works from Dave Sislakd

Excellent and long writeup here.
TODO: update as discussion continues.

Need a better understanding of references to CONT vs. SYS

hint

reference to cont_t

No question Not Multithreaded

A Comment

New function polledTimeout

see source PolledTimeout.h

Split IRAM into 2 linker sections to move std::fcn

This is coming in a future release. Described here Develo has a warning