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.
  • Update: Looking at this pin on an Oscilloscope at reset, you can see the effects of the internal pull-up resister against the external 10K Ohm pull-down while the reset pin is held low about 0.8 volts. It quickly goes to zero when the RST is released. I need to look at Boot ROM code listings, but I suspect that they remove the pull-up before reading the pins state for determining boot mode. At least I hope they do.

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

cont_t

Defines a structure to hold resources for a sketch to run in. It defines three major elements:

• A 4KB Stack
• The context, pc_ret and sp_ret, we were in before the stack/task switch. These are set by cont_run().
• The context, pc_yield and sp_yield, we were at when our task did a yield. These are set by cont_yield().

cont_yield

Swaps control to allow the SYS, NONOS SDK an opportunity to run.

Overview

The NONOS SDK runs tasks. Toward the end of user_init() a task, loop_task, is created. loop_task() is scheduled and run by the NONOS SDK. From this function, a call is made to cont_run() which handles saving the calling context and switching to the cont, sketch's, stack, and running loop_wrapper().

If while running loop_wrapper(), a call is made to cont_yield() the current PC and SP are saved (pc_yield and sp_yield) and control is passed back to pc_ret and sp_ret that were saved a cont_run() entry. . And thus cont_run() returns and the task exits.

The next time the task is run, execution resumes after the cont_yield() call via the saved pc_yield and sp_yield.

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