ESP32 WiFi — различия между версиями
(→Working with TCP/IP) |
(→Initializing the WiFi environment) |
||
Строка 42: | Строка 42: | ||
• Wikipedia – IEEE 802.11i-2004 | • Wikipedia – IEEE 802.11i-2004 | ||
− | === | + | ===Инициализация WiFi окружения=== |
WiFi является лишь частью возможностей ESP32. Может быть много случаев, когда WiFi не требуется. Инициализация WiFi выполняется разработчиком приложения путем вызова метода esp_wifi_init(). | WiFi является лишь частью возможностей ESP32. Может быть много случаев, когда WiFi не требуется. Инициализация WiFi выполняется разработчиком приложения путем вызова метода esp_wifi_init(). | ||
Версия 21:27, 28 июня 2017
Содержание
- 1 WiFi Theory
- 2 Инициализация WiFi окружения
- 3 Setting the operation mode
- 4 Scanning for access points
- 5 Обработчики событий WiFi
- 6 Настройки WiFi клиента
- 7 Запуск модуля WiFi
- 8 Подключение к точке доступа в режиме клиента
- 9 Запуск в режиме точки доступа
- 10 Working with connected stations
- 11 WiFi at boot time
- 12 The DHCP client
- 13 The DHCP server
- 14 Current IP Address, netmask and gateway
- 15 WiFi Protected Setup – WPS
- 16 Алгоритм инициализации WiFi
WiFi Theory
When working with a WiFi oriented device, it is important that we have at least some understanding of the concepts related to WiFi. At a high level, WiFi is the ability to participate in TCP/IP connections over a wireless communication link. WiFi is specifically the set of protocols described in the IEEE 802.11 Wireless LAN architecture.
Within this story, a device called a Wireless Access Point (access point or AP) acts as the hub of all communications. Typically it is connected to (or acts as) as TCP/IP router to the rest of the TCP/IP network. For example, in your home, you are likely to have a WiFi access point connected to your modem (cable or DSL). WiFi connections are then formed to the access point (through devices called stations) and TCP/IP traffic flows through the access point to the Internet.
The devices that connect to the access points are called "stations":
An ESP32 device can play the role of an Access Point, a Station or both at the same time.
Very commonly, the access point also has a network connection to the Internet and acts as a bridge between the wireless network and the broader TCP/IP network that is the Internet.
A collection of stations that wish to communicate with each other is termed a Basic Service Set (BSS). The common configuration is what is known as an Infrastructure BSS. In this mode, all communications inbound and outbound from an individual station are routed through the access point.
A station must associate itself with an access point in order to participate in the story. A station may only be associated with a single access point at any one time. Each participant in the network has a unique identifier called the MAC address. This is a 48bit value.
When we have multiple access points within wireless range, the station needs to know with which one to connect. Each access point has a network identifier called the BSSID (or more commonly just SSID). SSID is service set identifier. It is a 32 character value that represents the target of packets of information sent over the network.
See also: • Wikipedia – Wireless access point • Wikipedia – IEEE 802.11 • Wikipedia – WiFi Protected Access • Wikipedia – IEEE 802.11i-2004
Инициализация WiFi окружения
WiFi является лишь частью возможностей ESP32. Может быть много случаев, когда WiFi не требуется. Инициализация WiFi выполняется разработчиком приложения путем вызова метода esp_wifi_init().
Рекомендуется провести инициализацию следующим образом:
wifi_init_config_t config = WIFI_INIT_CONFIG_DEFAULT();
esp_wifi_init(&config);
See also: • esp_wifi_init
Setting the operation mode
The ESP32 can either be a station in the network, an access point for other devices or both. Remember, when an ESP32 is being a station, it can connect to a remote access point (your WiFi hub) while when being an access point, other WiFi stations can connect to the ESP32 (think of the ESP32 as becoming a WiFi hub). This is a fundamental consideration and we will want to choose how the device behaves early on in our application design. Once we have chosen what we want, we set a global mode property which indicates which of the operational modes our device will perform (station, access point or station AND access point).
This choice is set with a call to esp_wifi_set_mode(). The parameter is an instance of wifi_mode_t which can have a value of WIFI_MODE_NULL, WIFI_MODE_STA, WIFI_MODE_AP or WIFI_MODE_APSTA. We can call esp_wifi_get_mode() to retrieve our current mode state.
Scanning for access points
If the ESP32 is going to be performing the role of a station we will need to connect to an access point. We can request a list of the available access points against which we can attempt to connect. We do this using the esp_wifi_scan_start() function.
The results of a WiFi scan are stored internally in ESP32 dynamically allocated storage.
The data is returned to us when we call esp_wifi_scan_get_ap_records() which also releases the internally allocated storage. As such, this should be considered a destructive read.
A scan record is contained in an instance of a wifi_ap_record_t structure that contains: uint8_t bssid[6] uint8_t ssid[32] uint8_t primary wifi_second_chan_t second int8_t rssi wifi_auth_mode_t authmode
The wifi_auth_mode_t is one of: • WIFI_AUTH_OPEN – No security. • WIFI_AUTH_WEP – WEP security. • WIFI_AUTH_WPA_PSK – WPA security. • WIFI_AUTH_WPA2_PSK – WPA2 security. • WIFI_AUTH_WPA_WPA2_PSK – WPA or WPA2 security.
After issuing the request to start performing a scan, we will be informed that the scan completed when a SYSTEM_EVENT_SCAN_DONE event is published. The event data contains the number of access points found but that can also be retrieved with a call to esp_wifi_scan_get_ap_num().
Should we wish to cancel the scanning before it completes on its own, we can call esp_wifi_scan_stop().
Here is a complete sample application illustrating performing a WiFi scan. Much of the work is performed in the event handler. When we detect a scan completion event, we retrieve the located access points and log their details.
#include "esp_wifi.h"
#include "esp_system.h"
#include "esp_event.h"
#include "esp_event_loop.h"
#include "nvs_flash.h"
esp_err_t event_handler(void *ctx, system_event_t *event)
{
if (event->event_id == SYSTEM_EVENT_SCAN_DONE) {
printf("Number of access points found: %d\n",
event->event_info.scan_done.number);
uint16_t apCount = event->event_info.scan_done.number;
if (apCount == 0) {
return ESP_OK;
}
wifi_ap_record_t *list =
(wifi_ap_record_t *)malloc(sizeof(wifi_ap_record_t) * apCount);
ESP_ERROR_CHECK(esp_wifi_scan_get_ap_records(&apCount, list));
int i;
for (i=0; i<apCount; i++) {
char *authmode;
switch(list[i].authmode) {
case WIFI_AUTH_OPEN:
authmode = "WIFI_AUTH_OPEN";
break;
case WIFI_AUTH_WEP:
authmode = "WIFI_AUTH_WEP";
break;
case WIFI_AUTH_WPA_PSK:
authmode = "WIFI_AUTH_WPA_PSK";
break;
case WIFI_AUTH_WPA2_PSK:
authmode = "WIFI_AUTH_WPA2_PSK";
break;
case WIFI_AUTH_WPA_WPA2_PSK:
authmode = "WIFI_AUTH_WPA_WPA2_PSK";
break;
default:
authmode = "Unknown";
break;
}
printf("ssid=%s, rssi=%d, authmode=%s\n",
list[i].ssid, list[i].rssi, authmode);
}
free(list);
}
return ESP_OK;
}
int app_main(void)
{
nvs_flash_init();
tcpip_adapter_init();
ESP_ERROR_CHECK(esp_event_loop_init(event_handler, NULL));
wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
ESP_ERROR_CHECK(esp_wifi_init(&cfg));
ESP_ERROR_CHECK(esp_wifi_set_storage(WIFI_STORAGE_RAM));
ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));
ESP_ERROR_CHECK(esp_wifi_start());
// Let us test a WiFi scan ...
wifi_scan_config_t scanConf = {
.ssid = NULL,
.bssid = NULL,
.channel = 0,
.show_hidden = 1
};
ESP_ERROR_CHECK(esp_wifi_scan_start(&scanConf, 0));
return 0;
}
Using the Arduino libraries we can also make network scans. Here is an example:
int8_t count = WiFi.scanNetworks();
printf("Found %d networks\n", count);
for (uint8_t i=0; i<count; i++) {
String ssid;
uint8_t encryptionType;
int32_t RSSI;
uint8_t *BSSID;
int32_t channel;
WiFi.getNetworkInfo(i, ssid, encryptionType, RSSI, BSSID, channel);
printf("ssid=%s\n", ssid.c_str());
}
See also: • Handling WiFi events • esp_wifi_scan_start • esp_wifi_scan_stop • esp_wifi_scan_get_ap_records • esp_wifi_scan_get_ap_num
Обработчики событий WiFi
Во время работы в качестве устройства WiFi, могут возникнуть события представляющие интерес для приложения. Поскольку мы не знаем когда произойдет то или иное событие, мы не можем заблокировать приложение в их ожидании. Вместо этого мы должны определить функцию обратного вызова, которая будет вызвана если событие произойдет. Функция esp_event_loop_init() регистрирует функцию обратного вызова.
Пример функции обратного вызова:
esp_err_t eventHandler(void *ctx, system_event_t *event) {
// здесь код обработчика события ...
return ESP_OK;
}
Как правило мы должны будем включить следующие инклюды:
- #include <esp_event.h>
- #include <esp_event_loop.h>
- #include <esp_wifi.h>
- #include <esp_err.h>
Пример регистрации функции обратного вызова:
esp_event_loop_init(eventHandler, NULL);
Если в последствии предполагается изменение обработчика обратного вызова можно использовать:
esp_event_loop_set_cb(eventHandler, NULL);
В функцию обратного вызова передается параметр с деталями события. Тип данных этого параметра - «system_event_t», который содержит: System_event_id_t event_id и System_event_info_t event_info
Мы должны включить «esp_event.h», чтобы получить доступ к этим данным.
Теперь мы рассмотрим два свойства, переданные обработчику событий в system_event_t - этими свойствами являются «event_id» и «event_info». Event_id описывает, какое событие было обнаружено, а event_info содержит детали события, основанные на типе, указанном в event_id.
- event_id – перечисление содержащее тип события, принимает следующие значения:
- SYSTEM_EVENT_WIFI_READY – ESP32 WiFi is ready.
- SYSTEM_EVENT_SCAN_DONE – Сканирование точек доступа завершено, список доступен.
- SYSTEM_EVENT_STA_START – Started being a station.
- SYSTEM_EVENT_STA_STOP – Stopped being a station.
- SYSTEM_EVENT_STA_CONNECTED – Connected to an access point as a station. The connected data field is valid to be accessed.
- SYSTEM_EVENT_STA_DISCONNECTED – Disconnected from access point while being a station. The disconnected data field is valid to be accessed.
- SYSTEM_EVENT_STA_AUTHMODE_CHANGE – Authentication mode has changed. The auth_change data field is valid to be accessed.
- SYSTEM_EVENT_STA_GOT_IP – Got an assigned IP address from the access point that we connected to while being a station. The got_ip data field is valid to be accessed.
- SYSTEM_EVENT_AP_START – Started being an access point.
- SYSTEM_EVENT_AP_STOP – Stopped being an access point.
- SYSTEM_EVENT_AP_STACONNECTED – A station connected to us while we are being an access point. The sta_connected data field is valid to be accessed.
- SYSTEM_EVENT_AP_STADISCONNECTED – A station disconnected from us while we are being an access point. The sta_disconnected data field is valid to be accessed.
- SYSTEM_EVENT_AP_PROBEREQRECVED – Received a probe request while we are being an access point. The ap_probereqrecved data field is valid to be accessed.
- event_info – This is a C language union of distinct data types that are keyed off the event_id. The different structures contained within are:
Structure | Field | Event |
---|---|---|
system_event_sta_connected_t | connected | SYSTEM_EVENT_STA_CONNECTED |
system_event_sta_disconnected_t | disconnected | SYSTEM_EVENT_STA_DISCONNECTED |
system_event_sta_scan_done_t | scan_done | SYSTEM_EVENT_SCAN_DONE |
system_event_sta_authmode_change_t | auth_change | SYSTEM_EVENT_STA_AUTHMODE_CHANGE |
system_event_sta_got_ip_t | got_ip | SYSTEM_EVENT_STA_GOT_IP |
system_event_ap_staconnected_t | sta_connected | SYSTEM_EVENT_AP_STACONNECTED |
system_event_ao_stadisconnected_t | sta_disconnected | SYSTEM_EVENT_AP_STADISCONNECTED |
system_event_ap_probe_req_rx_t | ap_probereqrecved | SYSTEM_EVENT_AP_PROBEREQRECVED |
These data structures contain information pertinent to the event type received.
system_event_sta_connected_t
This data type is associated with the SYSTEM_EVENT_STA_CONNECT event.
- uint8_t ssid[32]
- uint8_t ssid_len
- uint8_t bssid[6]
- uint8_t channel
- wifi_auth_mode_t authmode
The ssid is the WiFi network name to which we connected. The ssid_len is the number of bytes in the ssid field that contain the name. The bssid is the MAC address of the access point. The channel is the wireless channel used for the connection. The authmode is the security authentication mode used during the connection.
system_event_sta_disconnected_t
This data type is associated with the SYSTEM_EVENT_STA_DISCONNECTED event.
- uint8_t ssid[32]
- uint8_t ssid_len
- uint8_t bssid[6]
- uint8_t reason
The reason code is an indication of why we disconnected. Symbolics are defined for each of the numeric reason codes to allow us to write more elegant and comprehensible applications should we need to consider a reason code.:
- WIFI_REASON_UNSPECIFIED – 1
- WIFI_REASON_AUTH_EXPIRE – 2
- WIFI_REASON_AUTH_LEAVE – 3
- WIFI_REASON_ASSOC_EXPIRE – 4
- WIFI_REASON_ASSOC_TOOMANY – 5
- WIFI_REASON_NOT_AUTHED – 6
- WIFI_REASON_NOT_ASSOCED – 7
- WIFI_REASON_ASSOC_LEAVE – 8
- WIFI_REASON_ASSOC_NOT_AUTHED – 9
- WIFI_REASON_DISASSOC_PWRCAP_BAD – 10
- WIFI_REASON_DISASSOC_SUPCHAN_BAD – 11
- WIFI_REASON_IE_INVALID – 13
- WIFI_REASON_MIC_FAILURE – 14
- WIFI_REASON_4WAY_HANDSHAKE_TIMEOUT – 15
- WIFI_REASON_GROUP_KEY_UPDATE_TIMEOUT – 16
- WIFI_REASON_IE_IN_4WAY_DIFFERS – 17
- WIFI_REASON_GROUP_CIPHER_INVALID – 18
- WIFI_REASON_PAIRWISE_CIPHER_INVALID – 19
- WIFI_REASON_AKMP_INVALID – 20
- WIFI_REASON_UNSUPP_RSN_IE_VERSION – 21
- WIFI_REASON_INVALID_RSN_IE_CAP – 22
- WIFI_REASON_802_1X_AUTH_FAILED – 23
- WIFI_REASON_CIPHER_SUITE_REJECTED – 24
- WIFI_REASON_BEACON_TIMEOUT – 200
- WIFI_REASON_NO_AP_FOUND – 201
- WIFI_REASON_AUTH_FAIL – 202
- WIFI_REASON_ASSOC_FAIL – 203
- WIFI_REASON_HANDSHAKE_TIMEOUT – 204
system_event_sta_scan_done_t
This data type is associated with the SYSTEM_EVENT_SCAN_DONE event.
- uint32_t status
- uint8_t number
- uint8_t scan_id
See also:
- Scanning for access points
- esp_wifi_scan_get_ap_records
system_event_authmode_change_t
This data type is associated with the SYSTEM_EVENT_STA_AUTHMODE_CHANGE event.
- wifi_auth_mode_t old_mode
- wifi_auth_mode_t new_mode
system_event_sta_got_ip_t
This data type is associated with the SYSTEM_EVENT_STA_GOT_IP event.
- tcpip_adapter_ip_info_t ip_info
The ip_info element is an instance of a tcpip_adapter_ip_info_t which contains three fields:
- ip -The IP address.
- netmask – The network mask.
- gw – The gateway for communications.
All three of these fields are of ip4_addr_t which is a 32bit representation of an IP address. During development, you might want to consider logging the IP address of the device. You can do this using: ESP_LOGD(tag, "Got an IP: " IPSTR, IP2STR(&event->event_info.got_ip.ip_info.ip));
system_event_ap_staconnected_t
This data type is associated with the SYSTEM_EVENT_AP_STACONNECTED event.
- uint8_t mac[6]
- uint8_t aid
system_event_ap_stadisconnected_t
This data type is associated with the SYSTEM_EVENT_AP_STADISCCONNECTED event.
- uint8_t mac[6]
- uint8_t aid
system_event_ap_probe_req_rx_t
This data type is associated with the SYSTEM_EVENT_AP_PROBREQRECVED event.
- int rssi
- uint8_t mac[6]
If we enable the correct logging levels, we can see the events arrive and their content. For example:
D (2168) event: SYSTEM_EVENT_STA_CONNECTED, ssid:RASPI3, ssid_len:6, bssid:00:00:13:80:3d:bd, channel:6, authmode:3
V (2168) event: enter default callback
V (2174) event: exit default callback
and
D (9036) event: SYSTEM_EVENT_STA_GOTIP, ip:192.168.5.62, mask:255.255.255.0, gw:192.168.5.1
V (9036) event: enter default callback
I (9037) event: ip: 192.168.5.62, mask: 255.255.255.0, gw: 192.168.5.1
V (9043) event: exit default callback
Настройки WiFi клиента
ESP32 в режиме WiFi клиента может быть подключена только к одной точке доступа. Парамерты точки доступа к которой мы хотим подключиться задаются в структуре wifi_sta_config_t. wifi_sta_config_t состоит из:
- char ssid[32] - ssid точки доступа к которой хотим подключиться
- char password[64] - пароль к точке доступа
- bool bssid_set
- uint8_t bssid[6]
Пример инициализации структуры wifi_config_t:
wifi_config_t staConfig = {
.sta = {
.ssid="<access point name>",
.password="<password>",
.bssid_set=false
}
};
После инициализации структуры передаем её в ESP32:
esp_wifi_set_config(WIFI_IF_STA, (wifi_config_t *)&staConfig);
Предварительно установив режим WiFi с помощью метода esp_wifi_set_mode():
esp_wifi_set_mode(WIFI_MODE_STA)
или
esp_wifi_set_mode(WIFI_MODE_APSTA)
See also: • esp_wifi_set_mode • esp_wifi_set_config
Запуск модуля WiFi
Поскольку Wi-Fi утверждает, что он должен пройти, может быть задан вопрос: «Когда Wi-Fi готов к использованию?». Если мы предположим, что ESP32 загружается с холода, есть вероятность, что мы хотим сказать, что это клиент или точка доступа, и задать её параметры. Учитывая, что это последовательность шагов, мы фактически не хотим, чтобы ESP32 выполнял эти задачи до тех пор, пока мы не выполнили всю нашу настройку. Например, если мы загружаем ESP32 и запрашиваем его как точку доступа, если он сразу стал точкой доступа, он может еще не знать параметров точки доступа, которая должна быть или, что еще хуже, может временно проявляться как неправильная точка доступа. Таким образом, есть окончательная команда, которую мы должны изучить, которая является инструкцией для подсистемы WiFi, чтобы начать работать. Это команда esp_wifi_start (). Все команды которые мы делаем до неё, это настройка среды. Только при вызове esp_wifi_start () подсистема WiFi начинает выполнять какую-либо реальную работу от нашего имени. Если наш режим - это точка доступа, вызов этой функции включает точку доступа. Если наш режим является режимом клиента, начинается подключение к точке доступа. Существует соответствующая команда, называемая esp_wifi_stop (), которая останавливает подсистему WiFi.
Подключение к точке доступа в режиме клиента
После передачи параметров подключения к WiFi в режиме клиента, которая включает SSID и пароль, мы готовы выполнить подключение к точке доступа. Функция esp_wifi_connect() установит соединение. Процедура установки соединения происходит не мнгновенно. Спустя некоторое время мы фактически подключимся - произойдет два события. Первое - SYSTEM_EVENT_STA_CONNECTED, указывающий, что у нас есть подключение к точке доступа. Второе событие - SYSTEM_EVENT_STA_GOT_IP, которое Указывает, что DHCP-сервером был назначен IP-адрес. Только после этих событий мы можем передавать / принимать данные. Если мы используем статический IP-адреса для нашего устройства, то мы увидим только связанное событие. Если мы отключимся от точки доступа, мы увидим событие SYSTEM_EVENT_STA_DISCONNECTED. Для отключения от ранее подключенной точки доступа, нужно вызвать esp_wifi_disconnect().
Существует еще один вариант подключения к точкам доступа - автоматическое подключение. Существует булев флаг, который хранится во флеше, который указывает, следует ли ESP32 пытаться автоматически подключиться к последней используемой точке доступа. Если установлено значение true, то после запуска устройства и без кодирования любых вызовов API, ESP32 попытается подключиться к последней используемой точке доступа. Этот вариант я предпочитаю не использовать, так как хочу сам контролировать работу устройства. Мы можем включить или отключить функцию автоматического подключения, выполнив вызов esp_wifi_set_auto_connect (). Ниже приведен полный пример, иллюстрирующий все шаги, необходимые для подключения к точке доступа с информированнием, когда мы готовы к работе:
#include "freertos/FreeRTOS.h"
#include "esp_wifi.h"
#include "esp_system.h"
#include "esp_event.h"
#include "esp_event_loop.h"
#include "nvs_flash.h"
#include "tcpip_adapter.h"
esp_err_t event_handler(void *ctx, system_event_t *event)
{
if (event->event_id == SYSTEM_EVENT_STA_GOT_IP) {
printf("Our IP address is " IPSTR "\n",
IP2STR(&event->event_info.got_ip.ip_info.ip));
printf("We have now connected to a station and can do things...\n")
}
return ESP_OK;
}
int app_main(void)
{
nvs_flash_init();
tcpip_adapter_init();
ESP_ERROR_CHECK( esp_event_loop_init(event_handler, NULL) );
wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
ESP_ERROR_CHECK(esp_wifi_init(&cfg) );
ESP_ERROR_CHECK( esp_wifi_set_storage(WIFI_STORAGE_RAM) );
ESP_ERROR_CHECK( esp_wifi_set_mode(WIFI_MODE_STA));
wifi_config_t sta_config = {
.sta = {
.ssid = "RASPI3",
.password = "password",
.bssid_set = 0
}
};
ESP_ERROR_CHECK(esp_wifi_set_config(WIFI_IF_STA, &sta_config));
ESP_ERROR_CHECK(esp_wifi_start());
ESP_ERROR_CHECK(esp_wifi_connect());
return 0;
}
Когда мы подключаемся к точке доступа, наше устройство является клиентом. Подключение к точке доступа автоматически не означает, что теперь у нас есть IP-адрес. Мы все еще должны запросить выделенный IP-адрес с сервера DHCP. Это может занять несколько секунд. В некоторых случаях мы можем запрашиватьопределенный IP-адрес адрес. Это приводит к значительно более быстрому времени соединения. Если мы укажем IP адрес, то необходмо также указать информацию о DNS, если нам нужно подключиться к DNS-серверам. Пример, который выделяет нам определенный IP-адрес:
#include <lwip/sockets.h>
// The IP address that we want our device to have.
#define DEVICE_IP "192.168.1.99"
// The Gateway address where we wish to send packets.
// This will commonly be our access point.
#define DEVICE_GW "192.168.1.1"
// The netmask specification.
#define DEVICE_NETMASK "255.255.255.0"
// The identity of the access point to which we wish to connect.
#define AP_TARGET_SSID "RASPI3"
// The password we need to supply to the access point for authorization.
#define AP_TARGET_PASSWORD "password"
esp_err_t wifiEventHandler(void *ctx, system_event_t *event)
{
return ESP_OK;
}
// Пример кода здесь ...
nvs_flash_init();
tcpip_adapter_init();
tcpip_adapter_dhcpc_stop(TCPIP_ADAPTER_IF_STA); // Don't run a DHCP client
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_set_ip_info(TCPIP_ADAPTER_IF_STA, &ipInfo);
ESP_ERROR_CHECK(esp_event_loop_init(wifiEventHandler, NULL));
wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
ESP_ERROR_CHECK(esp_wifi_init(&cfg) );
ESP_ERROR_CHECK(esp_wifi_set_storage(WIFI_STORAGE_RAM));
ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));
wifi_config_t sta_config = {
.sta = {
.ssid = AP_TARGET_SSID,
.password = AP_TARGET_PASSWORD,
.bssid_set = 0
}
};
ESP_ERROR_CHECK(esp_wifi_set_config(WIFI_IF_STA, &sta_config));
ESP_ERROR_CHECK(esp_wifi_start());
ESP_ERROR_CHECK(esp_wifi_connect());
See also: • Handling WiFi events • esp_wifi_connect • esp_wifi_disconnect
Запуск в режиме точки доступа
До сих пор мы рассматривали ESP32 как клиента WiFi для существующей точки доступа, но он также имеет возможность быть точкой доступа для других WiFi-устройств(клиентов), включая другие ESP32. Чтобы быть точкой доступа, нам нужно определить SSID, который позволяет другим устройствам увидеть нашу сеть. Этот SSID может быть помечен как скрытый, если мы не хотим чтобы его можно найти при сканировании. Кроме того, мы также должны указать режим аутентификации который будет использоваться, когда клиент захочет соединиться с нами. Первой этапом для начала работы ESP32 в режиме точки доступа является установка соответствующего режима командой esp_wifi_set_mode(). Для этого необходио передать в качестве параметра код режима точки доступа или совмещенного режима точка доступа и клиента. Это будет либо:
esp_wifi_set_mode (WIFI_MODE_AP);
или
esp_wifi_set_mode (WIFI_MODE_APSTA);
Затем нам нужно предоставить информацию о конфигурации. Мы делаем это, заполняя экземпляр wifi_ap_config_t. wifi_ap_config_t содержит:
- ssid – The WiFi ssid name upon which we will listen for connecting stations.
- ssid_len – The length in bytes of the ssid if not NULL terminated.
- password – The password used for station authentication.
- channel – The channel we will use for networking.
- authmode – How we wish stations to authenticate (if at all). The choices are
- open
- wep
- wpa
- wpa2
- wpa_wpa2
- ssid_hidden – Should we broadcast our ssid.
- max_connection – The number of concurrent stations. The default and maximum
is 4.
- beacon_interval – Unknown. 100.
Пример структуры инициализации:
wifi_config_t apConfig = {
.ap = {
.ssid="<access point name>",
.ssid_len=0,
.password="<password>",
.channel=0,
.authmode=WIFI_AUTH_OPEN,
.ssid_hidden=0,
.max_connection=4,
.beacon_interval=100
}
};
With the structure populated, we call esp_wifi_set_config() … for example: esp_wifi_set_config(WIFI_IF_AP, &apConfig); Finally, we call esp_wifi_start(). Here is a snippet of code that can be used to setup and ESP32 as an access point: When we become an access point, an ESP32 WiFi event is produced of type SYSTEM_EVENT_AP_START. Note that there is no payload data associated with this event. Once the ESP32 starts listening for station connects by being an access point, we are going to want to validate that this works. You can use any device or system to scan and connect. Personally, I use a Raspberry PI 3 for testing as it provides a nice Linux environment and has a WiFi adapter build in. You can also choose to plug in a separate WiFi dongle into one of the extra USB ports. One of the first tools we want to run is called "iwlist" which will perform a scan for us: $ sudo iwlist wlan1 scan In the results, we can look for our ESP32 … for example: Cell 02 - Address: 18:FE:34:6A:94:EF ESSID:"ESP32" Protocol:IEEE 802.11bgn Mode:Master Frequency:2.412 GHz (Channel 1) Encryption key:off Bit Rates:150 Mb/s Quality=100/100 Signal level=100/100 One of the other tools available on that environment is called "wpa_cli" which provides a wealth of options for testing WiFi. The recipe I use is to connect to an access point from the command line is: $ sudo wpa_cli add_network set_network <num> ssid "<SSID>" set_network <num> key_mgmt NONE enable_network <num> status You may have to run select_network <num> reconnect or reasociate to connect to the target and you can run disconnect to disconnect from the access point. ifname – show current interface interface <name> - select current interface To perform a scan run the command "scan". When complete, run "scan_results" to see the list. When a station connects, the ESP32 will raise the SYSTEM_EVENT_AP_STACONNECTED event. When a station disconnects, we will see the SYSTEM_EVENT_AP_DISCONNECTED event. See also: • man(8) – wpa_cl i When a remote station connects to the ESP32 as an access point, we will see a debug message written to UART1 that may look similar to: station: f0:25:b7:ff:12:c5 join, AID = 1 This contains the MAC address of the new station joining the network. When the station disconnects, we will see a corresponding debug log message that may be: station: f0:25:b7:ff:12:c5 leave, AID = 1 From within the ESP32, we can determine how many stations are currently connected with a call to wifi_softap_get_station_num(). If we wish to find the details of those stations, we can call wifi_softap_get_station_info() which will return a linked list of wifi_sta_list_t. We have to explicitly release the storage allocated by this call with an invocation of wifi_softap_free_station_info(). Here is an example of a snippet of code that lists the details of the connected stations: uint8 stationCount = wifi_softap_get_station_num(); os_printf("stationCount = %d\n", stationCount); wifi_sta_list_t *stationInfo = wifi_softap_get_station_info(); if (stationInfo != NULL) { while (stationInfo != NULL) { os_printf("Station IP: %d.%d.%d.%d\n", IP2STR(&(stationInfo->ip))); stationInfo = STAILQ_NEXT(stationInfo, next); } wifi_softap_free_station_info(); } When an ESP32 acts as an access point, this allows other devices to connect to it and form a WiFi connection. However, it appears that two devices connected to the same ESP32 acting as an access point can not directly communicate between each other. For example, imagine two devices connecting to an ESP32 as an access point. They may be allocated the IP addresses 192.168.4.2 and 192.168.4.3. We might imagine that 192.168.4.2 could ping 192.168.4.3 and visa versa but that is not allowed. It appears that they only direct network connection permitted is between the newly connected stations and the access point (the ESP32) itself. This seems to limit the applicability of the ESP32 as an access point. The primary intent of the ESP32 as an access point is to allow mobile devices (eg. your phone) to connect to the ESP32 and have a conversation with an application that runs upon it. See also: • esp_wifi_set_config • esp_wifi_set_mode
Working with connected stations
When our ESP32 is being an access point, we are saying that we wish to allow stations to connect to it. This brings in the story of managing those stations. Common things we might want to do are: • Determine when a new station connects • Determine when a previously connected station leaves • List the currently connected stations • Disconnect one or more currently connected stations We can register an event handler for detecting new station connects and existing station disconnects. The event handler will receive SYSTEM_EVENT_AP_STACONNECTED when a station connects and SYSTEM_EVENT_AP_STADISCONNECTED what a station leaves. We can get the list of currently connected stations using the esp_wifi_get_station_list() function. This returns a linked list of stations. The storage for this list is allocated for us and we should indicate that we are no longer in need of it by calling esp_wifi_free_station_list() when done. If for some reason the logic in our environment wants to forcibly disconnect a currently connected station, we can use the esp_wifi_kick_station() call. See also: • Handling WiFi events • esp_wifi_free_station_list • esp_wifi_get_station_list • esp_wifi_kick_station
WiFi at boot time
ESP32 может хранить информацию о запуске WiFi во флэш-памяти. Это позволяет выполнять свои функции при запуске без необходимости запрашивать у пользователя какую либо информацию. Эта возможность контролируется функциями esp_wifi_set_auto_connect () и esp_wifi_get_auto_connect().
Значениями параметров, используемых для автоматического подключения, являются значения, сохраненные во флэш-памяти при помощи функции esp_wifi_set_config().
See also: • esp_wifi_set_auto_connect • esp_wifi_get_auto_connect • esp_wifi_set_storage
The DHCP client
When the ESP32 connects to an access point as a station, it also runs a DHCP client to connect to the DHCP server that it assumes is also available at the access point. From there, the station is supplied its IP address, gateway address and netmask. There are times however when we want to supply our own values for this data. We can do this by calling tcpip_adapter_set_ip_info() during setup. The recipe is as follows: tcpip_adapter_init(); tcpip_adapter_dhcpc_stop(); tcpip_adapter_set_ip_info(); esp_wifi_init(); esp_wifi_set_mode(); esp_wifi_set_config(); esp_wifi_start(); esp_wifi_config(); (Note that the parameters are omitted in the above). The setup for calling tcpip_adapter_set_ip_info() can be as follows: tcpip_adapter_ip_info_t ipInfo; IP4_ADDR(&ipInfo.ip, 192,168,1,99); IP4_ADDR(&ipInfo.gw, 192,168,1,1); IP4_ADDR(&ipInfo.netmask, 255,255,255,0); tcpip_adapter_set_ip_info(TCPIP_ADAPTER_IF_STA, &ipInfo); Alternative, using strings we have: tcpip_adapter_ip_info_t ipInfo; inet_pton(AF_INET, "192.168.1.99", &ipInfo.ip); inet_pton(AF_INET, "192.168.1.1", &ipInfo.gw); inet_pton(AF_INET, "255.255.255.0", &ipInfo.netmask); tcpip_adapter_set_ip_info(TCPIP_ADAPTER_IF_STA, &ipInfo); See also: • tcpip_adapter_set_ip_info • tcpip_adapter_dhcpc_start • tcpip_adapter_dhcpc_stop • tcpip_adapter_dhcpc_get_status • tcpip_adapter_dhcpc_option • inet_pton
The DHCP server
When the ESP32 is performing the role of an access point, it is likely that you will want it to also behave as a DHCP server so that connecting stations will be able to be automatically assigned IP addresses and learn their subnet masks and gateways. The DHCP server can be started and stopped within the device using the APIs called wifi_softap_dhcps_start() and wifi_softap_dhcps_stop(). The current status (started or stopped) of the DHCP server can be found with a call to wifi_softap_dhcps_status(). The default range of IP addresses offered by the DHCP server is 192.168.4.1 upwards. The first address becomes assigned to the ESP8266 itself. It is important to realize that this address range is not the same address range as your LAN where you may be working. The ESP8266 has formed its own network address space and even though they may appear with the same sorts of numbers (192.168.x.x) they are isolated and independent networks. If you start an access point on the ESP8266 and connect to it from your phone, don't be surprised when you try and ping it from your Internet connected PC and don't get a response. See also: • Error: Reference source not found
Current IP Address, netmask and gateway
Should we need it, we can query the environment for the current IP address, netmask and gateway. The values of these are commonly set for us by a DHCP server when we connect to an access point. The function called tcpip_adapter_get_ip_info() returns our current value. Since the ESP32 can have two IP interfaces (one for an access point and one for a station), we supply which interface we wish to retrieve. When we connect to an access point and have chosen to use DHCP, when we are allocated an IP address, an event is generated that can be used as an indication that we now have a valid IP address. See also: • Handling WiFi events • Error: Reference source not found • tcpip_adapter_get_ip_info
WiFi Protected Setup – WPS
The ESP8266 supports WiFi Protected Setup in station mode. This means that if the access point supports it, the ESP8266 can connect to the access point without presenting a password. Currently only the "push button mode" of connection is implemented. Using this mechanism, a physical button is pressed on the access point and, for a period of two minutes, any station in range can join the network using the WPS protocols. An example of use would be the access point WPS button being pressed and then the ESP8266 device calling wifi_wps_enable() and then wifi_wps_start(). The ESP8266 would then connect to the network. See also: • wifi_wps_enable • wifi_wps_start • wifi_set_wps_cb • Simple Questions: What is WPS (WiFi Protected Setup) • Wikipedia: WiFi Protected Setup
Алгоритм инициализации WiFi
Представьте, что мы создали проект с использованием ESP32, который хочет подключиться к сети. Чтобы это произошло, мы хотим, чтобы ESP32 подключался к существующей точке доступа. Это работает, потому что ESP32 может быть Wi-Fi-клиентом. Для того, чтобы ESP32 соединился с точкой доступа, он должен знать два важных элемента. Он должен знать, к какой сети присоединиться (SSID), и ему нужно будет знать пароль для подключения к этой сети, поскольку большинство сетей требуют аутентификации. И есть головоломка. Если ESP32 перенесен в физически новую среду, как он «узнает», к какой сети подключиться и какой пароль использовать? Мы должны предположить, что ESP32 не имеет прикрепленного к нему экрана. Если бы это было так, мы могли бы запросить у пользователя информацию. Одним из решений является то, что ESP32 первоначально «будет» точкой доступа. Если бы это была точка доступа, мы могли бы использовать наш телефон для связи с ним, спросить, какие WiFi-сети он видит, предоставить пароль для сети и разрешить ему подключаться.
Пока (не сделано) {
если (мы знаем наш ssid и пароль) {
попытаемся подключиться к точке доступа;
Если (нам удалось установить связь) {
return;
}
}
Сами становятся точкой доступа;
Слушать входящие запросы браузера;
Дождаться ввода пары SSID / password;
}
Нам также необходимо обработать случай, когда мы считаем, что у нас есть SSID и пароль, используемые для подключения к точке доступа, но либо те, которые были изменены, либо мы находимся в другом месте. В этом случае мы также должны вернуться к точке доступа и ждать новых инструкций. Мы можем использовать энергонезависимое хранилище для сохранения нашего SSID и пароля. Возможно, мы захотим сохранить не одну пару SSID / пароль, а, возможно, сохранить упорядоченный список. Таким образом, когда мы учим наше устройство, как подключиться к точке доступа, а затем научим его подключаться к другому, мы можем вернуться к первому. Например, представьте, что вы используете ESP32 дома с одной сетью и тем же ESP32 при работе с другой сетью. Мы также можем сохранить информацию о статическом интерфейсе, если у нас либо нет, либо нет необходимости использовать службы DHCP-сервера при запуске в качестве станции.
См. Также: • Нелетучее хранение