Use a formatting function to give more human-readable output formats
for flash bandwidth. When the test starts and ends in less than one
millisecond, report as "Infinite".
Sample output:
````
Creating 512KB file, may take a while...
==> Time to write 512KB in 256b chunks = 6641 milliseconds
==> Created file size = 524288
Reading 512KB file sequentially in 256b chunks
==> Time to read 512KB sequentially in 256b chunks = 211 milliseconds = 2.48 MB/s
Reading 512KB file MISALIGNED in flash and RAM sequentially in 256b chunks
==> Time to read 512KB sequentially MISALIGNED in flash and RAM in 256b chunks = 212 milliseconds = 2.47 MB/s
Reading 512KB file in reverse by 256b chunks
==> Time to read 512KB in reverse in 256b chunks = 367 milliseconds = 1.43 MB/s
Writing 64K file in 1-byte chunks
==> Time to write 64KB in 1b chunks = 1249 milliseconds = 52.47 KB/s
Reading 64K file in 1-byte chunks
==> Time to read 64KB in 1b chunks = 296 milliseconds = 221.41 KB/s
````
esp_yield() now also calls esp_schedule(), original esp_yield() function renamed to esp_suspend().
Don't use delay(0) in the Core internals, libraries and examples. Use yield() when the code is
supposed to be called from CONT, use esp_yield() when the code can be called from either CONT or SYS.
Clean-up esp_yield() and esp_schedule() declarations across the code and use coredecls.h instead.
Implement helper functions for libraries that were previously using esp_yield(), esp_schedule() and
esp_delay() directly to wait for certain SYS context tasks to complete. Correctly use esp_delay()
for timeouts, make sure scheduled functions have a chance to run (e.g. LwIP_Ethernet uses recurrent)
Related issues:
- #6107 - discussion about the esp_yield() and esp_delay() usage in ClientContext
- #6212 - discussion about replacing delay() with a blocking loop
- #6680 - pull request introducing LwIP-based Ethernet
- #7146 - discussion that originated UART code changes
- #7969 - proposal to remove delay(0) from the example code
- #8291 - discussion related to the run_scheduled_recurrent_functions() usage in LwIP Ethernet
- #8317 - yieldUntil() implementation, similar to the esp_delay() overload with a timeout and a 0 interval
- =default for default ctor, destructor, move ctor and the assignment move
- use `std::unique_ptr<WiFiClient>` instead of raw pointer to the client
- implement `virtual std::unique_ptr<WiFiClient> WiFiClient::clone()` to safely copy the WiFiClientSecure instance, without accidentally slicing it (i.e. using the pointer with incorrect type, calling base WiFiClient virtual methods)
- replace headers pointer array with `std::unique_ptr<T[]>` to simplify the move operations
- substitute userAgent with the default one when it is empty
(may be a subject to change though, b/c now there is a global static `String`)
Allow HTTPClient to be placed inside of movable classes (e.g. std::optional, requested in the linked issue) or to be returned from functions. Class logic stays as-is, only the underlying member types are changed.
Notice that WiFiClient connection object is now copied, and the internal ClientContext will be preserved even after the original WiFiClient object was destroyed.
replaces #8236resolves#8231
and, possibly #5734
These changes are needed to address bugs that can emerge with the improved optimization from the GCC 10.3 compiler.
Updated performance inline functions `mmu_get_uint8()`, ... and `mmu_set_uint8()`, ... to comply with strict-aliasing rules.
Without this change, stale data may be referenced. This issue was revealed in discussions on https://github.com/esp8266/Arduino/issues/8261#issue-963529268
Changes to avoid over-optimization of 32-bit wide transfers from IRAM, turning into 8-bit or 16-bit transfers by the new GCC 10.3 compiler. This has been a reoccurring/tricky problem for me with the new compiler.
So far referencing the 32-bit value loaded by way of an Extended ASM R/W output register has stopped the compiler from optimizing down to an 8-bit or 16-bit transfer.
Example:
```cpp
uint32_t val;
__builtin_memcpy(&val, v32, sizeof(uint32_t));
asm volatile ("" :"+r"(val)); // inject 32-bit dependency
...
```
Updated example `irammem.ino`
* do a simple test of compliance to strict-aliasing rules
* For `mmu_get_uint8()`, added tests to evaluate if 32-bit wide transfers were converted to an 8-bit transfer.
When reading from a `Stream`, like `File`, using a temporary buffer is counterproductive because it complexifies the code and increases memory usage.
It's also a source of confusion because it can create dangling pointers in the `JsonDocument`.
The only benefit of using a buffer is the reading speed, but I don't think speed is the focus in this example; if it were, it would use a buffer in `saveConfig()` too.
A function called with a flash string, which only has an implementation with `const String&` as argument will be compiled as if it is called with a `String` constructor wrapped around it.
For example this implementation in the .h file:
```c++
bool startsWith(const __FlashStringHelper *prefix) const {
return this->startsWith(String(prefix));
}
```
This is completely useless as the compiler will generate exactly the same code with or without this function implementation in the .h file.
However if we move the implementation to the .cpp file, this conversion to `String` is only added once in the compiled binary.
In my own project I already managed to shrink the largest (ESP32) build by more than 70k in size (!!) by just adding extra function calls with the conversion in the .cpp file.
This PR is just a simple optimisation which already shrinks a very small build of my project by almost 3k in build size. (custom_beta_ESP8266_4M1M PIO env of ESPEasy)
```
Flash: [======== ] 82.5% (used 862137 bytes from 1044464 bytes)
Flash: [======== ] 82.3% (used 859545 bytes from 1044464 bytes)
```
Larger builds may benefit even more.
* Respect linking order of libraries
Now has the same order as the Arduino IDE does with its platform.txt
* Remove double-referenced libs
* Change implementation style
Instead of injecting at magic indices, which might break when some other extra-scripts inject other libraries, let's create the LIBS array at the bottom in easy to understand and correct order.
When LittleFS.begin() or SDFS.begin() is called after the filesystem is
already mounted, don't unmount/remount. When an unmount happens, all old
Files become invalid (but the core doesn't know this), so you would end
up with random crashes in FS code.
Now, check for _mounted, and if so just return immediately from begin().
This mimics the original SPIFFS code.
Fixes https://github.com/earlephilhower/ESP8266Audio/issues/407
* Fix PRxxx printf format macros
Update toolchain (newlib) to supply proper definitions for PRxxx macros.
Fixes#8220
Added a PRxxx macro to an example to ensure CI will catch any problem like
this in the future.
When Python is installed on Windows separately (i.e. Windows Store,
Python.org MSI, etc.) it set the PYTHONHOME environment variable to
the installed path.
When we call our own portable Python, it tries to use the support
PYC files in PYTHONHOME. If they're from a different version of
Python, however, they won't work. Even though we're running our
own distributed Python.exe, we are crashing on the system-wide
Python installation.
Add -I to all python3 calls, ignore PYTHONHOME/etc. environment vars.
Tested under Ubuntu 18.04 Linux w/o any ill effects (we ship pyserial
ourselves and add it manually to the Python search path).
Fixes#8096, or should as I understand it.
* Recover the BearSSL crash stack before the Heap is initialized and zeros it.
* Added comments for hwdt_pre_sdk_init()
* Keep Basic ASM version of app_entry_redefinable and removed alternate "C"/Extended ASM version. Update comments.
* Improved example HwdtStackDump to use StackThunk
When using previous IDE versions, the use of an invalid category value caused a warning to be displayed on every compilation:
WARNING: Category 'Network' in library lwIP_PPP is not valid. Setting to 'Uncategorized'
WARNING: Category 'Network' in library lwIP_enc28j60 is not valid. Setting to 'Uncategorized'
WARNING: Category 'Network' in library lwIP_w5500 is not valid. Setting to 'Uncategorized'
WARNING: Category 'Network' in library lwIP_w5500 is not valid. Setting to 'Uncategorized'
List of valid category values:
https://arduino.github.io/arduino-cli/latest/library-specification/#libraryproperties-file-format
MMU option with 48K IRAM shared. This happended after changes that
increased IRAM code size that caused free IRAM for Heap to fall
below ~16K, then "new" would OOM out in WiFiClientSecureBearSSL.
Added private function to try IRAM first then switch to DRAM on fail
to WiFiClientSecureBearSSL for iobuff allocations.
* Make mkdir.py work unter python3 versions below 3.5
Because early versions of python3 did not have the optional arg "exist_ok" for "pathlib.Path(...).mkdir(...)" a build under this versions will abort with an error message.
This PR will modify the python script so that it works even under python 3.4 (and below).
* Added comments for ets_install_uart_printf and corrected it usage.
* Correct case for hotkey 'p'.
Added conditional build around option 'p' to call stack_thunk_dump_stack
which can only print when debug is enabled.
* Create pins_arduino.h
* Update boards.txt.py
* Update boards.txt
* done a "boards.txt.py --allgen"
* Removed the definition of LED_BUILTIN from variants/wifi_kit_8/pins_arduino.h, because this board has no build in lED
* Copy released JSON to board URL, not new one
Fixes#8180
The draft release generates a ZIP and JSON. Instead of rebuilding the ZIP
on the publish step (which may result in a different SHA256 due to file time
differences in the new ZIP), just copy the one from the published release
directly.
Also clean up and remove unneeded environment variables and CI steps.
* Be more paranoid about JSON format, check after d/l
Fix release packager issue. Seems when variable set in $GITHUB_ENV
quotation marks are not removed, resulting in URLs with
http://ddd.dd/blah/"3.0.1"/release and JSON entries with the same
quotation problem.
* Don't crash when includeing LittleFS.h w/no FS
The LittleFS constructor could cause a divide-by-zero error and crash the
chip during pre-main startup (i.e. when the constructors were called).
Avoid by only initializing the LittleFS control structure when there is
a filesystem specified in the flash layout.
* Be even more paranoid on begin() and format()
