History

Michael (XIAO Xufeng) 562af8f65e global: move the soc component out of the common list This MR removes the common dependency from every IDF components to the SOC component. Currently, in the ``idf_functions.cmake`` script, we include the header path of SOC component by default for all components. But for better code organization (or maybe also benifits to the compiling speed), we may remove the dependency to SOC components for most components except the driver and kernel related components. In CMAKE, we have two kinds of header visibilities (set by include path visibility): (Assume component A --(depends on)--> B, B is the current component) 1. public (``COMPONENT_ADD_INCLUDEDIRS``): means this path is visible to other depending components (A) (visible to A and B) 2. private (``COMPONENT_PRIV_INCLUDEDIRS``): means this path is only visible to source files inside the component (visible to B only) and we have two kinds of depending ways: (Assume component A --(depends on)--> B --(depends on)--> C, B is the current component) 1. public (```COMPONENT_REQUIRES```): means B can access to public include path of C. All other components rely on you (A) will also be available for the public headers. (visible to A, B) 2. private (``COMPONENT_PRIV_REQUIRES``): means B can access to public include path of C, but don't propagate this relation to other components (A). (visible to B) 1. remove the common requirement in ``idf_functions.cmake``, this makes the SOC components invisible to all other components by default. 2. if a component (for example, DRIVER) really needs the dependency to SOC, add a private dependency to SOC for it. 3. some other components that don't really depends on the SOC may still meet some errors saying "can't find header soc/...", this is because it's depended component (DRIVER) incorrectly include the header of SOC in its public headers. Moving all this kind of #include into source files, or private headers 4. Fix the include requirements for some file which miss sufficient #include directives. (Previously they include some headers by the long long long header include link) This is a breaking change. Previous code may depends on the long include chain. You may need to include the following headers for some files after this commit: - soc/soc.h - soc/soc_memory_layout.h - driver/gpio.h - esp_sleep.h The major broken include chain includes: 1. esp_system.h no longer includes esp_sleep.h. The latter includes driver/gpio.h and driver/touch_pad.h. 2. ets_sys.h no longer includes soc/soc.h 3. freertos/portmacro.h no longer includes soc/soc_memory_layout.h some peripheral headers no longer includes their hw related headers, e.g. rom/gpio.h no longer includes soc/gpio_pins.h and soc/gpio_reg.h BREAKING CHANGE		2019-04-16 13:21:15 +08:00
..
main	global: move the soc component out of the common list	2019-04-16 13:21:15 +08:00
CMakeLists.txt	example: add nmea0183 parser example	2018-12-07 10:57:34 +08:00
Makefile	example: add nmea0183 parser example	2018-12-07 10:57:34 +08:00
README.md	example: add nmea0183 parser example	2018-12-07 10:57:34 +08:00

README.md

UART Echo Example

(See the README.md file in the upper level 'examples' directory for more information about examples.)

This example demonstrates how to utilize UART interfaces of ESP32 by echoing back to the sender any data received on UART1.

How to use example

Hardware Required

The example can be run on any ESP32 development board connected to a PC with a single USB cable for flashing and monitoring. The external interface should have 3.3V outputs. You may use e.g. 3.3V compatible USB-to-Serial dongle.

Setup the Hardware

Connect the external serial interface to the ESP32 board as follows.

ESP32 Interface	#define	ESP32 Pin	External UART Pin
Transmit Data (TxD)	ECHO_TEST_TXD	GPIO4	RxD
Receive Data (RxD)	ECHO_TEST_RXD	GPIO5	TxD
Ground	n/a	GND	GND

Optionally, you can set-up and use a serial interface that has RTS and CTS signals in order to verify that the hardware control flow works. Connect the extra signals according to the following table, configure both extra pins in the example code by replacing existing UART_PIN_NO_CHANGE macros with the appropriate pin numbers and configure UART1 driver to use the hardware flow control by setting .flow_ctrl = UART_HW_FLOWCTRL_CTS_RTS and adding .rx_flow_ctrl_thresh = 122.

ESP32 Interface	#define	ESP32 Pin	External UART Pin
Request to Send (RTS)	ECHO_TEST_RTS	GPIO18	CTS
Clear to Send (CTS)	ECHO_TEST_CTS	GPIO19	RTS

Configure the project

make menuconfig

idf.py menuconfig

Set serial port under Serial Flasher Options.

Build and Flash

Build the project and flash it to the board, then run monitor tool to view serial output:

make -j4 flash monitor

idf.py flash monitor

(To exit the serial monitor, type Ctrl-].)

See the Getting Started Guide for full steps to configure and use ESP-IDF to build projects.

Example Output

Type some characters in the terminal connected to the external serial interface. As result you should see echo in the terminal which is used for flashing and monitoring. You can verify if the echo indeed comes from ESP32 by disconnecting either TxD or RxD pin: no characters will appear when typing.

Troubleshooting

You are not supposed to see the echo in the terminal which is used for flashing and monitoring, but in the other one which is connected to UART1.