ESP8266 Урок 14. Wi-Fi. Режим STA (Станция)
Ну вот, наконец-то, дошли мы до той темы, к которой стремились и ради чего начинался цикл уроков по контроллерам ESP8266 – это приём и передача данных при помощи возможностей ESP8266 по беспроводной сети Wi-Fi.
Я думаю, что все знают, что это за тип сети и для чего она применяется.
Напомню лишь, что Wi-Fi – это протокол передачи данных, осуществляемой без применения проводов, физического уровня.
Как именно передаются данные по сети и как они подготавливаются, как заворачиваются в протоколы различного уровня, мы также очень хорошо знаем. Кто не помнит, напомню – смотрите уроки 40, 41, 44, 45, 46, 47, 48, 49, 50, 51, 52 по программированию контроллеров AVR, а также аналогичные уроки по контроллерам STM32. В данных уроках мы очень подробно рассмотрели многие протоколы всех уровней модели OSI. Те же самые протоколы будут использоваться и здесь, причём нам особо не придётся их программировать вручную, но знать, как они устроены, для чего нужны, мы обязаны, чтобы избежать ошибок при передаче данных, а также, если они и возникнут, то оперативно их устранить. И рассмотренных нами протоколов нам не потребуется протокол физического уровня Ethernet, его заменит протокол Wi-Fi.
Мы пока подробно не будем изучать протокол Wi-Fi, так как с ним работает наш контроллер аппаратно, но режимы работы мы должны знать. И знакомится с их разновидностями мы будем постепенно.
А пока мы должны знать, что наш контроллер ESP8266 поддерживает три основных режима работы – станция (Station mode или кратко STA), программная точка доступа (SoftAP), а также смешанный – Station + SoftAP.
Самым простым из этих режимов является первый – режим станции.
Режим станции (STA) – это такой режим, в котором контроллер не создает собственную сеть, а подключается к любой существующей сети Wi-Fi, например, к существующей локальной сети или к другому устройству, работающему в режиме точки доступа (AP).
На данном уроке мы настроим режим станции и попробуем подключиться к существующей точке доступа, например к роутеру, который раздаёт Wi-Fi по дому. Роутер от просто точки доступа отличается тем, что трафик, идущий от станций, подключенных к нему, он транслирует во внешнюю сеть и наоборот.
Пока воспользуемся возможностями SDK, то есть не будем лезть глубоко в дебри аппаратной части. Всему своё время.
Схема у нас будет простейшая – отладочная плата, подключенная к USB компьютера
Весь процесс соединения с точкой доступа и вхождение в различные стадии соединения мы будем отслеживать с помощью терминальной программы с помощью UART.
Проект наш выполнен из проекта прошлого урока с именем OS_TIMER и назван WIFI_STA.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Работа оборудования Mikrotik в режиме беспроводной станции (клиента)
Режим беспроводной станции (клиента) используется в Mikrotik гораздо реже, чем режим точки доступа, но часто, когда возникает в этом потребность, администраторы сталкиваются с различного рода затруднениями. Во многом это происходит из-за недостаточного понимания особенностей работы беспроводного оборудования в данном режиме. Поэтому в рамках данной статьи мы решили познакомить читателей с теорией и практикой применения роутеров данного производителя в качестве беспроводной станции и ответить на часто задаваемые вопросы.
На самом деле устройства поддерживают не один, а целую группу стандартов для целей обратной совместимости и поэтому можно с уверенностью говорить, что любое купленное устройство с заявленной поддержкой Wi-Fi будет работать с другим таким же устройством в рамках протоколов 802.11.
Но кроме обязательной поддержки стандарта многие производители реализуют собственные проприетарные решения для беспроводных устройств, при этом мы даже не будем касаться таких протоколов как Nstream и NV2, достаточно несоответствующих стандарту возможностей в рамках протокола 802.11. Следует понимать, что такие возможности поддерживаются только оборудованием определенного производителя и будут работать с другими устройствами. Это не хорошо и не плохо, но вы всегда должны четко знать, что именно из предоставляемых оборудованием функций соответствует стандарту 802.11, а что добавлено от производителя.
И, наконец, даже у одного производителя могут быть различные линейки или режимы работы беспроводного оборудования, имеющие ограниченную совместимость даже с собственными решениями. У Mikrotik это программный контроллер беспроводной сети CAPsMAN. И если вы применяете подобные решения, то также требуется принимать во внимание их особенности и ограничения.
Режимы работы беспроводной станции в Mikrotik
Оборудование Mikrotik предоставляет достаточно богатый набор режимов для беспроводной станции, часть из них являются стандартными, другая часть содержит проприетарные расширения, поэтому мы подготовили небольшую таблицу совместимости, позволяющую быстро оценить применимость того или иного режима.
| 802.11 | RouterOS | CAPsMAN | |
|---|---|---|---|
| station | + | + | + |
| station-bridge | + | ||
| station-pseudobridge | + | + | + |
| station-pseudobridge-clone | + | + | + |
| station-wds | + |
Режим station
Самый простой режим работы, при котором беспроводной модуль устройства выполняет роль обычного Wi-Fi адаптера, подключаясь к точке доступа как клиентское устройство. Режим полностью совместим с 802.11, что позволяет подключаться клиентом к оборудованию других производителей, также поддерживается работа с точками доступа управляемыми CAPsMAN.
Но в данном режиме беспроводной интерфейс не является прозрачным для L2 трафика, даже если вы поместите его в мост и объединить сети на канальном уровне таким образом не получится. Для того, чтобы устройства сегмента LAN2 на схеме ниже могли получить доступ к сегменту LAN1 или интернету вам потребуется маршрутизатор (роутер) один из сетевых интерфейсов которого будет работать в режиме беспроводной станции.
Режим station-bridge
Это проприетарный режим прозрачной станции, поддерживаемый только точками доступа Mikrotik и несовместимый с CAPsMAN. Основным ее отличием от простой станции является поддержка режима моста L2 для трафика устройств находящихся за станцией, в данном случае вы можете добавить беспроводной интерфейс в мост и все устройства сегмента LAN2 получат прозрачный доступ на канальном уровне в сегмент LAN1 как-бы находясь с ними в единой сети.
Фактически беспроводной канал используется в режиме моста, но со стандартными настройками точки доступа, которая может продолжать принимать подключения от обычных клиентов. Данный режим обычно используется для объединения собственных сетей, когда иного варианта доступа, нежели беспроводной канал, нет.
Каких-либо особенностей или отличий в настройках беспроводного модуля от режима station нет.
Режим station-pseudobridge
Таким образом прозрачный доступ на канальном уровне будет иметь только одно устройство, чей кадр был получен первым, остальные узлы сети будут иметь ограниченный доступ на уровне служб IPv4.
Производитель советует по возможности избегать этого режима и использовать только тогда, когда иные возможности создания L2 моста недоступны или за станцией находится только одно сетевое устройство. На практике данный режим следует использовать исключительно для прозрачного доступа единственного экземпляра оборудования в беспроводную сеть на оборудовании стороннего производителя или управляемую CAPsMAN при отсутствии иных возможностей подключения.
Режим station-pseudobridge-clone
Еще один вариант псевдопрозрачного моста, но в данном случае станция заменяет MAC-адреса источника на адрес одного из узлов сети, который либо задан в настройках, либо был получен из первого перенаправленного кадра. Со стороны точки доступа это будет выглядеть как будто к ней непосредственно присоединился данный узел. Фактически данный режим дает возможность прозрачного моста для единственного выбранного устройства, а возможность явно задать нужный MAC-адрес исключает элемент случайности.
Для указания MAC-адреса клиента перейдите на закладку Advanced беспроводного интерфейса и заполните поле Station Bridge Clone MAC.
Используя данный режим будьте осторожны, так как у вас появляется два устройства с одинаковым MAC-адресом и при одновременном подключении их к сети вы можете получить самые неожиданные последствия.
Режим station-wds
Это единственный режим, поддержку которого нужно включать со стороны точки доступа. Но в чем его преимущества и какие возможности он дает? Основное отличие данного режима в том, что между точкой доступа и беспроводной станцией создается соединение точка-точка и отдельный WDS-интерфейс для него. Это позволяет точке раздельно направлять данные к WDS-клиентам, а наличие отдельных интерфейсов позволяет использовать фильтрацию трафика, маршрутизацию и т.д. и т.п. При этом соединение остается прозрачным для L2 трафика, но добавляет возможность работы с Bridge Firewall.
Для использования режима WSD его потребуется включить на точке доступа, для этого на закладке WDS беспроводного интерфейса установите параметр WDS Mode в dynamic для динамического создание WDS-интерфейсов, или static если вы будете создавать их вручную. Опция WDS Default Bridge определяет мост, к которому по умолчанию будут подключаться WDS-интерфейсы.
Со стороны станции настройки ничем не отличаются от стандартных. Но теперь при подключении станции на точке доступа будет автоматически создан новый интерфейс и включен в указанный в настройках мост.
Говорить о практическом использовании режима station-wds можно долго, благодаря наличию отдельного сетевого интерфейса для каждого клиента вырисовываются перспективы построения достаточно сложных сетевых конфигураций. Но не забывайте о рациональности, не следует усложнять там, где это не нужно и если вам нужен просто беспроводной L2-мост, то лучше использовать station-bridge.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Wifi station что это
Artwork by Hanzheng Tang
В данной статье я хочу рассмотреть наиболее простые примеры для работы с сетью средствами SDK. При работе с сетью, SDK использует неблокирующее программирование. В связи с этим, программирование сводиться к написанию коллбек-функций, которые будут вызываться из SDK при наступлении того или иного события. Это затрудняет чтение и разбор алгоритма программы, поэтому в статье я всега стараюсь говорить, что за чем следует.
Статья по структуре будет напоминать предыдущую: «ESP8266: подключение, прошивка и работа с AT-командами», за тем исключением, что в этот раз все будет делаться с помощью программирования через ESP8266-NONOS-SDK.
В качестве «транспорта» для работы с TCP/IP я буду использовать штатный интерфейс espconn, который описан в ESP8266 Non-OS SDK API Reference.
Для захвата и анализа трафика между ESP8266 и точкой доступа на OpenWRT, я буду использовать программы tcpdump и Wireshark. Все примеры статьи используют SDK версии 2.1.0.
Посмотреть исходники, сборочные файлы, скачать скомпилированные прошивки, можно с портала GITLAB https://gitlab.com/flank1er/esp8266_sdk_examples
1) Создание базового проекта
Для на начала нужно будет создать базовый проект, который мы будем постепенно развивать. Отталкиваться при этом будем от последнего проекта предыдущей статьи. Итак:
Создаем структуру каталогов:
Переходим в созданную директорию 06_basic_project, и в каталоге inc создаем пустой заголовочный файл «user_config.h«:
После этого копируем файл «espmissingincludes.h«:
В главной директории создаем Makefile следующего содержания:
Осталось добавить «main.c» c исходником простой мигалки:
После компиляции и прошивки, светодиод на плате должен начать мигать с интервалом одну секунду.
Если сравнивать данный пример с примерами из предыдущей статьи, то можно заметить, что код мигалки реализован через таймер. Кроме того, добавлены две новые функции: user_rf_cal_sector_set() и user_rf_pre_init(). Что это за функции? В самом начале документа к ESP8266 Non-OS SDK API Reference можно увидеть следующие строки:
Здесь говорится, что указанные функции должны быть добавлены в один исходник с user_init(). Самостоятельно вызывать их не надо, они вызываются из SDK. Код функций был взят примера ESP8266_NONOS_SDK/examples/IOT_Demo/user/user_main.c.
У функции user_rf_cal_sector_set() имеется описание:
Думаю, не сложно заметить, что код из примера используется в вышеприведенной программе.
Итак, если светодиод на плате NodeMCU благополучно мигает и вопросов по коду больше нет, тогда переходим к установке WiFi соединения.
2) Установка WiFi соединения в режиме клиента
На основе функции wifi_station_get_connect_status() напишем функцию печати через UART статуса wifi-соединения, и добавим ее вызов в blink(). В целом программа будет выглядеть так:
Для наглядности я еще добавил печать IP-адреса в случае если ESP8266 устанавливает соединение с точкой доступа. Для получения IP используется функция wifi_get_ip_info(STATION_IF, &ipConfig):
При этом структура ip_info определена в заголовочном файле ip_addr.h, и имеет следующий вид:
Итак, после компиляции прошивки ESP8266, в терминале последовательного порта можно будет увидеть такую картинку:
Т.е. можно видеть, что esp8266 УЖЕ установила соединение с точкой доступа, без всяких телодвижений с нашей стороны.
КАК ТАКОЕ ВОЗМОЖНО?!
Здесь можно только предполагать. В прошлой статье я упоминал о подводном камне, когда прошивка esp_open_sdk начинает работать только после того как ESP8266 предварительно прошить прошивкой с интерпретатором АТ-команд. Теперь вспоминаем. Когда мы через этот интерпретатор устанавливаем соединение с точкой доступа, то после перезагрузки ESP8266, это соединение устанавливается уже автоматически. Т.е. на флешке УЖЕ хранится режим работы WIFI-модуля, SSID точки отступа и парольная фраза. Имея эту информацию, sdk автоматически при старте устанавливает соединение, вне зависимости от того, записан ли AT-интерпретатор или программа esp-open-sdk. Само-собой, в дальнейшем мы будем самостоятельно через функции SDK устанавливать соединение с нужной точкой доступа, но про этот нюанс забывать не стоит.
Печать статуса соединения с определенным интервалом не совсем корректный подход к работе c SDK. Более корректно будет использование wifi_set_event_handler_cb() для установки обработчика изменения статуса соединения:
wifi_set_event_handler_cb
Назначение функции Установка обработчика событий WiFi Прототип void wifi_set_event_handler_cb(wifi_event_handler_cb_t cb) Параметры wifi_event_handler_cb_t cb : callback-функция Возвращаемое значение Отсутствует. Пример ESP8266 Non-OS SDK API Reference
Смысл обработчика событий WiFi состоит в том, что при любом изменении статуса WiFi-соединения вызывается данный обработчик. Именно в нём и следует размещать печать статуса соединения.
Теперь приводим программу к следующему виду:
В случае успешной компиляции и прошивки, в терминале мы должны получть следующую картинку:
Здесь у нас получается уже небольшой лог, по которому можно видеть, что после загрузки WiFi модуль сначала переходит в режим клиента, потом он по о всей видимости сканирует доступные точки доступа, затем устанавливает соединение с своей точкой доступа, и через DHCP получает IP адрес.
Теперь, когда мы представляем в каком состоянии изначально находится WiFi модуль, мы можем осуществить переподключение к нужной нам точке доступа. Для это нам понадобятся следующие функции SDK:
Функция подключения к точке доступа:
wifi_station_connect
Назначение функции Подключение WiFi модуля находящегося в режиме клиента (station) к точке доступа (AP). Прототип void wifi_station_clear_username (void) Параметры Отсутствуют. Возвращаемое значение True: успешное выполнение;
False: ошибка при выполнении.Примечание Если ESP8266 уже подключен к роутеру, то перед вызовом wifi_station_connect нужно будет вызвать функцию wifi_station_disconnect().
Вызов данной функции должен происходить после инициализации, а ESP8266 должен находится в режиме клиента (station).ESP8266 Non-OS SDK API Reference
Функция отключения от точки доступа:
wifi_station_disconnect
Назначение функции Отключение WiFi модуля находящегося в режиме клиента (station) от точки доступа (AP). Прототип void wifi_station_clear_username (void) Параметры Отсутствуют. Возвращаемое значение True: успешное выполнение;
False: ошибка при выполнении.Примечание Не вызывайте данную функцию в user_init(). Ее вызов должен происходить после инициализации, а ESP8266 должен находится в режиме клиента (station). ESP8266 Non-OS SDK API Reference
Функция установки режима работы WiFi модуля:
Заданная конфигурация будет сохранена в системных параметрах флеш-памяти ESP8266.
ESP8266 Non-OS SDK API Reference
Функция задания массива настроек WiFi модуля в режиме клиента (station):
wifi_station_set_config
Назначение функции Устанавливает конфигурацию WiFi модуля для работы в режиме клиента, и сохраняет ее во флеш-памяти. Прототип bool wifi_station_set_config (struct station_config *config) Параметры struct station_config *config : указатель на структуру с конфигурацией WiFi модуля в режиме клиента. Возвращаемое значение True: успешное выполнение;
False: ошибка при выполнении.Пример Примечание Данная функция может быть вызвана только если WiFi модуль ESP8266 находится в режиме клиента (station). Как правило, station_config.bssid_set необходимо сбрасывать в 0, чтобы избежать проверки MAC адреса (BSSID) точки доступа. Иначе, подключение к точке доступа произойдет только при совпадении SSID и MAC адреса (BSSID).
Установленная конфигурация WiFi модуля будет сохранена во флеш-памяти ESP8266.
ESP8266 Non-OS SDK API Reference
где структура station_config определена в заголовочном файле user_interface.h и имеет следующий вид:
Процедура подключения к точке доступа в режиме клиента состоит из двух шагов: а) переход в режим клиента; б) установка структуры station_config. Структуру можно либо создать во время инициализации, заполнив нужные поля своими значениями, либо получить текущую структуру с помощью функции wifi_station_get_config() и изменив нужные поля, передать её обратно в ESP8266.
С учетом всего вышесказанного, окончательный вариант user_init() для установки соединения с точной доступа, примет следующий вид:
При этом, в заголовочном файле user_config.h должны находится данные для подключения к точке доступа:
3) Работа с TCP соединением используя espconn
После того, как мы установили соединение с точкой доступа, следует разобраться с установкой TCP-соединения, чтобы иметь возможность передавать и принимать данные с сервера.
Для начала, мне хотелось бы разобрать пример подключения по HTTP протоколу с использованием GET запроса. Попробуем просто скачать HTML-станицу со своего сервера, т.е. реализуем программными средствами пример из ноябрьской статьи: «13) Получение web-страницы или текстового файла от сервера на OpenWRT».
Итак, работа с TCP соединением через espconn производится через коллбэк-функции. Т.е. вы пришите свои функции на открытие TCP соединения, закрытие TCP соединения, на прием и передачу данных и т.е. Совсем не обязательно писать все коллбэк-функции, пишите только те, что вам необходимо. Очевидно, что перед созданием TCP соединения необходимо будет задать адрес и порт. Т.о., отталкиваясь от предыдущего примера, делаем следующее:
Добавляем заголовочные файлы с объявлением функций espconn и функций для работы с памятью:
Добавляем ip-адрес и порт целевого сервера:
Добавляем буфер, в котором будут храниться передаваемые и получаемые данные:
Если ваши данные небольшие по размеру, то буфер можно задать статично, как показано выше. Иначе имеет смысл использовать динамическое выделение памяти под массив.
Добавляем объявление коллбэк-функций:
И теперь собственно пишем функцию установки TCP-соединения:
Принцип работы походит на установку WiFi-соединения. Сначала создается структура типа espconn, далее заполняются ее поля, регестрируются коллбэк функции, после чего структура «скармливается» функции espconn_connect в качестве значения.
Вызов функции send_data() добавим в коллбэк-функцию void wifi_handle_event_cb(System_Event_t *evt)
Т.е. функция send_data() будет вызвана сразу после подключения к точке доступа WiFi.
Коллбэк функции: tcp_connected(void *arg), data_received_cb(void *arg, char *pdata, unsigned short len) и tcp_disconnected_cb(void *arg) выглядят следующим образом.
Функция tcp_connected(void *arg):
Коллбэк-функция data_received_cb() обрабатывает ответ уделенного сервера:
Через указатель на массив *pdata передается сам ответ, который функция os_printf( «%s: %s\n», __FUNCTION__, pdata) передает на последовательный порт. После этого, с помощью espconn_disconnect(conn) TCP-соединение разрывается.
В момент разрыва TCP-соединения вызывается коллбэк-функция tcp_disconnected_cb:
Она разрывает соединение с точкой доступа с помощью вызова функции SDK: wifi_station_disconnect().
Таким образом, алгоритм работы программы выглядит так:
Полный текст программы можно просмотреть под спойлером:
После компиляции и прошивки esp8266, лог работы программы будет выглядеть так:
Здесь хочу обратить внимание на то, что в качестве ответа веб-сервера мы получаем лишь 200-ий код ответа.
Теперь напомню, как выглядела TCP-сессия с помощью AT-команд:
Здесь ответ приходил двумя «чанками», после чего сервер САМОСТОЯТЕЛЬНО закрывал TCP-соединение. Т.е. если мы закомментируем строку с «espconn_disconnect(conn);», то получим полный ответ сервера:
Для контроля, в Wireshark можно посмотреть лог трафика генерируемого esp8266 в течении сессии:
Каких-либо ошибок не наблюдается. Отмечу, что в Wireshark трафик отфильтрован по порту веб-сервера. В данном случае это 8010.
4) Использование режима энергосбережения «deep sleep»
Теперь попробуем адаптировать алгоритм нашей программы ближе к реальной задаче. Для этого, ее работа должна выглядеть следующем образом: 1) esp8266 стартует, соединяется с точкой доступа, передает или принимает какие-то данные, после чего отключается от точки доступа. 2) после выполнения первой задачи, пусть esp8266 уходит в спящий режим, по выходу их которого он будет «дергать» RESET, в результате чего esp8266 перезагрузится и все начнётся заново.
Для осуществления этой задачи нам придется выкинуть из программы мигалку на светодиоде. Т.к. большую часть времени esp8266 будет находиться в режиме пониженного энергопотребления, в котором мигать чем либо уже не получиться. Кроме того, светодиод мигалки находиться на GPIO16 который принадлежит RTC, и он нам понадобится для пробуждения из спящего режима.
Работа eps8266 в режиме энергосбережении описана в следующем руководстве: ESP8266 Low Power Solutions
Согласно пункту 4.5 этого руководства, чтобы перевести esp8266 в режим пониженного энергосбережения deep_sleep, после завершения соединения с точкой доступа, достаточно будет добавить в CASE функции wifi_handle_event_cb(System_Event_t *evt) две сточки кода:
Полный текст обновленной программы можно посмотреть под спойлером:
Не забывайте, что из Makefile следует убрать сборку модуля gpio16.o. Кроме того, вывод D0/GPIO16 нужно будет соединить с RESET, чтобы esp8266 смог «проснуться»:
Есть еще один неприятный подводный камень при использовании режима пониженного энергопотребления deep_sleep. Проблема проявлется в невозможности прошить плату esp8266 nodemcu с помощью автоматической загрузки прошивки. Выглядит это как-то так:
В этом случае, чтобы прошить esp8266 нужно: а) отключить esp8266 от питания; б) зажать кнопку BOOT; в) подключить питание к esp8266 (кнопка BOOT при этом должна быть зажата); г) запустить прошивку esp8266, кнопку BOOT при этом можно освободить; д) после завершения прошивки, следует переподключить питание esp8266 (кнопка BOOT при этом должна быть свободной).
5) Реализация команды ping
Еще одной полезной возможностью мне показалась команда ping. Она имеется в AT командах, здесь же я хочу показать как она реализуется возможностями SDK.
Структуры и функции SDK для реализации команды ping объявлены в заголовочном файле ping.h, в папке с заголовочными файлами SDK. Описания в документации нет, т.е. они не документированы.
Думаю, что если вы дочитали до этого места, то вопросов здесь возникнуть не должно. Я без изменений скопировал этот код в свою программу, заменил вызов функции send_data() на user_test_ping() и получил такой результат:
Здесь в качестве ip я указал ip точки доступа, т.е. 192.168.1.10.
Лог сетевого трафика в этом с случае выглядит так:
Однако данный вариант реализации команды ping требует указания IP целевого хоста, в то время как часто бывает нужно пропинговать хост по доменному имени. Функция SDK которая возвращает IP доменного имени назвается espconn_gethostbyname(). Наглядное использование этой функции имеется в приведенном выше примере.
Действуя по аналогии, поместим вызов этой функции в кейс функции wifi_handle_event_cb(System_Event_t *evt), который вызывается при установлении соединения с точкой доступа
Функция dns_done() в таком случае примет такой вид:
Функция user_test_ping() незначительно меняется, она теперь принимает в качестве параметра IP-адрес:
Полный текст программы можно посмотреть под спойлером.
При работе программы, в терминале будет наблюдаться такой лог:
В Wireshark можно будет наблюдать два DNS пакета: запрос к DNS серверу, и последующий ответ от него:
6) Получение даты и времени из сети по протоколу SNTP
На практике это будет выглядеть так. В кейс функции wifi_handle_event_cb(System_Event_t *evt) отвечающий за установку соединения с точкой доступа помещаем код из примера в части 3.13 руководства ESP8266 Non-OS SDK API Reference:
Здесь я немного изменил код в сравнении с оригиналом, т.к. функции ipaddr_aton() я не нашел, поэтому пришлось импровизировать. Указано IP моего домашнего сервера с OpenWRT, на котором установлен SNTP сервер. Также добавлена функция с установкой часового пояса. В данном случае устанавливается самарский часовой пояс. По умолчанию время синхронизируется по пекинскому часовому поясу, а не по Гринвичу, как следовало бы ожидать.
В области глобальный переменных нужно не забыть объявить таймер:
Коллбек-функция копируется практически без изменений:
Здесь, в случае успешного получения текущего времени отключается таймер, и управление передается функции send_data().
Полный текст программы можно посмотреть под спойлером:
Лог работы программы:
Если посмотреть на лог трафика, то можно увидеть DNS запросы на резовлинг домена 0.ru.pool.ntp.org с последующим обращением к ним по NTP протоколу:
В теле ответа NTP сервера можно увидеть дату и время которую мы в итоге получили.
На этом пока все. Я не стал рассматривать в статье UDP запросы, работу в режиме сервера, LwIP, web-сокеты, внутренний RTC и другие интересные вещи в надежде найти для этого полезные практические примеры, а не ограничиваться голой теорией. Надеюсь, что следующая статья будет более интересной с практической точки зрения.