arduino/esp8266
1
0
Fork 0
mirror of https://github.com/esp8266/Arduino.git synced 2025-09-05 08:04:28 +03:00
Code Activity
Files
6280e98b0360f85fdac2b8f10707fffb4f6e6e31
esp8266/package
History
Earle F. Philhower, III 6280e98b03 Enable exceptions, update to optimized newlib, migrate to new toolchain (#5376) 
* Move to PROGMEM aware libc, allow PSTR in printf()

A Newlib (libc) patch is in progress to move the _P functions from inside
Arduino into first-class citizens in libc.  This Arduino patch cleans up
code that's been migrated there.  Binaries for the new libs are included
because it seems they're part of the Arduino git tree, and should be
replaced with @igrr built ones when/if the Newlib changes are accepted.

Notable changes/additions for Arduino:
Allow for use of PROGMEM based format and parameter strings in all
*printf functions.  No need for copying PSTR()s into RAM before printing
them out (transparently saves heap space when using _P functions) and
makes it easier to print out constant strings for applications.

Add "%S" (capital-S) format that I've been told, but cannot verify,
is used in Arduino to specify a PROGMEM string parameter in printfs,
as an alias for "%s" since plain "%s" can now handle PROGMEM.

Optimized the memcpy_P, strnlen_P, and strncpy_P functions to use 32-bit
direct reads whenver possible (source and dest alignment mediated), but
there is still room for improvement in others.

Finally, move several constant arrays from RODATA into PROGMEM and
update their accessors.  Among these are the ctype array, ~260 bytes,
mprec* arrays, ~300 bytes, and strings/daycounts in the time
formatting functions, ~200 bytes.  All told, sketches will see from
300 to 800 additional RAM heap free on startup (depending on their
use of these routines).

* Fix merge error in #ifdef/#endif

* Fix host test using the newlib generic pgmspace.h

Host tests now use the sys/pgmspace.h for compiles instead of the
ESP8266-specific version.

* Update with rebuilt libraries using latest newlib

* Include binaries built directly from @igrr repo

Rebuild the binaries using a git clone of
https://github.com/igrr/newlib-xtensa

Build commands for posterity:
````
rm -rf ./xtensa-lx106-elf/
./configure --prefix=<DIR>/esp8266/tools/sdk/libc --with-newlib \
            --enable-multilib --disable-newlib-io-c99-formats \
            --disable-newlib-supplied-syscalls \
            --enable-newlib-nano-formatted-io --enable-newlib-reent-small \
            --enable-target-optspace \
            --program-transform-name="s&^&xtensa-lx106-elf-&" \
            --disable-option-checking --with-target-subdir=xtensa-lx106-elf \
            --target=xtensa-lx106-elf
rm -f etc/config.cache
CROSS_CFLAGS="-fno-omit-frame-pointer -DSIGNAL_PROVIDED -DABORT_PROVIDED"\
             " -DMALLOC_PROVIDED" \
  PATH=<DIR>/esp8266/tools/xtensa-lx106-elf/bin/:$PATH \
  make all install
````

* Fix merge define conflict in c_types.h

* Fix strlen_P misaligned source error

Include fix from newlib-xtensa/fix-strlen branch cleaning up misaligned
access on a non-aligned source string.

* Fix strlen_P and strcpy_P edge cases

Ran the included test suite on ESP8266 tstring.c with the following defines:
 #define MAX_1 50
 #define memcmp memcmp_P
 #define memcpy memcpy_P
 #define memmem memmem_P
 #define memchr memchr_P
 #define strcat strcat_P
 #define strncat strncat_P
 #define strcpy strcpy_P
 #define strlen strlen_P
 #define strnlen strnlen_P
 #define strcmp strcmp_P
 #define strncmp strncmp_P

Uncovered edge case and return value problems in the optimized versions of
the strnlen_P and strncpy_P functions.  Corrected.

* Fix memcpy_P return value

memcpy-1.c test suite showed error in return value of memcpy_P.  Correct it.

* Fix strnlen_P/strlen_P off-by-4 error

Random crashes, often on String constructors using a PSTR, would occur due
to the accelerated strnlen_P going past the end of the string. Would make
debug builds fail, too (ESP.getVersionString() failure).

Fix to fall through to normal copy on a word that's got a 0 byte anywhere
in it.

* Add device tests for libc functional verification

Add test suite used to debug libc optimized _P functions to the device
tests.

* Rebuild from igrr's repo (same source as prior)

Rebuild .a from igrr's repo at 347260af117b4177389e69fd4d04169b11d87a97

* WIP - add exceptions

* Fix exception to have 0-terminator

* Move some exception constants to TEXT from RODATA

* Remove throw stubs

* Move more exception stuff to ROM

* Enable exceptions in platform.io

* Remove atexit, is duplicated in rebuilt lib

Need to look at the quick-toolchain options, there seems to be a definition
for atexit defined there (libgcc?) that needs to be excised.  For now,
remove our local do-nothing copy.

* Update libgcc to remove soft-fp functions

The esp-quick-toolchain generated libgcc.a needed to have the soft-FP routines
that are in ROM removed from it.  Remove them in the new esp-quick-toolchain
and update.

* Fix merge typos in Makefile

* Add unhandled exception handler to postmortem

* Return our atexit() handler

* Latest stdc++, minimize exception emercengy area

* Remove atexit from newlib

atexit was defined in newlib strongly, but we also define a noop atexit in core.
Since we never exit, use the core's noop and delete the atexit from libc.a

Updated in esp-quick-toolchain as well.

* Move __FUNCTION__ static strings to PROGMEM

__FUNCTION__ is unlikely to be a timing sensitive variable, so move it to
PROGMEM and not RODATA (RAM) using linker magic.

asserts() now should take no RAM for any strings.

* Clean up linker file, update to latest stdc++

* Update to latest stdc++ which doesn't call strerror

* Update to GCC5.1 exception emergency allocator

Using GCC 5.1's emergency memory allocator for exceptions, much less
space is required in programs which do not use exceptions and when
space is allocated it is managed more efficiently.

* Initial try with new compiler toolchain

* Include newlib built from esp-quick-toolchain

* Update JSON with all new esp-quick-toolchain builds

* Use 64bit Windows compiler on 64bit Windows

* Dump std::exception.what() when possible

When doing the panic on unhandled exceptions, try and grab the
.what() pointer and dump it as part of the termination info.
Makes it easy to see mem errors (std::bad_alloc) or std::runtime_error
strings.

* Use scripted install from esp-quick-toolchain

Makes sure proper libraries and includes are present by using a
scripted installation from esp-quick-install instead of a manual
one.

* Update eqk to remove atexit, fix packaging diff
2018-12-03 03:37:14 -03:00
..
arduino-esp8266-travis.enc
ci: deploy released package index to arduino.esp8266.com
2018-08-03 09:51:29 +03:00
build_boards_manager_package.sh
package: add version to board package name (#5046)
2018-08-20 17:16:51 +08:00
deploy_package_index.sh
ci: deploy released package index to arduino.esp8266.com
2018-08-03 09:51:29 +03:00
esp8266-arduino-doc.bash
Fix typo (#2291)
2016-07-18 19:29:25 +08:00
merge_packages.py
Allow package and docs to be hosted in different places
2015-11-18 12:02:49 +03:00
package_esp8266com_index.template.json
Enable exceptions, update to optimized newlib, migrate to new toolchain (#5376)
2018-12-03 03:37:14 -03:00
README.md
constexpr helpers to identify core version (#5269)
2018-11-29 17:10:33 +01:00

README.md

Release tools

Overview

This directory contains scripts used to automate the release process of esp8266/Arduino project. The purpose of the release process is to generate the following outputs from the repository:

  • Boards manager package index for Arduino IDE (i.e. package_esp8266_index.json). See specification of package index file for more info.

  • Boards manager package for Arduino IDE. This is a .zip file which contains source code of esp8266/Arduino project, platform.txt, boards.txt and a few other supporting files. See 3-rd party hardware specification for more info about the layout of the boards manager package.

  • Github Release for esp8266/Arduino project. This is used to host the boards manager package mentioned above, and also contains the release notes.

Here is an overview of the release process. See the section below for detailed instructions.

  1. Release process starts when a maintainer pushes a tag into the repository.

  2. Travis CI runs a build for this tag, and one of the jobs (with BUILD_TYPE=package) is used to prepare the boards manager package. This job runs build_boards_manager_package.sh.

  3. build_boards_manager_package.sh does a few things to build the boards manager package (.zip) file and the json index:

    • Pack source files into a zip file, excluding some files and tweaking platform.txt.
    • Download current latest package index json file from Github Releases. This file contains descriptions of all previous releases.
    • Generate package index for the new release.
    • Combines new release with previous releases in one json file (using merge_packages.py script).

  4. Travis CI uploads boards manager package (.zip file) and package index (.json file) to Github Releases, creating a draft release at the same time.

  5. Travis CI also uploads package index .json file to http://arduino.esp8266.com/stable/package_esp8266_index.json, i.e. well-known URL used by most users.

  6. When the draft release is created, maintainer edits release description and inserts changelog into the description field, unmarks the release as draft, and publishes the release.

  7. Housekeeping is performed in Github issue tracker to close the completed milestone, update issue tags, etc.

Creating a release (for maintainers)

  1. Assemble release notes.

    • Since most changes are integrated into master using squash-rebase policy (i.e. one commit per PR), git log --oneline gives a good overview of changes in the release.

    • Prepare release notes in Markdown format.

    • Combine related changes into the following categories, in that order:

      • Core
      • Libraries — one section per library that received changes. If library only had a single change or a few changes, it is also okay to combine changes to a few such libraries under single "Other Libraries" entry.
      • Upstream dependencies
      • Documentation
      • Boards

    • Not all commit descriptions which come from git log will explain changes well. Reword items as necessary, with the goal that a general user of this project should be able to understand what the change is related to. Preserve references to PRs or issues (#XXXX).

    • Don't include fixes for regressions which have been introduced since last release.

    • Aggregate minor fixes (e.g. typos, small documentation changes) in a few items. Focus on preparing a good overview of the release for the users, rather than mentioning every change.

    • When done, put release notes into a private Gist and send the link to other maintainers for review.

    • Update version to the release in platform.txt and commit. E.g. 2.5.0.

  2. Tag the latest commit on the master branch. In this project, tags have form X.Y.Z, e.g. 2.4.0, or X.Y.Z-rcN for release versions. Notice that there's no vat the beginning of the tag. Tags must be annotated, not lightweight tags. To create a tag, use git command (assuming that the master branch is checked out):

    git tag -a -m "Release 2.4.0" 2.4.0

  3. Push the tag created in step 2 to esp8266/Arduino Github repository:

    git push origin 2.4.0

  4. Wait for Travis CI build for the tag to pass. Check that the new (draft) release has been created. Check that the boards manager package .zip file has been successfully uploaded as a release artifact.

  5. Check that the package index downloaded from http://arduino.esp8266.com/stable/package_esp8266_index.json contains an entry for the new version (it may not be the first one).

  6. Navigate to release list in Github, press "Edit" button to edit release description, paste release notes. Remove "draft" status of the release and publish it.

  7. In the issue tracker, remove "staged-for-release" label for all issues which have it, and close them. Close the milestone associated with the released version.

  8. Create a commit to the master branch, updating:

    • The version in platform.txt file. This should correspond to the version of the next milestone, plus -dev suffix. E.g. 2.5.0-dev.

    • In main README.md:

      • in "Contributing" section, update the "easy issues" link to point to the next milestone.

      • in "Latest release" section, change version number in the readthedocs link to the version which was just released.