espressif / esp-iot-solution

Espressif IoT Library. IoT Device Drivers, Documentations And Solutions.

Espressif IoT Solution Overview

• 中文版

ESP-IoT-Solution contains device drivers and code frameworks for the development of IoT systems, providing extra components that enhance the capabilities of ESP-IDF and greatly simplify the development process.

ESP-IoT-Solution contains the following contents:

• Device drivers for sensors, display, audio, input, actuators, etc.
• Framework and documentation for Low power, security, storage, etc.
• Guide for espressif open source solutions from practical application point.

Documentation Center

• 中文：https://docs.espressif.com/projects/esp-iot-solution/zh_CN
• English:https://docs.espressif.com/projects/esp-iot-solution/en

Quick Reference

Development Board

You can choose any of the ESP series development boards to use ESP-IoT-Solution or choose one of the boards supported in boards component for a quick start.

Powered by 40nm technology, ESP series SoC provides a robust, highly integrated platform, which helps meet the continuous demands for efficient power usage, compact design, security, high performance, and reliability.

Setup Environment

Setup ESP-IDF Environment

ESP-IoT-Solution is developed based on ESP-IDF functions and tools, so ESP-IDF development environment must be set up first, you can refer Setting up Development Environment for the detailed steps.

Please note that different versions of ESP-IoT-Solution may depend on different versions of ESP-IDF, please refer to the below table to select the correct version:

ESP-IoT-Solution	Dependent ESP-IDF	Major Change	User Guide	Support State
master	>= v4.4	support component manager and new chips	Docs online	active, new feature develop
release/v1.1	v4.0.1	IDF version update, remove no longer supported code	v1.1 Overview	archived
release/v1.0	v3.2.2	legacy version	v1.0 Overview	archived

Since the master branch uses the ESP Component Manager to manager components, each of them is a separate package, and each package may support a different version of the ESP-IDF, which will be declared in the component's idf_component.yml file

Get Components from ESP Component Registry

If you just want to use the components in ESP-IoT-Solution, we recommend you use it from the ESP Component Registry.

The registered components in ESP-IoT-Solution are listed below:

Component Name	Version
aht20
at581x
avi_player
ble_conn_mgr
ble_ota
bootloader_support_plus
button
cmake_utilities
esp_lcd_gc9b71
esp_lcd_axs15231b
esp_lcd_panel_io_additions
esp_lcd_nv3022b
esp_lcd_sh8601
esp_lcd_spd2010
esp_lcd_st7701
esp_lcd_st77903_rgb
esp_lcd_st77916
esp_lcd_st77922
esp_lcd_touch_spd2010
esp_lcd_touch_st7123
keyboard_button
esp_msc_ota
esp_simplefoc
esp_sensorless_bldc_control
esp_tinyuf2
extended_vfs
gprof
iot_usbh
iot_usbh_cdc
iot_usbh_modem
ir_learn
knob
led_indicator
lightbulb_driver
ntc_driver
openai
pwm_audio
usb_device_uvc
usb_stream
xz
zero_detection

You can directly add the components from the Component Registry to your project by using the idf.py add-dependency command under your project's root directory. eg run idf.py add-dependency "espressif/usb_stream" to add the usb_stream, the component will be downloaded automatically during the CMake step.

Please refer to IDF Component Manager for details.

Get ESP-IoT-Solution Repository

If you want to Contribute to the components in ESP-IoT-Solution or want to start from the examples in ESP-IoT-Solution, you can get the ESP-IoT-Solution repository by following the steps:

• If select the master version, open the terminal, and run the following command:

  git clone --recursive https://github.com/espressif/esp-iot-solution
  

• If select the release/v1.1 version, open the terminal, and run the following command:

  git clone -b release/v1.1 --recursive https://github.com/espressif/esp-iot-solution
  

Build and Flash Examples

We highly recommend you Build Your First Project to get familiar with ESP-IDF and make sure the environment is set up correctly.

There is no difference between building and flashing the examples in ESP-IoT-Solution and in ESP-IDF. In most cases, you can build and flash the examples in ESP-IoT-Solution by following the steps:

1. Change the current directory to the example directory, eg cd examples/usb/host/usb_audio_player.
2. Run idf.py set-target TARGET to set the target chip. eg idf.py set-target esp32s3 to set the target chip to ESP32-S3.
3. Run idf.py build to build the example.
4. Run idf.py -p PORT flash monitor to flash the example, and view the serial output. eg idf.py -p /dev/ttyUSB0 flash monitor to flash the example and view the serial output on /dev/ttyUSB0.

Some examples may need extra steps to setup the ESP-IoT-Solution environment, you can run export IOT_SOLUTION_PATH=~/esp/esp-iot-solution in Linux/MacOS or set IOT_SOLUTION_PATH=C:\esp\esp-iot-solution in Windows to setup the environment.

Resources

• Documentation for the latest version: https://docs.espressif.com/projects/esp-iot-solution/ . This documentation is built from the docs directory of this repository.
• ESP-IDF Programming Guide: https://docs.espressif.com/projects/esp-idf/zh_CN . Please refer to the version ESP-IoT-Solution depends on.
• The IDF Component Registry is where you can find the components in ESP-IoT-Solution and other registered components.
• The esp32.com forum is a place to ask questions and find community resources.
• Check the Issues section on GitHub if you find a bug or have a feature request. Please check existing Issues before opening a new one.
• If you're interested in contributing to ESP-IDF, please check the Contributions Guide.

esp-iot-solution's Issues

I2C and SPI thread-safe

Problem Description

Hello.
If it is a components SPI and I2C thread-safe?

For now, i'll use:

BaseType_t I2C_take() {
	return xSemaphoreTake(i2c_semphr, 1000 / portTICK_RATE_MS);
}

BaseType_t I2C_give() {
	return xSemaphoreGive(i2c_semphr);
}

and in the code

if (I2C_take() == pdTRUE) {
	float t = iot_bme280_read_temperature(dev);
	I2C_give();
	xQueueSend(queue_, &t, 0);
}

If you known about This Man and his i2c_dev component thats is thread-safe.

Sorry for bad english :)

Unable to compile ESP32_Azure_IoT_Kit Example

Environment

• Development Kit: [ESP32-Azure IoT Kit]
• Kit version
• Module or chip used: [ESP32-WROVER-B]
• IDF version: v4.1-dev-369-g4dac7c7df
• Build System: [CMake]
• Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp32-2019r1) 8.2.0
• Operating System: [Windows]
• Power Supply: [USB]

Problem Description

idf.py build was not able to compile the example in the "\esp-iot-solution\examples\esp32_azure_iot_kit" folder.

IOT_SOLUTION_PATH is set.

Expected Behavior

idf.py build should be able to compile the example as mentioned in documentation

Actual Behavior

idf.py build will start throwing errors after [178/848]

Steps to repropduce

1. Install ToolChain
2. Get the latest esp-iot-solution repository from github
3. Run ESP-IDF Command Prompt and navigate to the esp32_azure_iot_kit folder
4. Run idf.py build

Snapshot of errors.

The error is too long. Below is just a snapshot of the start of the errors:

Running ninja in directory d:\esp\githubs\esp-iot-solution\examples\esp32_azure_iot_kit\build
Executing "ninja all"...
[172/848] Building CXX object cxx/CMakeFiles/cxx.dir/cxx_exception_stubs.cpp.obj
FAILED: cxx/CMakeFiles/cxx.dir/cxx_exception_stubs.cpp.obj
ccache D:\ESP.espressif\tools\xtensa-esp32-elf\esp32-2019r1-8.2.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-g++.exe -DESP_PLATFORM -DGCC_NOT_5_2_0=1 -DHAVE_CONFIG_H -DIDF_VER="v3.2.2" -Iconfig -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/esp32/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/driver/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/esp_ringbuf/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/tcpip_adapter/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/lwip/include/apps -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/lwip/lwip/src/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/lwip/port/esp32/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/lwip/port/esp32/include/arch -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/lwip/include_compat -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/vfs/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/esp_event/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/log/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/platform_include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/freertos/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/app_trace/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/heap/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/soc/esp32/include -ID:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/soc/include -Og -std=gnu++11 -fno-rtti -fno-exceptions -ffunction-sections -fdata-sections -fstrict-volatile-bitfields -mlongcalls -nostdlib -Wall -Werror=all -Wno-error=unused-function -Wno-error=unused-but-set-variable -Wno-error=unused-variable -Wno-error=deprecated-declarations -Wextra -Wno-unused-parameter -Wno-sign-compare -ggdb -MD -MT cxx/CMakeFiles/cxx.dir/cxx_exception_stubs.cpp.obj -MF cxx\CMakeFiles\cxx.dir\cxx_exception_stubs.cpp.obj.d -o cxx/CMakeFiles/cxx.dir/cxx_exception_stubs.cpp.obj -c D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/cxx/cxx_exception_stubs.cpp
In file included from d:\esp.espressif\tools\xtensa-esp32-elf\esp32-2019r1-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\sys-include\stdlib.h:18,
from d:\esp.espressif\tools\xtensa-esp32-elf\esp32-2019r1-8.2.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.2.0\cstdlib:75,
from D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/cxx/cxx_exception_stubs.cpp:1:
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:166:8: error: '_VOID' does not name a type
extern _VOID _EXFUN(__sinit,(struct _reent ));
^~~~~
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:193:3: error: '_PTR' does not name a type
_PTR _cookie; / cookie passed to io functions */
^~~~
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:195:36: error: '_read' has not been declared
_READ_WRITE_RETURN_TYPE _EXFNPTR(_read, (struct _reent *, _PTR,
^~~~~
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:195:43: error: expected identifier before '(' token
_READ_WRITE_RETURN_TYPE _EXFNPTR(_read, (struct _reent *, _PTR,
^
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:195:61: error: '_PTR' has not been declared
_READ_WRITE_RETURN_TYPE _EXFNPTR(_read, (struct _reent *, _PTR,
^~~~
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:197:36: error: '_write' has not been declared
_READ_WRITE_RETURN_TYPE _EXFNPTR(_write, (struct _reent *, _PTR,
^~~~~~
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:197:44: error: expected identifier before '(' token
_READ_WRITE_RETURN_TYPE _EXFNPTR(_write, (struct _reent *, _PTR,
^
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:197:62: error: '_PTR' has not been declared
_READ_WRITE_RETURN_TYPE _EXFNPTR(_write, (struct _reent *, _PTR,
^~~~
D:/ESP/githubs/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:200:20: error: '_seek' has not been declared
_fpos_t _EXFNPTR(_seek, (struct _reent *, _PTR, _fpos_t, int));

The error will continue until it hit this:

[185/848] Building C object touchpad/CMakeFiles/touchpad.dir/touchpad.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1

Please provide Readme in English

Thanks. (see examples/counting pedestrians)

Issue getting temperature from hts221 sensor (ESP32-Azure IoT KiT)

I'm running the provided example to test the hts221 using ESP32-Azure IoT KiT but the temperature and humidity value is always 0.00 and I cannot see any error message in the console

It is necessary to execute a previous configuration before running the example?

Thanks in advance

[temporary solved but please let it open for a while] (eth2wifi) always gets stuck again after a while in Wifi SoftAP mode

EDIT:
temporary solved but please let it open for a while
Last Update:
2019-March-12
@projectgus

it is a routing/arp problem in windows systems if you have not right configured your public and privat network adapter - i solved this by test on a fresh windows system and switch only one adapter (rj45)
so the LAN8720 get the IP from this windows RJ45 and the routing was done by windows fine.
now there is no more stuck again.

i will look deeper in the other windows system cause there must be a wrong routing setup
or arp entry or anything. let me check next time. if i find out detailed i will post here all steps i did.
there is no leak in the buffering itself, all data flys very fine.
thank you for the tip with WireShark - did not use it on sender and receiver,
allway only one way :) - but this was a good tip to check on sender and receiver.
so the data are fine -

only this windows routing ( tracert it ) is
very contaminated by eternal back and forth setups and more frequent setups
and has not always resolved cleanly or entries (gtw, routings) were not always deleted cleanly
all ok Angus but please let it open for a while - i will update the thing here.

amazing work!
best wishes
rudi

---

Hi

the Ethernet to wifi station data forwarding demo works very well with an extern Wifi Hotspot.
same doing to use the esp32 as own Wifi Hotspot and the Ethernet to wifi softap data forwarding demo
the things works at begin, then after a while of continous stream data 3-5 seconds the stream data becomes a mess.

after a new refresh request the stream begin to work ok and then it work for 3-5 seconds and the mess begins again.

i did not look deeper in the handle of FiFo or ringbuffer, which use the Ethernet to wifi softap data forwarding demo perhabs.
but can you please check or say, can we flush the data ringbuffer or can we setup with more buffer that the datastream does not go confuse anymore`?

sry - the wifi things are in a blob bin
so i can't do anything on a normal way to check the things

My example Setup:

using the ESP32 and LAN8720
works well with the setup demo, works well with the Station Demo.
the hardware setup is not the problem - it works very fine.

just only change from Station to softAP mode
works 3-5 seconds that the stream gets a mess.

i use the original demo code without any change

Symbolic
Ethernet to wifi station data forwarding demo
"wireless adapter"

DEVICE to forward data has LAN -> connected by RJ45 to -> LAN8720 -> ESP32 as Station -> connect to a extern Wifi Hotspot
Device sends continous data stream to the connected client at extern Wifi Hotspot
there is no problem and all works fine

Ethernet to wifi softap data forwarding demo
"WiFi hotspot"

DEVICE to forward data has LAN -> connected by RJ45 to -> LAN8720 -> ESP32 as Wifi Hotspot
Device sends continous data stream to the connected client at ESP32(WifiHotspot)
first 3-5 seconds all ok, then get a mess in data stream

where can you make a flush or increase or better tune the buffer
i think the mistake is in the buffer ( read write forward goes to mess )
in Hotspot Mode.

any suggestion?
it is a very good example - i do not want to miss it

thank you
best wishes
rudi

Can't find DataScope application

Touch sensor readme refers to "DataScope tool can be downloaded from Espressif's official website." but I cannot find it. Could someone provide a link, please? Thank you!

Update for lvgl 6.0?

Hi,
Is there an ETA to update the IoT commit to be compatible with lvgl V6.0?
It has basically become unusable.

Esp32 capacitive touch sensitivity

Hello, I want to now about the sensitivity of ESP32 internal capacitive touch sensor. I read this article:
https://github.com/espressif/esp-iot-solution/blob/master/documents/touch_pad_solution/touch_sensor_design_en.md
It mentioned that between finger and electrode, It is possible to have a protective cover, But it's thickness and material are important points, Is a normal glass or plastice surface which is less than 1 mm thick, fine? I tried ESP-WROOM-32 but even with a piece of paper between finger and electrode it doesn't detect anything at all.

Unable to use I2S LCD mode with 8-bit parallel

I have ported over an ILI9488 display with an init sequence that's known to work on other libraries. However I'm noticing the code expects 16 bit commands/registers, and there are no provisions on the code to check for 8 bit data paths for registers. In fact it seems that the 8 bit defines are just plain wrong for the combination of displays with 8 bit commands and 8 bit bus (

esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd_com.c

Line 36 in db36832

void iot_i2s_lcd_write_cmd(i2s_lcd_handle_t i2s_lcd_handle, uint16_t cmd)

is pretty telling in this regard).

When connected via a 16 bit bus the top byte/8 lines are ignored, but as far as I can tell on 8 bits bus the ILI commands are seemingly being cancelled by NOPs when the bytes are swapped (high byte is 0x0). I unfortunately can't follow up on this suspicion right now as I don't have a logic analyser handy. I do know that the connections are right and I do know that bit banging the GPIOs as a bus works. I suspect there could be something weird with the WS clock but first I'd like to make sure that my reading of i2s_lcd_com makes any sense...

For kicks, I also attempted to port over ILI9341 as 8-bit parallel I2S; everything is royally garbled there but I can see some thin strips with parts of what the original image is supposed to be. So I'm still hoping it's just misconfigured somehow...

Code not working with LAN8710A.

Hello ,

I am trying to use Ethernet to WiFi data forwarding demo code on ESP32-EVB Rev D on windows 10 with msys32 and I have added header file and C source file of LAN8710A in Ethernet components of ESP IDF, code has built successfully , but its not working, device is rebooting continuously.

Please Help.
Thanks.

编译aws_iot_demo报缺少certs/aws-root-ca.pem 这个文件，其他两个文件我已经从aws iot控制台下载了。

你好，
编译aws_iot_demo报缺少certs/aws-root-ca.pem 这个文件，其他两个文件我已经从aws iot控制台下载了。请问我怎么获取到aws-root-ca.pem？

Conflict between iot_lcd.cpp and SPI SDCARD.

HI，the engineer who makes the “iot_lcd. cpp”.
I am using “iot_lcd. cpp” on the M5Stack.
Because the LCD and SD SPI of M5Stack are reused.
First of all , I used the APIS of LCD, and second I initialize the SD APIS. It's ok for me to read and write some files by SD APIS.
Finally, after using SD APIS, all the LCD APIS are failed.
added:
My LCD spi is HSPI, using dma channel 1.
My SD spi is VSPI, using dma channel 2.

ESP32 Sense Kit - Liquids

Just purchased from DigiKey the ESP32 Sense Kit. Works nice until a little moisture gets on one of the 9 key. Then none of the buttons work. Is this expected operation? I also cannot get it to work at all with any of the protective covers. Does this touch sensor not auto-calibrate?

programming esp-01

i want to use esp-prog to program esp-01

connection are:

esp-prog / esp-01

TX / rx
RX / tx
I00 / i00
EN / RST (tryed also on CH_PD)
GND / GND
usb conn. / +V (external source)
-- / CH-PD with pullup 10k
-- / i02 to pullup 10k

the blue light flash when i start to program

i try with program like esp8266flasher, inside visual studio (with visualmicro),ESPFlashDownloadTool_v3.6.4

when the green light flash, also on the esp01 flash the blue light

noone of this can program, what is the trick?

thanks

Using LittlevGL with an LCD display that doesn't have a touch screen driver

Environment

• Development Kit: ESP32-Wrover-Kit
• Kit version (for WroverKit/PicoKit/DevKitC): v3
• Module or chip used: ESP32-WROVER
• IDF version (run git describe --tags to find it):
  // v3.1.1-68-g4070d09
• Build System: Make
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  // 1.22.0-80-g6c4433a
• Operating System: Linux
• Power Supply: external 5V

Problem Description

An ESP-WROVER-KIT V3 has an LCD display with an ILI9341 screen driver but it has no touch screen driver. If the LittlevGL library is used, it would therefore make sense to turn off the menuconfig option IoT Solution settings > IoT Components Management > HMI Components > LVGL settings > LittlevGL Touch Screen Enable. However, if this option is turned off, there is the following compile error:

/home/brian/src/esp-idf/esp-iot-solution/examples/hmi/lvgl_example/build/lvgl_gui/liblvgl_gui.a(lvgl.o):(.literal.lvgl_init+0x10): undefined reference to `lvgl_indev_init'
/home/brian/src/esp-idf/esp-iot-solution/examples/hmi/lvgl_example/build/lvgl_gui/liblvgl_gui.a(lvgl.o): In function `lvgl_init':
/home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl.c:52: undefined reference to `lvgl_indev_init'
collect2: error: ld returned 1 exit status
/home/brian/src/esp-idf/esp-iot-solution/submodule/esp-idf//make/project.mk:406: recipe for target '/home/brian/src/esp-idf/esp-iot-solution/examples/hmi/lvgl_example/build/lvgl_example.elf' failed
make: *** [/home/brian/src/esp-idf/esp-iot-solution/examples/hmi/lvgl_example/build/lvgl_example.elf] Error 1

The compile error occurs because this line of code is attempting to call the non-existant lvgl_indev_init function:

 lv_indev_drv_t indevdrv = lvgl_indev_init(); /* Initialize your indev */

Would it not be better to change this line of code to the following:

#ifdef CONFIG_LVGL_DRIVER_TOUCH_SCREEN_ENABLE
 lv_indev_drv_t indevdrv = lvgl_indev_init(); /* Initialize your indev */
#endif

This line of code:

 lvgl_calibrate_mouse(indevdrv, false);

would also need to be changed to:

#ifdef CONFIG_LVGL_DRIVER_TOUCH_SCREEN_ENABLE
 lvgl_calibrate_mouse(indevdrv, false);
#endif

Not able to compile the aws_iot_demo

Environment

• Development Kit: ESP32-DevKitC
• Kit version (for WroverKit/PicoKit/DevKitC): ?
• Module or chip used: ESP32D0WDQ6 (revision 1)
• IDF version: v3.3-dev-206-g0d7f2d77c
• Build System: make
• Compiler version: xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
• Operating System: Linux
• Power Supply: USB

Problem Description

I'm not able to compile esp-iot-solution/examples/aws_iot_demo. make fails with fatal error: iot_lcd.h: No such file or directory

Expected Behavior

The example should be able compile, but here is something wrong or missing in my setup.

There is no iot_lcd.h in main/include. The iot_lcd.h is locate in /esp-iot-solution/components/spi_devices/lcd/include/iot_lcd.h.

Should I add some definition to the Makefile? Should I install components under aws_iot_demo folder?

Actual Behavior

jgr@zoe:~/dev/esp/esp-iot-solution/examples/aws_iot_demo$ make
CXX build/main/aws_iot_lcd.o
/home/jgr/dev/esp/esp-iot-solution/examples/aws_iot_demo/main/aws_iot_lcd.cpp:14:21: fatal error: iot_lcd.h: No such file or directory

Steps to repropduce

cd esp-iot-solution/examples/aws_iot_demo
make menuconfig
make

Other examples

The oled_screen_module compiles and runs perfectly!

cd esp-iot-solution/examples/oled_screen_module
make menuconfig
make flash monitor

[feature] driver for ADS1256-24-Bit-ADC (AEGHB-288)

Feature request from : http://bbs.esp32.com/viewtopic.php?f=22&t=7890&sid=c4dadc799207e6391c2bee46a4305715

where to download the esp32 secure flasher tool?

Question as the title show , can show me the download link of the esp32 secure flasher tool, mention in document "https://github.com/espressif/esp-iot-solution/blob/master/documents/security_solution/download_tool_en.md#download-tool-gui-instruction"

When using a 128 x 64 OLED display the SSD1306 OLED driver displays the 16th character on a row incorrectly

Environment

• Development Kit: ESP32-Azure IoT Kit
• Kit version (for WroverKit/PicoKit/DevKitC): Unknown. Unfortunately no version information is printed on board. The number 1845 is printed on the board. See below pictures.
• Module or chip used: ESP32-WROVER-B
• IDF version (run git describe --tags to find it): v3.1.3
• Build System: Make
• Compiler version (run xtensa-esp32-elf-gcc --version to find it): 1.22.0-80-g6c4433a
• Operating System: Linux
• Power Supply: USB

Problem Description

The ESP32-Azure IoT Kit has a 128 x 64 OLED display. If text is displayed on the OLED display using the 16 x 8 font, it should be possible to display 16 characters per row on the OLED display.

The X pixel position of the 1st character is 0
The X pixel position of the 2nd character is 8
The X pixel position of the 3rd character is 16
...
The X pixel position of the 16th character is 120

If a character is displayed at X pixel position 120 using the 16 x 8 font it is not displayed correctly. The character is 8 pixels wide. As can be seen in the below picture, the first 6 columns of pixels for the character are displayed on the right hand side of the display and the last 2 columns of pixels are displayed on the left hand side of the display.

Expected Behavior

A character displayed at X pixel position 120 using the 16 x 8 font should appear on the right hand side of the display.

Actual Behavior

A character displayed at X pixel position 120 using the 16 x 8 font only partially appears on the right hand side of the display. The first 6 columns of pixels for the character are displayed on the right hand side of the display and the last 2 columns of pixels are displayed on the left hand side of the display.

Steps to repropduce

The issue can be reproduced with the code provided below.

Code to reproduce this issue

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "iot_i2c_bus.h"
#include "iot_ssd1306.h"

#define I2C_MASTER_SCL_IO           26
#define I2C_MASTER_SDA_IO           25
#define I2C_MASTER_NUM              I2C_NUM_1
#define I2C_MASTER_FREQ_HZ          100000

static i2c_bus_handle_t i2c_bus = NULL;
static ssd1306_handle_t ssd1306_dev = NULL;

static void i2c_bus_init() {
    i2c_config_t conf;
    conf.mode = I2C_MODE_MASTER;
    conf.sda_io_num = (gpio_num_t)I2C_MASTER_SDA_IO;
    conf.sda_pullup_en = GPIO_PULLUP_ENABLE;
    conf.scl_io_num = (gpio_num_t)I2C_MASTER_SCL_IO;
    conf.scl_pullup_en = GPIO_PULLUP_ENABLE;
    conf.master.clk_speed = I2C_MASTER_FREQ_HZ;
    i2c_bus = iot_i2c_bus_create(I2C_MASTER_NUM, &conf);
}

static void ssd1306_init() {
    ssd1306_dev = iot_ssd1306_create(i2c_bus, SSD1306_I2C_ADDRESS);
    iot_ssd1306_refresh_gram(ssd1306_dev);
    iot_ssd1306_clear_screen(ssd1306_dev, 0x00);
}

extern "C" void app_main() {
    i2c_bus_init();
    ssd1306_init();

    iot_ssd1306_draw_string(ssd1306_dev, 120, 0, (const uint8_t *) "6", 16, 0);
    iot_ssd1306_refresh_gram(ssd1306_dev);
}

Steps to fix

This can be fixed by setting the lower column start address for page addressing mode to 0 rather than 2 as is currently the case.

In other words, changing this line of code from:

#define SSD1306_SET_LOWER_ADDRESS   0x02

to:

#define SSD1306_SET_LOWER_ADDRESS   0x00

resolves the issue.

Here's a picture of what it looks like after this modification is made.

I can create a pull request with this change but I don't know why SSD1306_SET_LOWER_ADDRESS is currently set to 2. I also don't know if setting SSD1306_SET_LOWER_ADDRESS to 0 will have a negative impact on something else.

If I had to guess why SSD1306_SET_LOWER_ADDRESS is currently set to 2, I'd say it has something to do with supporting 132 x 64 OLED displays that have a SH1106 chip. If is this is the case, it has a negative impact on 128 x 64 displays as the 16th character on a row is no longer displayed correctly. An additional negative impact of this is that the text wrap functionality that provided by the SSD1306 driver can't be relied on as it will also display the 16th character on a row incorrectly.

Edit: Changed the word "can" on the last line above to "can't".

error: wrong return type on i2s_lcd_create

This function is returning ESP_ERR_INVALID_ARG when it should return a pointer (NULL)

esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd.c

Lines 292 to 294 in 3cf2659

	i2s_lcd_handle_t i2s_lcd_create(i2s_port_t i2s_num, i2s_lcd_config_t *pin_conf)
	{
	I2S_CHECK((i2s_num < I2S_NUM_MAX), "i2s_num error", ESP_ERR_INVALID_ARG);

also here

esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd.c

Lines 313 to 315 in 3cf2659

	if (gpio_config(&gpio_conf) != ESP_OK) {
	return ESP_FAIL;
	}

This cause the following warning

/home/user/esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd.c: In function 'i2s_lcd_create':
/home/user/esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd.c:31:16: warning: return makes pointer from integer without a cast [-Wint-conversion]
         return (ret);                                                                   \
                ^
/home/user/esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd.c:294:5: note: in expansion of macro 'I2S_CHECK'
     I2S_CHECK((i2s_num < I2S_NUM_MAX), "i2s_num error", ESP_ERR_INVALID_ARG);
     ^
In file included from /home/user/esp-iot-solution/submodule/esp-idf/components/esp32/include/esp_timer.h:44:0,
                 from /home/user/esp-iot-solution/submodule/esp-idf/components/freertos/include/freertos/portmacro.h:82,
                 from /home/user/esp-iot-solution/submodule/esp-idf/components/freertos/include/freertos/portable.h:94,
                 from /home/user/esp-iot-solution/submodule/esp-idf/components/freertos/include/freertos/FreeRTOS.h:105,
                 from /home/user/esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd.c:18:
/home/user/esp-iot-solution/submodule/esp-idf/components/esp32/include/esp_err.h:28:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
 #define ESP_FAIL        -1      /*!< Generic esp_err_t code indicating failure */
                         ^
/home/user/esp-iot-solution/components/i2s_devices/lcd_common/i2s_lcd.c:314:16: note: in expansion of macro 'ESP_FAIL'
         return ESP_FAIL;
                ^

esp-iot-solution library for "esp32 azure Iot" board

Hello,
I have a problem using the aforementioned library. I get the message "no headers files (.h) found in C:............\Arduino\libraries\esp-iot-solution".
Can someone provide information about the usage of this library?
Thank you in advance!

lvgl_example does not activate backlight of LCD

Environment

• Development Kit: ESP32-Wrover-Kit
• Kit version (for WroverKit): v3
• Module or chip used: ESP32-WROVER
• IDF version v3.1.3
• Build System: Make
• Compiler version : 1.22.0-80-g6c4433a
• Operating System: macOS
• Power Supply: USB

Problem Description

lvgl_example does not activate backlight of LCD

Expected Behavior

backlight would turn on to view example

Actual Behavior

screen remains black

Steps to reproduce

set correct options in menuconfig:

(25) LittlevGL LCD MISO GPIO
(23) LittlevGL LCD MOSI GPIO
(19) LittlevGL LCD CLK GPIO
(22) LittlevGL LCD CS GPIO
(21) LittlevGL LCD DC GPIO
(18) LittlevGL LCD RESET GPIO
(5) LittlevGL LCD BL GPIO

& disable touch screen options

Code to reproduce this issue

If I add this line to app_main.cpp, after lvgl_init();, the screen lights up:

///Enable backlight
gpio_set_level((gpio_num_t)CONFIG_LVGL_LCD_BL_GPIO, 0);

Debug Logs

Other items if possible

lvgl_example and IDF3.3 not working (AEGHB-295)

IDF v3.3 (basic kit was installed with https://dl.espressif.com/dl/esp-idf-tools-setup-2.0.exe)
ESP32_Core_board_v2 (with ESP32 WROOM 32)
littlevgl installed: https://blog.littlevgl.com/2019-01-31/esp32

Since I use latest idf instead of "make menuconfig" and "make" I use:
idf.py menuconfig
idf.py build
from esp-iot-solution\examples\hmi\lvgl_example directory.

The result of build is:
CMake Error at D:/Work/ESP32/esp-iot-solution/submodule/esp-idf/tools/cmake/project.cmake:57 (idf_set_global_variables):
Unknown CMake command "idf_set_global_variables".
Call Stack (most recent call first):
CMakeLists.txt:20 (project)

The hello_world example from IDF is working fine, I can compile and run it in the same way, I have issues only with the IOT package.

ssd1306 oled on i2c not showing up ( esp Azure iot kit )

I used esp32_azure_iot_kit example code from this repo.
I tried using esp_tool to scan for available devices, Except OLED ( addr: 0x3c ) other sensors are showing up. Below is the result on i2cdetect

Scanning I2C Addresses
.. .. .. .. .. .. .. .. .. .. .. .. .. .. 0E ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. 23 .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 5F
.. .. .. .. .. .. .. .. 68 .. .. .. .. 6D .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..

ESP-MDF

I am using esp-mdf now, but how should I use ssd1306 driver to light up my OLED?

Old version of esp-idf tagged in esp-iot-soloution/submodule/esp-idf

the esp-idf submodule should be updated to latest esp-idf release.
Currently it seems to be somewhere after V3.1

Request: Component for current fuel gauges for lithium-ion batteries MAX17048 (AEGHB-287)

Hope to see a component for Battery fuel gauge like MAX17048.

Question: I found a Arduino library for MAX17048 but curious if it works without changes for ESP32 as well.
If not can we see ESP-IDF component for them as well.

How can i use I2C with LittlevGL

Environment

• Development Kit: ESP32-DevKitC
• Kit version: DevKitC/v3
• Module or chip used: ESP32-WROOM-32
• IDF version : 3.1.3
• Build System: Make
• Compiler version: 1.22.0-80-g6c4433a
• Operating System: Linux
• Power Supply: USB

Problem Description

How can i use simultaneously I2C and LittlevGL or spi_lcd?

I2C's pins 21 and 22 are use for SPI as MOSI and SCK

lvgl_example current problem (AEGHB-289)

/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: /esp-iot-solution/examples/hmi/lvgl_example/build/lvgl_example.elf section .dram0.bss' will not fit in region dram0_0_seg'
/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: region `dram0_0_seg' overflowed by 10072 bytes
collect2: error: ld returned 1 exit status
/esp-iot-solution//submodule/esp-idf//make/project.mk:406: recipe for target '/esp-iot-solution/examples/hmi/lvgl_example/build/lvgl_example.elf' failed
make: *** [/esp-iot-solution/examples/hmi/lvgl_example/build/lvgl_example.elf] Error 1

when you encounter this problem, please modify the following:

lv_conf.h:

/*================
 *  THEME USAGE
 *================*/
#define LV_THEME_LIVE_UPDATE    1       /*1: Allow theme switching at run time. Uses 8..10 kB of RAM*/

#define USE_LV_THEME_TEMPL      0       /*Just for test*/
#define USE_LV_THEME_DEFAULT    1       /*Built mainly from the built-in styles. Consumes very few RAM*/
#define USE_LV_THEME_ALIEN      1       /*Dark futuristic theme*/
#define USE_LV_THEME_NIGHT      0       /*Dark elegant theme*/
#define USE_LV_THEME_MONO       0       /*Mono color theme for monochrome displays*/
#define USE_LV_THEME_MATERIAL   0       /*Flat theme with bold colors and light shadows*/
#define USE_LV_THEME_ZEN        0       /*Peaceful, mainly light theme */
#define USE_LV_THEME_NEMO       0       /*Water-like theme based on the movie "Finding Nemo"*/

/*==================
 *    FONT USAGE
 *===================*/

/* More info about fonts: https://docs.littlevgl.com/#Fonts
 * To enable a built-in font use 1,2,4 or 8 values
 * which will determine the bit-per-pixel. Higher value means smoother fonts */
#define USE_LV_FONT_DEJAVU_10              0
#define USE_LV_FONT_DEJAVU_10_LATIN_SUP    0
#define USE_LV_FONT_DEJAVU_10_CYRILLIC     0
#define USE_LV_FONT_SYMBOL_10              0

#define USE_LV_FONT_DEJAVU_20              4
#define USE_LV_FONT_DEJAVU_20_LATIN_SUP    4
#define USE_LV_FONT_DEJAVU_20_CYRILLIC     4
#define USE_LV_FONT_SYMBOL_20              4

#define USE_LV_FONT_DEJAVU_30              0
#define USE_LV_FONT_DEJAVU_30_LATIN_SUP    0
#define USE_LV_FONT_DEJAVU_30_CYRILLIC     0
#define USE_LV_FONT_SYMBOL_30              0

#define USE_LV_FONT_DEJAVU_40              0
#define USE_LV_FONT_DEJAVU_40_LATIN_SUP    0
#define USE_LV_FONT_DEJAVU_40_CYRILLIC     0
#define USE_LV_FONT_SYMBOL_40              0

lv_test_theme.c

/**********************
 *   STATIC FUNCTIONS
 **********************/
static lv_res_t roller_action(lv_obj_t * roller)
{
    lv_theme_t *th = lv_theme_alien_init(100, NULL);
    switch (lv_ddlist_get_selected(roller))
    {
        case 0:
            th = lv_theme_default_init(100, NULL);
            break;
    
        case 1:
            th = lv_theme_alien_init(100, NULL);
            break;
    
        case 2:
            // th = lv_theme_night_init(100, NULL);
            break;
    
        case 3:
            // th = lv_theme_mono_init(100, NULL);
            break;
    
        case 4:
            // th = lv_theme_material_init(100, NULL);
            break;
    
        case 5:
            // th = lv_theme_zen_init(100, NULL);
            break;
    
        case 6:
            // th = lv_theme_nemo_init(100, NULL);
            break;
    
        default:
            break;
    }
    lv_theme_set_current(th);
    return LV_RES_OK;
}

unit-test-app don't work.

I tried unit-test-app, but error occure.

Environment

freeRTOS version:V8.2.0
NEWLIB version:2.2.0
lwIP version:2-0-3-255
ESP-IDF version:v4.0-dev-311-g70eda3d22-dirty

Problem Description

unit-test-app don't work.

Steps to repropduce

$ cd MY_IOT_SOLUTION_PATH/tools/unit-test-app
$ make erase_flash
$ make defconfig
$ make flash IOT_TEST_ALL=1 monitor

--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
Enabling RNG e?ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5888
ho 0 tail 12 room 4
load:0x40078000,len:9188
load:0x40080000,len:6084
0x40080000: _WindowOverflow4 at /home/robotics/esp-iot-solution/submodule/esp-idf/components/freertos/xtensa_vectors.S:1779

entry 0x4008032c
0x4008032c: _KernelExceptionVector at ??:?

I (30) boot: ESP-IDF v3.1.3 2nd stage bootloader
I (30) boot: compile time 10:12:34
I (30) boot: Enabling RNG early entropy source...
I (34) boot: SPI Speed      : 40MHz
I (39) boot: SPI Mode       : DIO
I (43) boot: SPI Flash Size : 4MB
I (47) boot: Partition Table:
I (50) boot: ## Label            Usage          Type ST Offset   Length
I (58) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (65) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (73) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (80) boot:  3 ota_0            OTA app          00 10 00010000 00100000
I (87) boot:  4 ota_1            OTA app          00 11 00110000 00100000
I (95) boot: End of partition table
I (99) boot: No factory image, trying OTA 0
I (104) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x269354 (2528084) map
I (998) esp_image: segment 1: paddr=0x0027937c vaddr=0x3ffc0000 size=0x04350 ( 17232) load
I (1005) esp_image: segment 2: paddr=0x0027d6d4 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /home/robotics/esp-iot-solution/submodule/esp-idf/components/freertos/xtensa_vectors.S:1779

I (1006) esp_image: segment 3: paddr=0x0027dadc vaddr=0x40080400 size=0x02534 (  9524) load
I (1018) esp_image: segment 4: paddr=0x00280018 vaddr=0x400d0018 size=0xfdc08 (1039368) map
0x400d0018: _flash_cache_start at ??:?

I (1387) esp_image: segment 5: paddr=0x0037dc28 vaddr=0x40082934 size=0x17580 ( 95616) load
0x40082934: _xt_medint3 at /home/robotics/esp-iot-solution/submodule/esp-idf/components/freertos/xtensa_vectors.S:1323

I (1427) esp_image: segment 6: paddr=0x003951b0 vaddr=0x400c0000 size=0x00064 (   100) load
I (1427) esp_image: segment 7: paddr=0x0039521c vaddr=0x50000200 size=0x00008 (     8) load
E (1434) esp_image: Image length 3691088 doesn't fit in partition length 1048576
E (1442) boot: OTA app partition slot 0 is not bootable
E (1448) esp_image: image at 0x110000 has invalid magic byte
W (1454) esp_image: image at 0x110000 has invalid SPI mode 141
W (1461) esp_image: image at 0x110000 has invalid SPI size 7
E (1467) boot: OTA app partition slot 1 is not bootable
E (1473) boot: No bootable app partitions in the partition table
Fatal exception (0): IllegalInstruction
epc1=0x40080354, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
0x40080354: _UserExceptionVector at ??:?

assert fails for nvs_get_blob() in lvgl_wificonfig example

Environment

• Development Kit: [ESP32-DevKitC]
• Kit version (for DevKitC): [v4]
• Module or chip used: [ESP32-WROOM-32]
• IDF version (run git describe --tags to find it):
  // v3.1.3
• Build System: [Make]
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  // 5.2.0
• Operating System: [macOS]
• Power Supply: [USB]

Problem Description

assert failed running lvgl_wificonfig example - fails to load blob from NVS

Expected Behavior

should be possible to build and run the example

Actual Behavior

firmware halts with assert failure:

E (841) param: /Users/tim/embedded/esp/esp-iot-solution/components/general/param/param.c:61 (iot_param_load)

Steps to repropduce

make defconfig
make menuconfig

• set serial params
  make erase_flash flash simple_monitor

Code to reproduce this issue

Debug Logs

Hard resetting via RTS pin...
--- forcing DTR inactive
--- forcing RTS inactive
--- Miniterm on /dev/tty.SLAB_USBtoUART 115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
I (202) esp_image: segment 1: paddr=0x0005c1ec vaddr=0x3ffb0000 size=0x032a0 ( 12960) load
I (208) esp_image: segment 2: paddr=0x0005f494 vaddr=0x40080000 size=0x00400 ( 1024) load
I (210) esp_image: segment 3: paddr=0x0005f89c vaddr=0x40080400 size=0x00774 ( 1908) load
I (219) esp_image: segment 4: paddr=0x00060018 vaddr=0x400d0018 size=0x7db34 (514868) map
I (407) esp_image: segment 5: paddr=0x000ddb54 vaddr=0x40080b74 size=0x1001c ( 65564) load
I (445) boot: Loaded app from partition at offset 0x10000
I (445) boot: Disabling RNG early entropy source...
I (446) cpu_start: Pro cpu up.
I (449) cpu_start: Starting app cpu, entry point is 0x40080e48
I (0) cpu_start: App cpu up.
I (460) heap_init: Initializing. RAM available for dynamic allocation:
I (466) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (472) heap_init: At 3FFD09F8 len 0000F608 (61 KiB): DRAM
I (478) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (485) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (491) heap_init: At 40090B90 len 0000F470 (61 KiB): IRAM
I (497) cpu_start: Pro cpu start user code
I (68) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (473) gpio: GPIO[5]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
E (841) param: /Users/tim/embedded/esp/esp-iot-solution/components/general/param/param.c:61 (iot_param_load)

Other items if possible

How to assign static Ip for esp32 in Bridge mode

I am using ESP32-EVB Rev.D olimex board and running Ethernet to wifi transparent bridge. (https://github.com/espressif/esp-iot-solution/tree/master/examples/eth2wifi)
I want to run a web server in same code to change bridge modes (soft ap and station), instead of changing it from menuconfig.
In bridge code obviously my routers DHCP does not assigns ip to esp32, it is just for connection between Ethernet and wifi .
I get mac of soft AP and station but how to assign ip address to them for webserver?
I assigned static ip to eth0 in same code and changed ethernet init function, but bridge is was not working now.
is it possible to assign static ip to esp32 when it is in bridge mode?

My Ethernet initialization function is given below

#define DEVICE_IP "192.168.10.254"
#define DEVICE_GW "192.168.10.1"
#define DEVICE_NETMASK "255.255.0.0"
static void initialise_ethernet(void)
{
esp_err_t ret = ESP_OK;
tcpip_adapter_ip_info_t ipInfo;
inet_pton(AF_INET, DEVICE_IP, &ipInfo.ip);
inet_pton(AF_INET, DEVICE_GW, &ipInfo.gw);
inet_pton(AF_INET, DEVICE_NETMASK, &ipInfo.netmask);
tcpip_adapter_init();
ret = tcpip_adapter_dhcpc_stop(TCPIP_ADAPTER_IF_ETH);
ESP_LOGI(TAG, "dhcp client stop RESULT: %d", ret);
tcpip_adapter_set_ip_info(TCPIP_ADAPTER_IF_ETH, &ipInfo);
eth_config_t config = DEFAULT_ETHERNET_PHY_CONFIG;

// Set the PHY address in the example configuration
config.phy_addr = CONFIG_PHY_ADDRESS;
config.gpio_config = eth_gpio_config_rmii;
// config.tcpip_input = tcpip_adapter_eth_input_sta_output;
config.tcpip_input = tcpip_adapter_eth_input;
#ifdef CONFIG_PHY_USE_POWER_PIN
//Replace the default 'power enable' function with an example-specific
// one that toggles a power GPIO.
config.phy_power_enable = phy_device_power_enable_via_gpio;
#endif
//esp_eth_init_internal(&config)
esp_eth_init(&config);
esp_eth_enable();
}

about iot_lcd.cpp

HI，the engineer who makes the “iot_lcd. cpp”.
I am using “iot_lcd. cpp” on the M5Stack.
Because the LCD and SD SPI of M5Stack are reused.
First of all , I used the APIS of LCD, and second I initialize the SD APIS. It's ok for me to read and write some files by SD APIS.
Finally, after using SD APIS, all the LCD APIS are failed.
added:
My lcd spi is HSPI, using dma channel 1.
My SD spi is VSPI, using dma channel 2.

LittlevGL and thread safety

Environment

• Development Kit: ESP32-DevKitC
• Kit version (for WroverKit/PicoKit/DevKitC): v4
• Module or chip used: ESP32-WROVER-B
• IDF version (run git describe --tags to find it): esp-idf v3.1.3
• Build System: Make
• Compiler version : 1.22.0-80-g6c4433a
• Operating System: Linux
• Power Supply: USB

Problem Description

According to the LittlevGL Documentation LittlevGL is not thread-safe. Here's the relevant section of the documentation:

LittlevGL is not thread-safe. Despite it, it's quite simple to use LittlevGL inside an operating system.

The simple scenario is to don't use the operating system's tasks but use lv_tasks. An lv_task is a function called periodically in lv_task_handler. In the lv_task you can get the state of the sensors, buffers etc and call LittlevGL functions to refresh the GUI. To create an lv_task use: lv_task_create(my_func, period_ms, LV_TASK_PRIO_LOWEST/LOW/MID/HIGH/HIGHEST, custom_ptr)

If you need to use other task or threads you need one mutex which should be taken before calling lv_task_handler and released after it. In addition, you have to use to that mutex in other tasks and threads around every LittlevGL (lv_...) related code. This way you can use LittlevGL in a real multitasking environment. Just use a mutex to avoid concurrent calling of LittlevGL functions.

On the other hand, some of the LittlevGL examples in the esp-iot-solution use LittlevGL in a way that is not thread safe. They create FreeRTOS tasks that call LittlevGL functions while LittlevGL may itself be running in the background in it's own task.

For example, lvgl_example creates a FreeRTOS task here which calls LittlevGL functions in a way that is not thread safe here.

Another example is lvgl_wificonfig which creates a FreeRTOS task here which can end up calling LittlevGL functions in a way that is not thread safe in refresh_wifi_list.

I had a program that occasionally crashed with errors similar to the one shown below when LittlevGL functions were called in a way that was not thread safe. Switching from a FreeRTOS task to a lv_task resolved the issue.

If needed, I can publish a repository on GitHub that shows how to reproduce the below error quickly. The same repository also show how to resolve the issue with an lv_task.

Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x400ec01e  PS      : 0x00060130  A0      : 0x800eb671  A1      : 0x3ffaf6a0  
0x400ec01e: lv_disp_is_mem_fill_supported at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_hal/lv_hal_disp.c:228

A2      : 0x00000001  A3      : 0x3ffc3ce0  A4      : 0x0000004a  A5      : 0x3ffc3ce0  
A6      : 0x00000280  A7      : 0x3ffc87e0  A8      : 0xffffffff  A9      : 0x00000135  
A10     : 0x0000004a  A11     : 0x0000013f  A12     : 0x00000280  A13     : 0x3ffc87e0  
A14     : 0xffffffff  A15     : 0xffffffff  SAR     : 0x00000001  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x0000000f  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  

Backtrace: 0x400ec01e:0x3ffaf6a0 0x400eb66e:0x3ffaf6c0 0x400e552a:0x3ffaf6f0 0x400e6a99:0x3ffaf870 0x400e40dd:0x3ffaf890 0x400e9dae:0x3ffaf8c0 0x400e9e50:0x3ffaf910 0x400e9ee4:0x3ffaf930 0x400e9fd5:0x3ffaf960 0x400ea041:0x3ffaf990 0x400ea081:0x3ffaf9b0 0x400e7255:0x3ffaf9d0 0x400e72f3:0x3ffaf9f0 0x400e28fb:0x3ffafa10 0x400d1c33:0x3ffafa30 0x400d1c97:0x3ffafa50
0x400ec01e: lv_disp_is_mem_fill_supported at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_hal/lv_hal_disp.c:228

0x400eb66e: lv_vfill at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_draw/lv_draw_vbasic.c:161

0x400e552a: lv_draw_rect_main_corner at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_draw/lv_draw_rect.c:316

0x400e6a99: lv_draw_rect at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_draw/lv_draw_rect.c:78

0x400e40dd: lv_obj_design at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_core/lv_obj.c:1495

0x400e9dae: lv_refr_obj at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_core/lv_refr.c:149

0x400e9e50: lv_refr_obj_and_children at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_core/lv_refr.c:149

0x400e9ee4: lv_refr_area_part_vdb at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_core/lv_refr.c:149

0x400e9fd5: lv_refr_area_with_vdb at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_core/lv_refr.c:149

0x400ea041: lv_refr_areas at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_core/lv_refr.c:149

0x400ea081: lv_refr_task at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_core/lv_refr.c:149

0x400e7255: lv_task_exec at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_misc/lv_task.c:262

0x400e72f3: lv_task_handler at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl/lv_misc/lv_task.c:262

0x400e28fb: lv_task_timercb at /home/brian/src/esp-idf/esp-iot-solution/components/hmi/lvgl_gui/lvgl.c:37

0x400d1c33: timer_process_alarm at /home/brian/src/esp-idf/esp-iot-solution/submodule/esp-idf/components/esp32/esp_timer.c:176

0x400d1c97: timer_task at /home/brian/src/esp-idf/esp-iot-solution/submodule/esp-idf/components/esp32/esp_timer.c:176


CPU halted.

components/features/dac_audio/dac_audio.c: i2s_write_bytes is deprecated

CC build/coap/libcoap/src/encode.o
/home/user/esp-iot-solution/components/features/dac_audio/dac_audio.c: In function 'iot_dac_audio_play':
/home/user/esp-iot-solution/components/features/dac_audio/dac_audio.c:62:5: warning: 'i2s_write_bytes' is deprecated [-Wdeprecated-declarations]
     i2s_write_bytes(dac->i2s_num, (const char*) data, length, ticks_to_wait);
     ^
In file included from /home/user/esp-iot-solution/components/features/dac_audio/dac_audio.c:17:0:
/home/user/esp-iot-solution/submodule/esp-idf/components/driver/include/driver/i2s.h:273:5: note: declared here
 int i2s_write_bytes(i2s_port_t i2s_num, const void *src, size_t size, TickType_t ticks_to_wait) __attribute__ ((deprecated));

No output on OLED on i2c using ESP32-Azure-IoT Kit (ESP32-WROVER-B)

Environment

• Development Kit: ESP32-Azure IoT Kit
• Kit version:
• Module or chip used: ESP32-Wrover-B
• IDF version: v3.2-2
• Build System: Make
• Compiler version:
  xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
• Operating System: Linux (via WSL)
• Power Supply: USB

Problem Description

Hi, I have the Azure IoT board and I am having an issue with the OLED displaying the output from the example application from esp32_azure_iot_kit from the examples in the esp-iot-solution repo. I am using the sample as is without any changes as yet but I am planning to enhance this application to write to Azure IoT using the esp-azure sdk.

Before I do this I need to ensure that the board and all sensors are working correctly. Looking at the monitor the application is working correctly and I can see the data being captured from sensors and shown in monitor. The issue is that this data it is not showing up on the OLED. Please Note before I used the example from this repo and powered the board the OLED was working and displaying data/output as it should. It was only when I started using the example so that I could develop against it (have not as yet) did I start having issues.

I have run i2cdetect and it is not showing anything. (see screenshots I have attached)

Expected Behavior

Application to run and sensor data to display on OLED

Actual Behavior

Application runs but no sensor data is displayed on OLED

Steps to repropduce

1. Clone esp-iot-solution repo and make flash monitor application
2. Review monitor to see data is coming through accurately, push button to see that application changes to different sensor data and monitor displays data
3. Notice that no data is displayed at all on OLED.

// It helps if you attach a picture of your setup/wiring here.
Pictures attached below, as well as zip file with .elf file and sdkconfig.

Other items if possible

• [X ] sdkconfig file (attach the sdkconfig file from your project folder)
• [ X] elf file in the build folder (note this may contain all the code details and symbols of your project.)
• coredump (This provides stacks of tasks.)

FileforDebug.zip

new operator kills logging (stack issue?)

Noticed while compiling lvgl_example.

Log works fine until this call:
lcd_obj = new CEspLcdAdapter(&lcd_pins); from esp-iot-solution\components\hmi\gdrivers\gdisp\ST7789\ST7789_adapter.cpp

Added ESP_LOGI("Something", "1"); lines and the are popping up in the monitor until that line. The last line of esp-iot-solution\components\spi_devices\lcd\iot_lcd.cpp\CEspLcd::CEspLcd added a log, that is visible.

The first log what is not visible is this one:
CEspLcdAdapter(lcd_conf_t lcd_conf, int height = LCD_TFTHEIGHT, int width = LCD_TFTWIDTH, bool dma_en = true, int dma_word_size = 1024, int dma_chan = 1) : CEspLcd(lcd_conf, height, width, dma_en, dma_word_size, dma_chan)
{
/ Code here*/
ESP_LOGI("ST7789_ADA", "1");
}
and the logging stops working completely after from anywhere in the code (between the last CEspLCD log and this one is just the background stuff of "new" operator calling a parent class and than the child class constructor - parent constructor is ok, child get's corrupted somehow and corrupts logging as well).

Not the logging concerns me but rather the new operator - if does corrupts the stack or anything else which kicks out logging could result in unstable firmware ...

IDF version: 3.2.2 (iot-solution cannot be compiled with 3.3)
ESP-WROOM-32/ESP32_Core_Board using ST7789 LCD.
Tools installed with esp-idf-tools-setup-2.0.exe.

Otherwise the example sort of works, I can see content on the LCD ...

Industry Protocols on Azure Kit ESP32

On this link
https://catalog.azureiotsolutions.com/details?title=AzureKit-ESP32&source=all-devices-page

It is written that Azure ESP 32 kit supports the following industrial protocols

Industry Protocols
CAN bus , OPC UA , PPMP , Modbus , ZigBee , PROFINET , OPC Classic , EtherCAT

I am unable to find any relevant software stack regarding their implementation. Are they under development?. Any help would be appreciated.

Thanks.

warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'

/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:39:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:41:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueASyncPut':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:57:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:59:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueASyncPush':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:73:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:75:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueASyncInsert':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:86:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:88:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueASyncRemove':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:110:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:112:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueASyncIsIn':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:139:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:141:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueGSyncGet':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:172:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:176:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueGSyncPut':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:193:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:195:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueGSyncPush':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:210:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:212:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueGSyncInsert':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:224:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:226:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueGSyncRemove':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:248:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:250:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c: In function 'gfxQueueGSyncIsIn':
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:277:13: warning: 'taskENTER_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portENTER_CRITICAL(mux)'
   gfxSystemLock();
             ^
/home/user/esp-iot-solution/components/hmi/ugfx_gui/ugfx/src/gqueue/gqueue.c:279:13: warning: 'taskEXIT_CRITICAL(mux)' is deprecated in ESP-IDF, consider using 'portEXIT_CRITICAL(mux)'
   gfxSystemUnlock();
             ^

Is it possible to compile the lvgl examples on idf 4.0 / gcc 8.2 tool chain? (AEGHB-290)

Environment

• Development Kit: none

• Kit version

• Module or chip used: ESP32-WROVER-B

• IDF version (run git describe --tags to find it): v4.0-dev-1443-g39f090a4f

• Build System: both

• Compiler version (run xtensa-esp32-elf-gcc --version to find it): 8.2.0

• Operating System: Fedora 30

• Power Supply: external 3.3V

Problem Description

trying to compile the lvgl examples on idf 4.0 / gcc 8.2 tool chain results in dozens of errors. Is this even supported?

Expected Behavior

successful make

Actual Behavior

hundreds of errors like
/opt/esp32-idf/projects/esp-iot-solution/submodule/esp-idf/components/newlib/include/sys/reent.h:166:8: error: '_VOID' does not name a type
extern _VOID _EXFUN(__sinit,(struct _reent *));

/opt/esp32-idf/esp-idf/tools/xtensa-esp32-elf/esp32-2019r1-8.2.0/xtensa-esp32-elf/xtensa-esp32-elf/sys-include/stdlib.h:155:44: error: expected initializer before '__result_use_check'
void *reallocarray(void *, size_t, size_t) __result_use_check __alloc_size(2)

etc
other projects build fine.

Steps to repropduce

1. install current idf + current toolchain according to docs
2. make menuconfig
3. make

Code to reproduce this issue

Debug Logs

Other items if possible

ESP-IDF iot_apds9960 - INT PIN isnt working using ESP-IDF Library

Hello there!
I'm having issues to enable the gesture interruption pin of APDS9960 using the ESP-IDF library, when the sensor starts it doesnt change the int pin to the high state.
I already tested using the arduino library and works very well. Im using a osciloscope to analyze the signal.

Here is my gesture init:

` esp_err_t iot_apds9960_gesture_init(apds9960_handle_t sensor)
{
/* Set default values for ambient light and proximity registers */
iot_apds9960_set_adc_integration_time(sensor, 10);
iot_apds9960_set_ambient_light_gain(sensor, APDS9960_AGAIN_4X);

iot_apds9960_enable_gesture_engine(sensor, false);
iot_apds9960_enable_proximity_engine(sensor, false);
iot_apds9960_enable_color_engine(sensor, false);


iot_apds9960_enable_proximity_interrupt(sensor, true); <- I added this
iot_apds9960_clear_interrupt(sensor);

iot_apds9960_enable(sensor, false);
iot_apds9960_enable(sensor, true);

iot_apds9960_set_gesture_dimensions(sensor, APDS9960_DIMENSIONS_ALL);
iot_apds9960_set_gesture_fifo_threshold(sensor, APDS9960_GFIFO_4);
iot_apds9960_set_gesture_gain(sensor, APDS9960_GGAIN_4X);
iot_apds9960_set_gesture_proximity_threshold(sensor, 10, 10);
iot_apds9960_reset_counts(sensor);

iot_apds9960_set_mode(sensor, APDS9960_ALL);
iot_apds9960_set_led_drive_boost(sensor, APDS9960_LEDDRIVE_100MA, APDS9960_LEDBOOST_100PCNT);
iot_apds9960_set_gesture_waittime(sensor, APDS9960_GWTIME_2_8MS);

iot_apds9960_set_gesture_pulse(sensor, APDS9960_GPULSELEN_8US, 8); // padrão tava 8US, 8

iot_apds9960_enable_proximity_engine(sensor, true);
iot_apds9960_enable_gesture_interrupt(sensor, true); <- I added this
return iot_apds9960_enable_gesture_engine(sensor, true);

}`

Any one can give me an advice about this?

Thank you in advance.
Best regards
Rafael F. Silva

Nonsensical pressure readings with BME280 sensor

Hi, when using an i2c bme280 the pressure readings were nonsensical. I traced the issue to two mistakes in the function iot_bme280_read_pressure() (esp-iot-solution/components/i2c_devices/sensor/bme280/bme280.c). That function should return the athmospheric pressure in hPa.
The problem was two fold:

1. it reads the wrong register BME280_REGISTER_TEMPDATA instead of BME280_REGISTER_PRESSUREDATA
2. there was a division by 100 omitted at the return statement.

Here is the corrected function:

float iot_bme280_read_pressure(bme280_handle_t dev)
{
    int64_t var1, var2, p;
    uint8_t data[3] = { 0 };
    bme280_dev_t* device = (bme280_dev_t*) dev;

    if (iot_bme280_read_temperature(dev) == ESP_FAIL) {
        // must be done first to get t_fine
        return ESP_FAIL;
    }

    if (iot_bme280_read(dev, BME280_REGISTER_PRESSUREDATA, 3, data) == ESP_FAIL) {
        return ESP_FAIL;
    }

    int32_t adc_P = (data[0] << 16) | (data[1] << 8) | data[2];
    if (adc_P == 0x800000) {  // value in case pressure measurement was disabled
        return ESP_FAIL;
    }

    adc_P >>= 4;

    var1 = ((int64_t) device->t_fine) - 128000;
    var2 = var1 * var1 * (int64_t) device->data_t.dig_p6;
    var2 = var2 + ((var1 * (int64_t) device->data_t.dig_p5) << 17);
    var2 = var2 + (((int64_t) device->data_t.dig_p4) << 35);
    var1 = ((var1 * var1 * (int64_t) device->data_t.dig_p3) >> 8)
            + ((var1 * (int64_t) device->data_t.dig_p2) << 12);
    var1 = (((((int64_t) 1) << 47) + var1)) * ((int64_t) device->data_t.dig_p1)
            >> 33;

    if (var1 == 0) {
        return ESP_FAIL; // avoid exception caused by division by zero
    }
    p = 1048576 - adc_P;
    p = (((p << 31) - var2) * 3125) / var1;
    var1 = (((int64_t) device->data_t.dig_p9) * (p >> 13) * (p >> 13)) >> 25;
    var2 = (((int64_t) device->data_t.dig_p8) * p) >> 19;

    p = ((p + var1 + var2) >> 8) + (((int64_t) device->data_t.dig_p7) << 4);
    p = p >> 8; // /256
    return ((float)p/100);
}

I take no credit for this since I merely compared side by side with the Bluedot Arduino library (BlueDot-Arduino/BlueDot_BME280).

Thanks

Is it possible to compile the empty_project on idf 4.0 / gcc 8.2 tool chain?

Environment

• Development Kit: ESP32-DevKitC
• Kit version
• Module or chip used: [ESP32-WROOM-32
• IDF version (run git describe --tags to find it): v4.0-dev-1287-gd7e659df2
• Build System: Make
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):xtensa-esp32-elf-gcc.exe (crosstool-NG esp32-2019r1) 8.2.0
• Operating System: Windows
• Power Supply: USB

Problem Description

  building the empty project, then report some errors!

Debug Logs

Administrator@DE-0011 MSYS /d/lin_work/esp32_work/esp32_prj/empty_project

make all

/d/lin_work/esp32_work/esp32_prj/esp/esp-iot-solution/submodule/esp-idf//make/project.mk:60: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
WARNING: Failed to find Xtensa toolchain, may need to alter PATH or set one in the configuration menu
/d/lin_work/esp32_work/esp32_prj/esp/esp-iot-solution/submodule/esp-idf/make/project.mk:60: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
WARNING: Failed to find Xtensa toolchain, may need to alter PATH or set one in the configuration menu
WARNING: Missing submodule components/bootloader/subproject/components/micro-ecc/micro-ecc...
Attempting 'git submodule update --init components/bootloader/subproject/components/micro-ecc/micro-ecc' in esp-idf root directory...
error: 路径规格 'components/bootloader/subproject/components/micro-ecc/micro-ecc' 未匹配任何 git 已知文件
make[1]: *** [/d/lin_work/esp32_work/esp32_prj/esp/esp-iot-solution/submodule/esp-idf/make/project.mk:531：/d/lin_work/esp32_work/esp32_prj/esp/esp-iot-solution/submodule/esp-idf/components/bootloader/subproject/components/micro-ecc/micro-ecc/.git] 错误 1
make: *** [/d/lin_work/esp32_work/esp32_prj/esp/esp-iot-solution/submodule/esp-idf/components/bootloader/Makefile.projbuild:41：/d/lin_work/esp32_work/esp32_prj/empty_project/build/bootloader/bootloader.bin] 错误 2

alink_os: Warning: system_get_time is deprecated

/home/user/esp-iot-solution/components/platforms/alink/adaptation/alink_os.c:273:5: warning: 'system_get_time' is deprecated [-Wdeprecated-declarations]
     return system_get_time() / 1000;
     ^
In file included from /home/user/esp-iot-solution/components/platforms/alink/adaptation/alink_os.c:25:0:
/home/user/esp-iot-solution/submodule/esp-idf/components/esp32/include/esp_system.h:96:10: note: declared here
 uint32_t system_get_time(void)  __attribute__ ((deprecated));
          ^

Custom fonts for ssd1306 component

Hi all. Please, I managed to break up the ssd1306 component under esp8266 (esp-12F). But now I have another question, I found no mention of how to create and add my own fonts? Thank you for the hint :)

Touch does not work properly

I am running lvgl_examle, I use the same screen as in the example, but I can't use touch. I didn't find any problems when I looked at the touch source code, so I tested the touch separately and the printed x and y were normal.
But if I first initialize the display and then use touch, the data I get will be zero.

Test code:

spi_device_handle_t spi_wr = NULL;
    lcd_conf_t lcd_pins = {
        .lcd_model = LCD_MOD_ST7789,
        .pin_num_miso = CONFIG_LVGL_LCD_MISO_GPIO,
        .pin_num_mosi = CONFIG_LVGL_LCD_MOSI_GPIO,
        .pin_num_clk = CONFIG_LVGL_LCD_CLK_GPIO,
        .pin_num_cs = CONFIG_LVGL_LCD_CS_GPIO,
        .pin_num_dc = CONFIG_LVGL_LCD_DC_GPIO,
        .pin_num_rst = CONFIG_LVGL_LCD_RESET_GPIO,
        .pin_num_bckl = CONFIG_LVGL_LCD_BL_GPIO,
        .clk_freq = CONFIG_LVGL_LCD_SPI_CLOCK,
        .rst_active_level = 0,
        .bckl_active_level = 1,
        .spi_host = (spi_host_device_t)CONFIG_LVGL_LCD_SPI_NUM,
        .init_spi_bus = true,    //Initialize the SPI bus for the first time
    };
    lcd_dc_t dc;
    dc.dc_level = 0;
    dc.dc_io = lcd_pins.pin_num_dc;

    lcd_init(&lcd_pins, &spi_wr, &dc, 1);

    xpt_conf_t xpt_conf = {
        .pin_num_cs = CONFIG_LVGL_TOUCH_CS_GPIO,               
        .pin_num_irq = CONFIG_LVGL_TOUCH_IRQ_GPIO,             
        .clk_freq = 1 * 1000 * 1000,                          
        .spi_host = (spi_host_device_t)CONFIG_LVGL_LCD_SPI_NUM, 
        .pin_num_miso = -1,                                     
        .pin_num_mosi = -1,                                    
        .pin_num_clk = -1,                                     
        .dma_chan = 1,
        .init_spi_bus = false, //The second time will not be initialized
    };
    spi_device_handle_t m_spi = NULL;
    iot_xpt2046_init(&xpt_conf, &m_spi);

    for (;;)
    {
        int x = iot_xpt2046_readdata(m_spi, 0xD0, 1);
        int y = iot_xpt2046_readdata(m_spi, 0x90, 1);
        ESP_LOGI(TAG, "x:%d , y:%d", x, y);
        vTaskDelay(50 / portTICK_PERIOD_MS);
    }

Some problem with i2s_lcd_write_data()

Environment

• Development Kit: [ESP32-PICO-Kit]

• Kit version(PicoKit): Not sure

• Module or chip used: [ESP32-PICO-D4]

• IDF version : v3.3-beta1-179-ge931fe9f5

• Build System: [CMake]

• Compiler version: (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0

• Operating System: [Windows]

• Power Supply: [USB]

repeat sending data from i2s_lcd_write_data() not correct

expect: 0xab 0xab 0xab 0xab for the first 4 bytes at least

actual: 0xab 0xab 0xaf 0a51

I am trying to understand how 8080 output from i2s work. To do this I have copied 5 files from \esp-iot-solution-master\components\i2s_devices\lcd_common to the root directory of a hello-world program with structure as below. All i2s_lcd_xxx.c and .h files in the same directory as hello_world_main.c for simplicity.

• i2s_8080_lcd
  -CMakeLists
  -Makefile
  -sdkconfig
  -main
  |- CMakelists
  |- hello_world_main.c
  |- i2s_lcd.c
  |- i2s_lcd_com.c
  |- i2s_lcd_com.h
  |- iot_i2s_lcd.h

Code to reproduce this issue (hello_world_main.c) as below

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_system.h"
#include "esp_spi_flash.h"
#include "sdkconfig.h"
#include "../components/drv/dummy.h"
#include "i2s_lcd_com.h"
#include "iot_i2s_lcd.h"

#define I2S_PORT_NUM	(0)
#define LCD_D0_PIN  (19)
#define LCD_D1_PIN  (21)
#define LCD_D2_PIN  (0)
#define LCD_D3_PIN  (22)
#define LCD_D4_PIN  (23)
#define LCD_D5_PIN  (33)
#define LCD_D6_PIN  (32)
#define LCD_D7_PIN  (27)
#define LCD_D8_PIN  (25)
#define LCD_D9_PIN  (26)
#define LCD_D10_PIN (12)
#define LCD_D11_PIN (13)
#define LCD_D12_PIN (14)
#define LCD_D13_PIN (15)
#define LCD_D14_PIN (2)
#define LCD_D15_PIN (4)
#define LCD_WR_PIN  (18)
#define LCD_RS_PIN  (5)

void app_main()
{
    dummy_init();

    i2s_lcd_config_t d2805_conf={
    		16,	//data_width = 16
			{
			        LCD_D0_PIN, LCD_D1_PIN, LCD_D2_PIN, LCD_D3_PIN,
			        LCD_D4_PIN, LCD_D5_PIN, LCD_D6_PIN, LCD_D7_PIN,
			        LCD_D8_PIN, LCD_D9_PIN, LCD_D10_PIN,LCD_D11_PIN,
			        LCD_D12_PIN, LCD_D13_PIN, LCD_D14_PIN, LCD_D15_PIN
			},
			LCD_WR_PIN,
			LCD_RS_PIN
    };

    i2s_lcd_handle_t d2805_handle = i2s_lcd_create(I2S_PORT_NUM, &d2805_conf);
    DRAM_ATTR static const char fb[10] = {0xab, 0xab, 0xab, 0xab, 0x55, 0xaf, 0x3d, 0x6f, 0x44, 0x78};

    for(;;){
    	i2s_lcd_write_data(d2805_handle, (char *)&fb, sizeof(fb), portTICK_PERIOD_MS, false);
    }
}

Pins [0:15] are wired to a logic analyzer to visualize the bus. This program only send a fixed byte pattern of 10. It was expected the pattern should match the byte array defined in fb[10] but the actual waveform is shown below.

The first two bytes are always correct. They match the first two elements 0xab 0xab, but the 3rd and 4th elements started to corrupt. It should be 0xab 0xab. I have scripted them to be the same as the 1st and 2nd byte to avoid any mistake in jumper wires. Since the 1st and 2nd bytes are correct, it means my wiring should be OK. Inconsistency is very "consistent"! I mean after a restart or power removal, the 3rd and 4th bytes are always 0xaf 0x51. So the error is a systematic one.

What is the mistake? How to achieve a simple result like repeat sending some byte array like above?

i2c bus usage in arduino IDE (esp32 azure IoT kit)

Hello,
I would like to have access to the sensors' data of esp32 azure IoT kit. I am trying to make it through the I2C bus. Although, the scanning proccess on I2C does not detect any device.
I am coding in arduino IDE. Is there any advices?
Thank you!

WroverLCD example fails at lcd_cmd()

Environment

• Development Kit: [ESP32-Wrover-Kit]
• Kit version (for WroverKit): [v1|v2|v3|v4]
• Module or chip used: [ESP32-WROVER|ESP32-WROVER-I|ESP32-WROVER-B|ESP32-WROVER-IB]
• IDF version (run git describe --tags to find it):
  v3.3-dev-301-gadd7c49a2
• Build System: [Make|CMake]
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  xtensa-esp32-elf-gcc.exe (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
• Operating System: [Windows]
• Power Supply: [USB]

Problem Description

Panic happens while trying wrover esp example

//Detailed problem description goes here.

Expected Behavior

Some text should be written on wrover lcd display

Actual Behavior

Panic because of assert at picture below. I used jtag to see where assert happens.
You get assert at this line:

Steps to repropduce

1. Make project originally build from blink example appended with LCD code from this git repository
2. you could pull from repository:
3. build project & upload to wrover

Code to reproduce this issue

https://github.com/zhivko/WroverLCD

make: *** No rule to make target '//Makefile'. Stop.

Environment

• Development Kit: ESP32-DevKitC
• Kit version (for WroverKit/PicoKit/DevKitC): v1
• Module or chip used: ESP32-WROOM-32
• IDF version : v3.3
• Build System: Make
• Compiler version : (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
• Operating System: Windows
• Power Supply: USB

Problem Description

When an example ulp project(esp-idf-solutions repository) is built it fails by saying "make: *** No rule to make target '//Makefile'. Stop." However, I have installed and added the ulp toolchain in path. The ulp examples in the main esp-idf repository builds and I can flash successfully. The ulp examples of esp-idf-solutions do not work.

Expected Behavior

Expected Behavior is that Build should be successful.

Actual Behavior

Gives build error: make: *** No rule to make target '//Makefile'. Stop.

Steps to repropduce

1. navigate to example project
2. run make flash

Debug Logs

abish@DESKTOP-S465RFF MINGW32 /d/esp/ulp_tsens

$ make flash
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5
Compiler version: 5.2.0
make: *** No rule to make target '//Makefile'.  Stop.

Other items if possible

sdkconfig.txt