Прошивка для esp32 nodemcu lua на базе последней idf4.4

И опять баг IDF5 или тараканы в моей голове:



Через некоторое время:




Код:

Код (Lua):

dat = {}
SSID = 'AP'
PASSWD = 'passwd'

time.settimezone('EST-3')
-- time.initntp()
time.initntp("pool.ntp.org")

wifi.start()
wifi.mode(wifi.STATION, true)

wifi.sta.on("disconnected", function(ev, info)
    print("Lost WiFi!")
    dat.wifi = nil
    dat.ip = nil
    wifi.sta.connect()
end)
wifi.sta.on("got_ip", function(ev, info)
    dat.wifi = true
    dat.ip = info.ip
    print("NodeMCU Got IP:", info.ip)
end)

local scfg = {}
scfg.auto = true
scfg.save = true
scfg.ssid = SSID
scfg.pwd = PASSWD
SSID, PASSWD = nil, nil

wifi.sta.config(scfg, true)
wifi.sta.connect()


asktime = function ()
    nowt, nowts = time.get()
    print(string.format('%d %d', nowt, nowts))
    localTime = time.getlocal()
    print(string.format("%04d-%02d-%02d %02d:%02d:%02d DST:%d", localTime["year"], localTime["mon"], localTime["day"], localTime["hour"], localTime["min"], localTime["sec"], localTime["dst"]))
end

tmr.create():alarm(2000, 1, asktime)
 

... и это не последний прикол.

А время все таки меняется

 

Просто слишком много секунд прошло с начала UNIX эпохи...

Такое же поведение было и IDF4, то есть оно общее для обеих прошивок.

В программном обеспечении nodemcu при переходе от Lua 5.1 к Lua 5.3 с целью сокращения объёма занимаемой памяти и повышению быстродействия в Lua 5.3 были изменены разрядности по умолчанию для чисел integer и floating point.

Теперь в menuconfig можно выбрать опции для сборки прошивки:

Код (C++):

Top → Component config → Lua configuration
Lua version (Lua 5.3)  --->
[ ] Use 64bit integers
[ ] Use double precision floating point
 

Если собрать прошивку с 5.1, то значения секунд будут отображаться правильно, так как 5.1 сразу 64-fp, и разрядность не теряется. Если собрать прошивку по умолчанию 5.3, то мы видим потерю значений. При сборке прошивки 5.3 с установленным флажком Use double precision floating point всё становится снова хорошо.

tv_sec: 1690219965 <- это отладочная печать из кода в С
tv_usec: 946641
1690219965 946641 <- это видим принятое в Lua
2023-07-24 20:32:45 DST:0

Формально это баг. Однако, не думаю, что стоит на нём зацикливаться. Эту разницу в прошивках надо учитывать при написании программы пользователем.
По крайней мере, система могла бы выдавать предупреждение на этапе загрузки, как это делается для устаревающих драйверов, о потере разрядности при использовании прошивки [5.3-int32-singlefp].

Для получения текущего времени в прошивке singlefp можно пользоваться time.getlocal(). Если позарез нужны эти цифры с голыми секундами и микросекундами, то собирать прошивку с double precision fp. Или с Lua 5.1.
Возможно, имеет смысл изначально собирать прошивку с double precision fp чтобы избежать подобных ситуаций.

 

Работа с этими секундами очень удобна. В частности, когда требуется периодически повторять много вызовов через разные и продолжительные периоды времени.

Позже выложу пример.

И как обычно, огромное спасибо за разъяснения.

 

Согласен.
Подкорректировал своё предыдущее сообщение.

И, чтоб два раза не вставать, поправил файл .../nodeMCU-firmware/components/modules/time.c
Теперь секунды возвращаются корректно для прошивок:

Lua 5.3.5 [5.3-int32-singlefp] on IDF v5.0.2
Lua 5.3.5 [5.3-int32-doublefp] on IDF v5.0.2
Lua 5.3.5 [5.3-int64-singlefp] on IDF v5.0.2
Lua 5.3.5 [5.3-int64-doublefp] on IDF v5.0.2

 

А правильно ли я делаю?

Код (Bash):

cd dev-esp32-idf5-testing/
git pull origin dev-esp32-idf5-testing

Если я изменю файл, мне надо будет вызвать

Код (Bash):

git stash

перед вызовом выше, а потом вернуть этот файл?

 

Да, всё верно.

 

Мне кажется, с этим модулем еще не все проблемы с IDF5.

Если запустить тот код, что я привел, сразу после подачи питания, время синхронизируется не всегда. Если перегрузить через node.reset() и вновь запустить - время появляется правильное.
Но пока до конца не разобрался.

В проекте на IDF4 все работало - видимо настройки по умолчанию были другие.

А вот что точно - idf5 работает "шустрее". Цифры по MAX7219 двигает субъективно раза в три быстрее чем idf4 на том же коде.

 

Для более устойчивого получения времени я вызываю time.initntp() только после получения IP.
В конце концов, можно для проверки вообще завернуть вызов time.getlocal() в net.dns.resolve.

Код (C++):

net.dns.resolve("ntp1.ntp-servers.net", function(ip)
  if ip then
    print('sec = ', (time.get()))
  end
end)
 

Ошибка с потерей разрядности никак не связана с версиями IDF. Она должна проявится даже на esp8266 с собранной прошивкой с Lua 5.3-single fp. Это особенность перехода на Lua 5.3.

 

Ясно. Это не баг, это фича. Раньше "If any sync operation fails (maybe the device is disconnected from the internet), then all the names will be looked up again."

Конечно, ничто не мешает затолкать time.initntp() в callback wifi.sta.on("got_ip"...) а time.ntpstop() в callback
wifi.sta.on("disconnected"...). Ничто, кроме старых привычек да веры в то, что "все что ни делается - все к лучшему". Вишь как, даже Lua 5.3 туда же....

Чет от многого привычного приходится отказываться ради этого светлого Lua 5.3.

Не уловил смысл: time.getlocal() не получает время с сервера, а читает внутренние данные. Наличие доступа к серверу времени не значит, что время синхронизировано. Синхронизация лучше проверяется сравнением текущего года с 1970.

Ну да если нет доступа к серверу, то и время может быть ошибочным. А может и нет. При перезагрузке ESP32 внутреннее время сохраняется, а доступа к серверу времени может не быть. Особенно в наше непростое время.

 

Изменения в стеке TCP/IP внутри espressif IDF, частью которого является модуль sntp, происходят независимо от ПО nodemcu. Там вносятся свои новые приколы. А софт lua nodemcu и не менялся с момента выпуска версии для esp32.

Можно просто поставить галочку [ ] Use double precision floating point при сборке прошивки, и всё будет как раньше.

Да, конечно, time.get().
Идея была во внесении дополнительной задержки после time.init() за счёт асинхронной операции перед фактическим запросом времени.

 

И это не обращается к серверу. Здесь можно запускать time.initntp() после проверки DNS. Но делать так я бы не стал, поскольку нужно организовывать проверку по кругу, если с первого раза DNS не находится. Все это муторно.

Проще после получения IP запустить синхронизацию и надеяться на лучшее. Мой опыт показывает что сервера времени в целом доступны всегда. Проблема бывает именно на стороне железки.

 

Если Вы не против встряну в Ваш диалог по поводу синхронизации времени на ESP32.
У меня сейчас прошивка от Игоря с IDF4.4, а также в наличии роутер от компании keenetic c прошивкой 3.9.X.
Так вот с данной прошивкой, в роутере можно включить sntp-сервер (который синхронизируется с серверами keenetic) и текущее время получать по адресу 192.168.1.1, по мне так очень удобно при наличии конечно такого роутера.

 

... а ведь и верно. И у меня такое есть.

 

У меня так и сделано. Только прошивка Open WRT.

 

Сергей! Вы выкладывали скомпилированные luacross файлы для прошивок.
В случае выбора опций в Lua 5.3 luacross не работает корректно с lfs. Не дополните?

 

Сгенерировал, но не проверял ни один.

 

Да, я как-то очень странно прочитал документацию на модуль time

PS. Если кто-нибудь проверит работоспособность добавленных luac.cross.exe с разными прошивками, то отпишитесь. Я тогда выложу в репозиторий.

 

Обязательно в ближайшее время.

 

Все работает. Добавляю прошивки idf5 и в каждом архиве тот luacross, что работает с ней.
@serg3295 , огромное спасибо за работу и разъяснения.

 

Информация для тех, кто собирает прошивку для ESP32 из исходников репозитория nodemcu-firmware.

Разработчики nodemcu-firmware перенесли все изменения из рабочей ветки dev-esp32-idf5-testing в ветку dev-esp32.
В этой ветке произведено обновление до текущей стабильной версии ESP-IDF v5.1.2.
Все исправления ошибок, которые обсуждались в данной теме (модули time, mqtt), были учтены.

То есть, для сборки прошивки ESP32, пользоваться теперь нужно (снова ) веткой dev-esp32.