WiFi лампа-будильник. Обсуждение прошивки от vvip-68

[vvip]

Выложил версию. В ней изменен формат хранения резервной копии настроек.

Ранее все тексты бегущей строки (резервная копия) сохранялась каждая строка в отдельном файле.
LittleFS имеет размер кластера то ли 16 КБайт то ли 32 КБайт - не помню. Не суть. Суть в том, что даже самый маленький текст на 20 букв в отдельном файле занимал целый кластер. Сохранили 36 строк - нет 500+K "дискового пространства". И то, если места хватило - а то могло и не хватить и тогда резервная копия не создастся.

Новый формат - все данные - EEPROM +тексты хранятся в одном файле,размер которого в 99.9% случаев помещается в один кластер.
К сожалению, (?) новый формат несовместим с предыдущим. Зато появилась возможность скачивать сохраненные настройки на комп/на телефон, потом загружать скачанный файл и восстанавливать настройки. То есть для устройств без SD-карты - реальная возможность не потерять настройки и тексты бегущей строки при обновлении.

На момент перехода, чтобы не потерять настройки и тексты - действовать нужно в следующем порядке:
1. Загружаем новую прошивку. Файловую систему НЕ обновляем.
2. После обновления прошивки и перезапуска контроллера идем в Web-интерфейс, на страничку "Настройки" -> "Прочие" и нажимаем кнопку "Сохранить настройки в файловую систему".


3. Предполагаем, что у вас версия EEPROM (константа EEPROM_OK в первых строках файла a_def_soft.h) - 0x0E3 и
IP адрес устройства - 192.168.0.100. В реальности - подставьте свои значения.
Итак, в браузере пишем в адресной строке - http://192.168.0.100/assets/eeprom_0xE3.hex
Оно должно загрузить файл, предложить сохранить его на диске. Сохраняем.
4. Обновляем файловую систему - обновится Web-интерфейс.
5. После перезапуска контроллера идем в веб-браузер, открываем Web-интерфейс. Нажимаем Ctrl-F5 и/или Ctrl-Shift-R - это обновит соодержимое странице в окне браузера, загрузив ее из контроллера, а не из кэша браузера
6. Идем в Web-интерфейс, на страничку "Настройки" -> "Прочие" и нажимаем кнопку "Загрузить настройки из файла". Выбираем ранее сохраненный файл настроек, нажимаем кнопку "Загрузить". Контроллер должен восстановить настройки из загруженного (uploaded) файла и перезапуститься.
7. После перезапуска - настройки восстановлены, прошивка и веб-интерфейс обновлены.



Слева направо:
1. Восстановить сохраненные настройки из файла, сохраненного до этого в файловую систему микроконтроллера
2. Сохранить текущие настройки в файловую систему микроконтроллера
3. Загрузить на устройства файл сохраненных настроек ранее скачанный из устройства на компьютер / телефон. Сразу после завершения загрузки настройки будут восстановлены из загруженного файла.
4. Скачать сохраненные настройки из устройства в файл на компьютере / телефоне.

 

[vvip]

@VadZher, нет, карта размещения настроек поменялась с версии 1.14a на 1.14c - и вот, см. пост выше - даже формат поменялся.

Та процедура что выше - позволит при обновлении не потерять тексты строк, но настройки эффектов все равно придется делать по-новой.
В версии 1.14а настройки эффектов хранились в EEPROM с адреса 400, в версии 1.14с - "уехали" на адреса с 800

 

[VadZher]

@vvip,
Доброе утро! Перешёл на прошивку 1.14с, версия для ESP32. Обнаружил, что не сохраняются текстовые строки, набранные вручную. При выборе пустой ячейки, наборе строки вручную и нажатии на кнопку «сохранить» - строка просто исчезает. Если выбрать пустую ячейку, нажать на кнопку «очистить», ввести строку вручную и нажать на кнопку сохранить - строка сохранится в памяти, будет отображаться на матрице, но не будет видна для редактирования.
Посмотрите, пожалуйста, в чём может быть проблема.
У меня версия с SD картой, эффекты с неё доступны. Прошивался с параметром initialize_texts 0.

 

[vvip]

@VadZher, затрудняюсь сказать. У меня подобной проблемы не наблюдается. Все строки и редактируются и сохраняются. Я не могу проанализировать и исправить ошибку, если она существует пока не смогу повторить / воспроизвести ее.

UPD: Залил чистую прошивку без предварительной инициализации строк.
Поведение немного странное, но не такое как вы описываете.
У меня первое заполнение строки и нажатие на кнопку "Сохранить" - строка пропадает. Но при повторном ввод текста в эту же ячейку - сохраняется и уже никуда не пропадает. Даже после перезагрузки контроллера и - редактируй сколько влезет, все изменения сохраняются.
Этот момент - посмотрю.

 

[AnCore]

@VadZher, тоже заметил. Но всё нормально становится, если снова вписать текст в ячейку, где исчез текст

 

[VadZher]

@vvip,
@AnCore,
Сейчас прошился с параметром initialize_texts 1. Изменения строк с примерами сохраняются. Наверное, описанная мной проблема связана с особенностью хранения пустых строк в памяти.

 

[vvip]

@VadZher, исправил ошибку не сохранения строки с первого раза.
Саму прошивку обновлять не нужно, нужно обновить только файловую систему. Ошибка была на Web-странице.

Но повторю - тот сценарий, что описали вы - у меня не воспроизводится.
У меня строка не сохранялась только в самый первый раз, когда редактировалась пустая ячейка.
Если строку очистить или снова во второй раз ввести текст - сохранялось. В контроллер и было доступно для редактирования даже после перезапуска устройства.

Эту ситуацию я исправил.

 

[VadZher]

@vvip,
Сейчас картина следующая: если изменить существующую строку и сохранить - новая строка отображается в поле редактирования и на матрице. Если нажать на кнопку браузера обновить - в поле редактирования появляется предыдущая строка без внесённых исправлений.

Спасибо за обновление! Сейчас попробую.

 

[vvip]

@VadZher, нет, такого поведения не наблюдаю у себя...

 

[VadZher]

@vvip,
После обновления файловой системы строки сохраняются, доступны для редактирования. Спасибо за помощь!

При нажатии кнопки обновить всё равно возвращается прежняя строка. Видимо, это связано с особенностью обновления браузера Safari на айфон. С ноутбука всё работает отлично.

 

[vvip]

@VadZher, видимо браузер на айфоне игнорирует Web-Headers, говорящие, что не нужно брать данные из кэша браузера, нужно получить новые данные с контроллера.

Айфоны вообще странные и сами в себе. Например, даже загрузка самого файла index.html - они изначально не открывали его, а предлагали сохранить на диск. Пришлось вручную править заголовки в штатно-стандартной библиотеке AsyncWebServer, из за чего ее теперь не с репозитория ставить, а исключительно из папки Libraries проекта.

По работе знаком с командой, которая пишет веб-интерфейсы для устройств, которые кодируют видео и отправляют его в сеть. Например в браузер для просмотра(специальное браузерное приложение Easy TV player). Так вот они плачут горючими слезами от этих айфонов, айпадов и прочих сафари. Там всё нестандартно, все работает вкривь и вкось, никаких Web/HTML стандартов браузеры не соблюдают, там все по-своему, всё на костылях нужно писать...

 

[TM1]

Добрый день. Пробовал подключение через MMOT с приложения, скорее всего по заводил куда не надо адреса роутера. теперь все эффекты идут с большими тормозами и зависаниями, точка подключения wifi исчезла вообще. пробовал по новой закачать прошивку, всё тоже самое. Как можно исправить? или пробовать новую плату?

 

[vvip]

@TM1, как вариант - по новой закачать прошивку с опцией Erase All Flash Content

 

[AnCore]

Тоже эффекты с подвисаниями, а бегущая строка рывками отображается. Попробую перепрошить с другими настройками..

 

[TM1]

vvip, спасибо. вроде стала работать нормально. прошил заново через Erase All Flash Content. уже боюсь что-то нажимать, чтобы не поломать ничего опять.

 

[AnCore]

@TM1, у вас бегущая строка нормально отображается? Плавно? Спрашиваю, потому что у меня не плавно строка бежит, с небольшими рывками (перепробовал все рекомендуемые настройки в прошивке - безупешно). Поставил прошлогоднюю версию (v.1.14.2023.1114), строка нормально стала отображаться

 

[VadZher]

@vvip,
Я помню эту ситуацию с заголовками и правками библиотеки в апреле прошлого года, когда с версии 1.13 на 1.14 переходили. Тогда ещё и Сотнег подключался, дельные советы давал. Согласен, что для создания кросс-платформенных приложений нервы из вольфрама нужны. Причём, мало кто оценит прилагаемые усилия: конечному пользователю конкретной платформы безразлично, сколько сил и средств было вложено разработчиком в поддержку другой.
Поделюсь своими наблюдениями за работой веб-интерфейса прошивки 1.14с для ESP32 на устройствах с iOS:
Отображение страниц стало работать медленнее. Сама страница с пустыми полями по времени загружается также, но появилась пауза в 0,5-1 секунду до подгрузки данных.
Перед началом отображения бегущей строки эффект замирает на 0,5-1 секунду. При этом, сама строка движется без рывков (использую максимальную скорость).
При использовании режима «Рисование» поставленная на сетке точка всегда отображается на 4 клетки выше и одну левее желаемой. Выбор цвета кисти и меню пиктограмм на этой же странице работают нормально.
Вместе со странным поведением при обновлении страницы с текстами бегущей строки (о чём писал ранее) - это все замечания по работе последней версии веб-интерфейса с iOS.
Сам контролер работает стабильно, эффекты отображаются плавно.
Спасибо Вам за проект и его поддержку!

 

[vvip]

@VadZher, спасибо за отклик. У меня Айфонов нет, так что в случае чего - даже проверить посмотреть не на чем.

Единственное отмечу:
- Для всех (почти всех) страниц алгоритмы и скрипты получения данных не менялись. При открытии страницы (таба) в устройство отправляется список параметров, чтьи значения хотелось бы получить. Далее сервер их отдает в сокет, который слушает браузер. Так что по большому счету ничего тут измениться не должно бы.. Может субъективное восприятие? Могу не отрисовывать элементы страницы, пока не получены значения для отображения. Но поскольку механизм то останется тот же - пауза будет в виде пустой страницы, только потом отображение с данными...

Страница с текстами. Ранее при загрузке страницы выполнялся запрос к контроллеру на получение каждой из 36 строк. Получили одну - запросили другую и так далее. Это могло затянуться секунд на 10, пока не получишь все строки, к тому же - для длинных строк требовало выделение больших буферов памяти, что либо приводило к ее фрагментации, либо просто память кончалась и происходила перезагрузка контроллера.

В последней версии все строки хранятся в файлах в папке, доступной по Web -- загрузка строк происходит обычным HTTP-запросом файлов, содержащих строки. На андроиде и на компе у этих запросов стоят заголовки no-cache, чтобы запрашивалась актуальная версия с контроллера, а не то что браузер сохранил в кэше. По-видимому айфоны (и сафари) - игнорируют все эти заголовки запроса данных не из кэша и отдают браузеру кэшированное содержимое - отсюда и "старые" версии содержимого строк.

Для сбора статистики - кто-нибудь еще заметил замедление загрузки страниц? По сравнению с какой версией?

- Про паузу перед отображением строки - пос сравнению с какой версией?
Вот, скажем, в версии 1.13 все строки хранились в EEPROM, суммарно все строки не могли быть длиннее примерно 2K.
Из EEPROM содержимое строки загружается практически мгновенно. К тому же, они просто хранились в оперативной памяти в буфере. Доступ мгновенный.

Потом кто-то захотел иметь длинные строки. Длинные строки в EEPROM не запихнешь, в памяти тоже особо не похранишь - ее всегда мало. Поэтому хранение самих строк было перенесено в файловую систему. Загрузка строки из файла занимает больше времени. К тому же операция синхронная. Поэтому пока контроллер открывает файл и читает его содержимое - ничего другого не выполняется. Эффект замирает.
Кстати, я у себя особо замираний не замечал. Но у меня вемос например на 160Mhz скомпилирован вместо стандартных 80MHz...

Далее следующий момент. Часть строк ограничена макросом {S} по времени, когда ее можно показывать. Поэтому загруженная строка проверяется и если ее не время отображать - загружается другая строка. Что тоже требует времени. Отсюда паузы перед отображением.

Есть идеи как это все организовать по другому? Держа в уме при этом ограниченный размер оперативной памяти?
Ну, разве что, для ESP32, где памяти поболее - все же кэшировать их в оперативную память... Подумаю над этим моментом...

Про рисование - у меня всё отображается точно. Даже на телефоне, где сетка рисуется мелко, и то примерно тык пальцем и отображение на матрице попадает именно в то место, куда хотел. А у вас при этом - точка на экране соответствует точке, зажигаемой на матрице? Или на экране в одном месте, а на матрице - со сдвигом? Хотя по коду такое, думаю, невозможно...
А если матрица маленькая и клеточки на страничке крупные - касание попадает в желаемую или все равно сдвиг? Может на айфонах с калибровкой экрана что-то не то и координаты касания передаются со смещением?

А есть возможность к этому устройству как-то подключить мышку и тыкать ее острым кончиком стрелки в нужную клетку? Соответствует позиция куда тыкали позиции, которая закрасилась?

Никогда не куплю себе айфон и продукцию эппл. Судя по многочисленным отзывам в моем окружении - глюкалово то еще. Единственное о чем хорошие отзывы - камера...

Это вам еще повезло, что контроллер стабильно, как вы говорите работает.
Я у себя не могу побороть проблему. Проявляется по разному на разных экземплярах контроллеров. И в зависимости от условий компиляции скетча тоже.

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

А может такое проявиться только на некоторых эффектах. На всех все показывается, только к примеру "Мерцание" - только первый светодиод мигает...

А может наоборот - все эффекты показываются нормально, но на отображении некоторых бегущих строк (только некоторых!). все замирает и начинает мерцать первый диод. Вот заметил что в этих строках макрос {D} или {S}. Хотя некоторые строки с макросом {S} в комбинации с {R} отображаются без проблем.

А может наоборот - все строки отображаться нормально кроме строки с макросом {R}.

Я уже голову сломал не могу осознать причину поведения.
Можно вставить несколько пустых строк в коде и пересобрать прошивку - и проблема уйдет. А может и не уйдет.
Можно вставить какой-нибудь пустой не нужный оператор типа String s; s.reserve(20); и проблема уйдет. А может и не уйдет.А можно просто взять кусочек кода, и поменять его местами с другим никак не связанным кусочком кода - просто поменять их местами, передвинув на 10 строк выше/ниже. И проблема уйдет. Можно изменить какое-нибудь значение настроек компиляции в меню "Инструменты". Например поставить "С++ Exception" в 'Enabled'. Или "Stack protection" в "Enabled". Тоже может изменить вышеописанное поведение...

Еще встречал (с бегущей строкой) - есть функция в коде для ее отображения на матрицу, и в ней некоторая последовательность строк кода - все работает ровненько. Потом берем эти несколько строк и переносим в функцию. Там где были строки вызываем эту функцию. Параметров у функции нет. Всё. Дикие тормоза, рывки в бегущей строке.

Чего-то я не понимаю в программировании микроконтроллеров...
Поэтому - соберете прошивку - проверяйте каждый эффект, каждую строку - работает ли, не зависает ли и так далее.

Я не знаю что с этим делать. Та же бегущая строка - у кого-то плавно, у кого-то дергается.
Более того у меня - сегодня все работает плавно. Завтра включишь тот же контроллер, ничего не меняя, прошивку не обновляя, всё как было вчера. Только строка бежит с подергиваниями. Послезавтра может снова нормально все быть... Причин не знаю...
Вот - свежий пример. Контроллер работает несколько часов. Не перегружался.Строки с макросом {D} и{S} - не отображаются. Мигает только первый светодиод. Прошла еще пара часов. Строки с макросами {D}и{S} стали прекрасно отображаться, как и все прочие строки...

 

[VadZher]

@vvip,
На устройствах iOS на сетке рисования я точно попадаю стилусом в правую нижнюю клетку, на сетке отображается точка на 4 клетки выше и 1 клетку левее, она же появляется и на оконной матрице. И такое смещение сохраняется по всей сетке, кроме верхних строчек - они не реагируют на нажатие. На андроид-устройствах и ноутбуке под Windows такой проблемы нет.
Как выглядит задержка отображения данных - запишу и отправлю Вам видео с экрана. Она появилась раньше, было большое обновление, кажется, ещё до правок Vortigont’a, но в версии 1.14с стала более выражена.
С остановкой эффекта перед отображением бегущей строки у меня других идей нет. Может, создавать в памяти массив, состоящий только из актуальных строк? Но, периодическое его обновление потребует чтение файла с текстовыми строками, а значит и фризы эффектов.

 

[TM1]

AnCore, да может немного не плавно, хотя не с чем сравнить и очень маленькая ещё эксплуатация. А в общем мне всё нравится, я первый раз сделал такое. Ещё бы научиться скачивать новые эффекты и перекидывать их на флешку.

 

[AnCore]

@TM1, для начала немного поковыряйтесь в Jinx (что, куда нажимать, как сохранять и тд)

Экспорт эффектов анимации из ПО «Jinx!»

LED панель или гирлянда на WS2812/WS2813, управление ESP8266/ESP32, Web-интерфейс - vvip-68/LedPanelWiFi

github.com

 

[vvip]

@VadZher, про строки - весь вопрос сколько памяти в контроллере. Если на 8266 ее мало и каждый лишний занятый килобайт уменьшает объем свободной памяти и увеличивает вероятность падения контроллера и его перезагрузки. Ну, ок что-нибудь придумаем с кэшем. Перечитывать его не нужно будет. Приняли с браузера - сохранили в постоянную память (в файл) и заменили в кэше в оперативной памяти. Загрузка из файлов - один раз при старте контроллера...

 

[vvip]

Итак, выложил изменения - теперь тексты бегущей строки при старте контроллера сохраняются в оперативной памяти, далее при использовании не загружаются с диска, а берутся из кэша. Исключение - строки длиннее указанного порога длины. Если длинее - по-прежнему будут браться из файла.
Есть желающие потестировать?

#define USE_TEXT_CACHE 1           // Держать тексты бегущей строки в оперативной памяти (по возможности).
                                   // Кэширование строк в памяти позволит свести к нулю время получения очередной строки для отображения
                                   // Загрузка строки из файла требует некоторого времени, что вызывает торможение отображение эффекта перед показом бегущей строки
                                   // Однако кэш в памяти уменьшает объем свободной оперативной памяти, что на устройствах с ESP8266 может приводить к частым
                                   // перезагрузкам микроконтроллера при нехватки памяти. Тогда установите значение этого параметра в 0 - не использовать
#if defined(ESP8266)
#define TEXT_CACHE_LINE_SIZE 200   // Макс длина текста бегущей строки, которая будет кэшироваться. Более длинные строки будут по-прежнему загружаться перед использованием из файла
#else
#define TEXT_CACHE_LINE_SIZE 512   // Макс длина текста бегущей строки, которая будет кэшироваться. Более длинные строки будут по-прежнему загружаться перед использованием из файла
#endif

 

[AnCore]

@vvip, извиняюсь за ожидание (долго не мог сконнектиться.. я домашний вайфай обычно указываю в прошивке, но в этот раз не получалось подключиться и точка доступа даже не появлялась, перепрошился без указания домашней сети и подключился сразу к ней, а уже после указал в интерфейсе свою домашнюю сеть)... В общем, бегущая строка отображается нормально (у меня во всяком случае)

 

[VadZher]

@vvip,
Спасибо за оперативное обновление!
По результатам тестирования на ESP32:
Паузы эффектов перед началом отображения бегущей строки исчезли, строка движется плавно.
Восстановление настроек и текстовых строк из сохранённого на айфон бэкап-файла происходит корректно.
При редактировании текстовых строк с айфона проблем с их сохранением, а также возвратом предыдущей строки при обновлении не возникает, кнопка "показать" доступна. Но обратил внимание, что если бегущая строка содержала макрос с номером эффекта, то после его удаления или изменения на другой строка в автоматическом режиме продолжает отображаться на фоне предыдущего. Обновление страницы при этом не помогает, только перезагрузка контролера. При нажатии на кнопку "показать" строка отображается корректно, на последнем заданном эффекте.