• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

EspLua вместо NodeMCU

Вот если бы Вашу энергию, да в мирных целях...
ESP зто же игрушка, нормальный стек в 64 кб RAM устойчиво работать не будет ( это мало для всех открытых PCB),
только в локалке, или точка точка. Для управления детским вертолетом или домашним термометром. Да и совсем забыл о "умном доме":)
 
Привет pvvx,
"Тамагочи"(борд V:1.0) не умерла, только поспала ночь.
Утром весело замигала лампочкой.
Причина понятна, промывал этиловым спиртом 96% перед фотографией.
Странно, выключилась не сразу (примерно) через 20 минут, просочилась вода 4 % под чип.
у меня были подозрения - что залил, проверял - кварц работал нормально.
Значит еще есть выводы чипа которые весят в воздухе без подтяжки (ну или большие mOm ).
Можем далее мучить "Тамагочи":)
 
NodeMCU 0.9.6 build 20150704 powered by Lua 5.1.4
пишу в память по 16 clk быстрее ?;)
CLK ( 200нс клетка.)
clk.png
 
Последнее редактирование:
Провел 2 теста:
код Lua (ESP07+32mбит)
Код:
if file.open("x.txt","w") then
local i=1
while 1  do
file.writeline("0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000") -- 100
    tmr.wdclr()
    i=i+1
    print(i)
             end
end
что получилось:
Код:
1
...
2524
2525
(завис)

----RESET----
0‚~?–4ы!‹“8’ЃЏ

EspLua.ru 1.2.0 build 20150710  powered by Lua 5.1.4
lua: cannot open init.lua
>
----------------------------
script1.lua     : 232 bytes
x.txt           : 254924 bytes
----------------------------
Total file(s)   : 2
Total size      : 255156 bytes

Тест 2 на другой прошивке
1
...
13255
13256
13257
ь!¤„я1д)mф1д)Н!Ьяи ( перезагрузился сам )

NodeMCU 0.9.6 build 20150704  powered by Lua 5.1.4
lua: cannot open init.lua
>
и это все что может FS ?
 
Последнее редактирование:

pvvx

Активный участник сообщества
А сколько грузила 176 байт чисто по SPI ?
Долго :)
, а то в месте с UART не понятно - UART на 9600?
Это был старт прошивки и смотрел на сколько ускоряет загрузку "rapid loader".
Обещанные 30..50 ms до полного старта кода обеспечивает, что невозможно с обычным загрузчиком.
 

pvvx

Активный участник сообщества
EspLua.ru 1.2.0 build 20150710 powered by Lua 5.1.4
померил.
У меня получилось от просыпания, до старта init.lua 1,5сек.
не та ревизия прошивки?
Ну сколько раз говорить? Сама Lua и особенно spissf имеют дестяку тысяч проблем, т.к. "портированием" на lx106 (систему CPU ESP8266) их никто не занимался. То что есть - это просто бездарная копия от их создателей.
По этому, во первых, имеем полный тормоз Lua и spiffs на flash, когда её диск состоит более чем из нескольких сотен "сегментиков" и во вторых встроен тормоз с чтением памяти констант из flash или IRAM. В итоге до старта уже Lua ждать приходиться сутками :) и работать быстрее чем на 9600 Бод по UART она практически не может. :p
В NodeMCU обработка каждой строки или даже части происходит по минимальному таймеру в 80 ms (READLINE_INTERVAL). По этому говорить о скорости её работы нет никакого смыслу.
Загрузчик "rapid loader" обеспечивает то, что через 30 ms после включения модуля идет настройка WiFi (уже исполняется код SDK) и дальнейшее соединение будет готово значительно быстрее...
 
Последнее редактирование:

pvvx

Активный участник сообщества
Тогда до старта чего, начала bin кода ?
а я понял - ветка называется:
EspLua вместо NodeMCU
Да, и я пытаюсь исправить это дело. Всё поэтапно. До интерпретатора Lua ещё не дошел.
Пока идет подгонка методов и частичные исправления spiffs.
Но главная цель - найти варианты и алгоритмы как скорректировать всё это дело, что-бы кто-то из реальных "программистов" взялся за создание и поддержку нормального варианта Lua на ESP8266.
Не нравится - обращайтесь к китайцам с их NodeMCU :)
 
Мне нравиться идея с интерпретатором, очень удобно для стартапов,
да и на СИ такие "выкрутасы" сложно сделать. На каком языке писать давно уже все равно;).
Если платформа "устаканиться" - это очень хорошо,
скорость работы терпимая строка выполняется за ~200мкс, а вот устойчивость ни какая,
да и Вы сами пишите в каждом письме о проблемах.
Простой тест FS - даже с одним файлом и крах на всех версиях! (зачем я ставил 32, 128мб :( 4м достаточно! )

Спасибо что не бросаете этот проект.
Если нужно будет помучить "Тамагочи" пишите.:)
Буду отслеживать Вашу ветку.
 

pvvx

Активный участник сообщества
Простой тест FS - даже с одним файлом и крах на всех версиях! (зачем я ставил 32, 128мб :( 4м достаточно! )
Вы же видели какие потери на файловой системе spiffs при 16 мегабайтах flash. Там надо применять другую разметку. Такое кол-во блоков по 256 байт на 16 мегабайтах ни к чему (реальный сектор во flash 4096 байт). Да и вообще spiffs на таких объемах неоправдана, тем более метод её портирования, где идет чтение flash по 4 байта. Такие накладные расходы сжирают производительность в ноль. А мне как-то неохота переписывать всё и оставлять при этом совместимость с убожеством spiffs и имеющейся реализации Lua... Мне интересны только задачи в промежутке между этими монстроидальными пакетами и системой, до уровня hard...
 
Последнее редактирование:
Вы же видели какие потери на файловой системе spiffs при 16 мегабайтах flash.
я не спец в этих ESP библиотеках (еще ни как сам собрать проект не могу:)),
может глупый вопрос, а приклеить нормальную FS с каталогами, временем и тд.,
к примеру из STM32 - работает отлично, использую много лет.
Хотя при RAM в 64 к. грустно будет...:(
 
А что хотите изменить?
могу собрать и выложить.
-Модули подключать по надобности. ( экономить RAM)
-Uart по умолчанию 230, 460, 921
-Буферы UART увеличить с 100/256 до 1024 или по более.
- int или float все равно.
Еще что придумается в процессе.:)
Я понял все проблемы с майк-файлом.

Если не очень трудно, собрали бы работающий проект с майк-файлом для форума.
думаю что многим пригодилось бы ;).
 
Последнее редактирование:
Сверху Снизу