bugfix/uart_isr_switch_context: add switching context in uart ISR.
1. add switching context in uart ISR
2. remove duplicated #include in uart.c
3. modify example in uart.h(will later add examples to idf/examples)
See merge request !203
esp32: softap supports bridge
Softap supports bridge, then the stations associated with esp32 softap can send/receive traffic from each other
See merge request !210
Default esp-idf builds now show -Wextra warnings (except for a few:
signed/unsigned comparison, unused parameters, old-style C declarations.)
CI building of examples runs with that level raised to -Werror, to catch
those changes going into the main repo.
1. Actually, btc & api are the same module thing. So the type defined in api header file can be included by btc c/h files.
Besides, why btc & api should be separated, because that user may be aware of api and api refer defines/types, rather than other non-refer things.
All defines/types that user won't use should be put in btc directory (and define with prefix "btc_"), and which will be used by user should be defined with prefix "esp_" .
2. rename attribute value(all is value, not data)
1. which named uuid is esp_bt_uuid_t type
2. which named id is xxx_id_t type, such as service_id_t char_id_t, include inst & uuid
3. share include directory
Add more scalable tick/idle hook handlers.
Like it says in the title. Also adds WAITI to the idle loop, which suspends the CPU until an interrupt comes in. Seems we did not have that yet... :x
See merge request !196
Work around the GPIO pullup/pulldown SoC bug
Some GPIO pins need to have their pullups/pulldowns set in the RTC peripheral instead of in the GPIO peripheral because of a silicon bug.
This merge:
- Declares PIN_PULLUP_EN and friends as deprecated; they can't really be changed to work around the issue because they get passed an iomux register instead of an io pin number
- Adds gpio_pullup_en and friends to the GPIO driver. These functions do have the workaround (as well as all the other functions in the gpio driver) and are meant to easily replace the PIN_PULLUP_EN routines
- Fixes some comments in the gpio headers
See merge request !200
build system: General refactoring
The original goal here was to support setting different COMPONENT_INCLUDEDIRS/COMPONENT_LDFLAGS based on sdkconfig. It's turned into a general refactor.
* The `get_variable` target & associated macros have been replaced with a target that generates a makefile snippet for each component (inside the build directory), and includes these in the project make pass. This improves build speed ( "no-op" `make all` on my system is down from 1.43s (wall) / 0.55s (CPU) to 0.49s (wall) / 0.23s (CPU) due to not forking as many processes) and also makes the builds more debuggable, as you can go and look at the component_project_vars.mk files in the build directory to see what paths are being added where.
* Including component_common.mk from component.mk is no longer necessary (and prints a deprecation warning). Instead, component.mk is included from inside a wrapper makefile. This allows default variables and project configuration to be loaded before component.mk begins, and removes the need to split makefile statements arbitrarily between "before including component_common" and "after including component_common", with which goes where depending on internals of the build system. Part-fix for TW#8017.
* Rewrote build system docs to reflect these details and also clarify some other points, add more ReST structure. Fixes other issues raised in TW#8017.
* Should be backwards compatible with existing components. The only difference I know is the deprecation warning when including component_common.mk.
Adds one new failure case: because some paths are encoded in the generated component_project_vars.mk files then reorganising the component directory structure (but not modifying any other files or menuconfig) may cause a partial build to fail and require a `make clean`. Moving the whole project directory, whole build directory, or whole ESP-IDF directory will not trigger this. This failure case should only ever cause a build error, not incorrect build output.
See merge request !188
