Как самому отключить модули в NODEMCU

[pvvx]

Что-то всё у вас не правильно, совсем не так как пишите. Запустил данную помойку на SDK version: 1.1.2. Начал чистить - уже 2 файла си выкинул За увеличение памяти ещё не брался, т.к. там такое понаписали друзья @nikolz, лучше помолчю ... .

SDK version: 1.1.2
data  : 0x3ffe8000 ~ 0x3ffe8b1c, len: 2844
rodata: 0x3ffe8b20 ~ 0x3ffec4e4, len: 14788
bss   : 0x3ffec4e8 ~ 0x3fff62d0, len: 40424
heap  : 0x3fff62d0 ~ 0x3fffc000, len: 23856
Heap size: 23536 bytes.
Flash Header:
 Number of segments: 3
 SPI Flash Interface: QIO
 SPI CLK: 80MHz
 Flash size: 512K
 Entry point: 0x40100004
 Segment 1: offset: 0x40100000, size: 28648
 Segment 2: offset: 0x3ffe8000, size: 2844
 Segment 3: offset: 0x3ffe8b20, size: 14788
Found free IRAM: base:0x40106fe8, size:4120 bytes
Real Flash size: 524288 bytes.
mode : softAP(1a:fe:34:9f:c0:bf)
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
add if1
bcn 100

fs.start:0006f000,size:0000d000
mount res: 0
Task task_lua started.
SIG_LUA received.

NodeMCU 1.1.2 build 20150624  powered by Lua 5.1.4
lua: cannot open init.lua
Heap size::14480.
> print(node.heap());
15984
> print(node.heap());
15984

 

[jmms]

@nikolz Да я уже понял что никто ничего не считал, не нужно предлагать методы подсчета, это не продуктивно.
Но полезно то, что да, действительно есть здравое зерно в ваших словах: зачем напрягаться и учить C++, если можно накабанить на Lua.
Мне просто не ясно, ну накабанил я код на Lua для ESP, окей, работает. Вот беру другой МК (мир то на ESP клином не сошелся, верно) - что тоже нужно для этого МК на Lua кабанить?
Я просто прямо спрошу (чтобы вам не приходилось читать мысли): где еще используется Lua, кроме ESP (я сейчас про сферу МК спрашиваю)?

 

[pvvx]

Взмахом волшебной палочки прибавляем 16 килобайт к IRAM для дальнейшего перемещения туда буферов...

Спойлер: лог

SDK version: 1.1.2
data  : 0x3ffe8000 ~ 0x3ffe8b1c, len: 2844
rodata: 0x3ffe8b20 ~ 0x3ffec4e4, len: 14788
bss   : 0x3ffec4e8 ~ 0x3fff62d0, len: 40424
heap  : 0x3fff62d0 ~ 0x3fffc000, len: 23856
Heap size: 23536 bytes.
Flash Header:
Number of segments: 3
SPI Flash Interface: QIO
SPI CLK: 80MHz
Flash size: 512K
Entry point: 0x40100004
Segment 1: offset: 0x40100000, size: 28648
Segment 2: offset: 0x3ffe8000, size: 2844
Segment 3: offset: 0x3ffe8b20, size: 14788
Found free IRAM: base:0x40106fe8, size:20504 bytes
Real Flash size: 524288 bytes.
mode : softAP(1a:fe:34:9f:c0:bf)
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
add if1
bcn 100

fs.start:0x0006f000,size:0x0000d000
mount res: 0
Task task_lua started.
SIG_LUA received.

NodeMCU 1.1.2 build 20150624  powered by Lua 5.1.4
lua: cannot open init.lua
Heap size::14480.
> print(node.heap());
15984
>

Получаем 20 килобайт пустой IRAM и 15 килобайт HEAP (ничего не вырезано, а на оборот - включена полная отладка) Дальше надо ковырять и переносить всё как надо, да функции новые из нового SDK включать...
А nikolz-у итого не дам Ему хватает старой версии, от своих приятелей. Если накручу и увижу что nikolz будет пользоваться новой, закрою восстановление Lua на новый лад всем

 

[pvvx]

С 5.5 кило nikolz опять ошибся. Посмотрите лог - 23 кило свободного heap до старта NodaMCU и при них уже загажен bss и rodata на 10 кило + 15 кило минимум. Ещё задействована переполняющая и затирающая данные ROM-BIOS глубина стека CPU за 8 килобайт. Так писали NodaMCU "евросоюз и страны брикс" + китайцы
Одних сообщений более 10 килобайт в rodata было - часть уже сместил в flash, а flash читалась по 4 байта максимум с обращением через десяток вложений функций, которые просто тусуют эти байты туда-сюда до обращения к функции ROM-BIOS... Всё это безобразие можно наглядно посмотреть в их иcходниках
Так пишут те, кто знает только Lua

 

[pvvx]

что Вы не сможете отладить все то,
на что пописали( то бишь пометили)?

Но одному скучно. Вот вы не ответили на вопрос, а я туда ещё не долез (до как оно тама интерпретируется...). Там столько кривого, что даже не знаю как это исправлять...

 

[nikolz]

В качестве информации.
1) Вот перечень ядер на которые уже портирован eLUA
ARM7TDMI,Cortex-M3 ,ARM966E-S
--------------------
2) несколько советов как быстро реализовать свой проект на луа и чтобы было счастье,
и чтобы не мешали ... как начинающему танцору.
------------------
Совет 1: Напишите весь алгоритм словами или кубиками на бумаге.
Продумайте все от начала и до конца.
Это позволит сэкономить много вашего времени.
---------------------
Совет 2: Для начала изучите язык программирования используя бесплатный софт для винды.
запрограммируйте простейшие примеры работы с таблицами потоками функциями
-------------------
Совет 3: Изучите документацию того железа и софта, на котором Вы будете реализовывать Вашу идею.
Т е не идею придумывают глядя на железо, а железо выбирают под идею.
--------------------------
Список советов продолжим позже
спасибо за внимание.

 

[jmms]

@nikolz Я в курсе, что этот ЯП запихнули и в Варкрафт и много где еще, но мы ведь обсуждаем МК, то есть в контексте других МК луа используется не часто, то есть используется судя по всему только в ESP. // окей вопрос снят
Я не понимаю какую логику нужно пихать в МК, решайте задачи на Python, используйте ESP+RaspberryPi или отправляйте данные в облако и считайте там. Вы же за экономию времени ратуете. Я не могу понять: зачем делать сложную логику на этом МК, для которой прийдется переходить к высокоуровневому скриптовому языку, потенциал которого упирается в ресурсы МК.

 

[nikolz]

С 5.5 кило nikolz опять ошибся. Посмотрите лог - 23 кило свободного heap до старта NodaMCU и при них уже загажен bss и rodata на 10 кило + 15 кило минимум. Ещё задействована переполняющая и затирающая данные ROM-BIOS глубина стека CPU за 8 килобайт. Так писали NodaMCU "евросоюз и страны брикс" + китайцы
Одних сообщений более 10 килобайт в rodata было - часть уже сместил в flash, а flash читалась по 4 байта максимум с обращением через десяток вложений функций, которые просто тусуют эти байты туда-сюда до обращения к функции ROM-BIOS... Всё это безобразие можно наглядно посмотреть в их иcходниках
Так пишут те, кто знает только Lua

-----------------
pvvx,
Вы начинаете утомлять своим недоверием к людям и невнимательным прочтением чужих постов.
Во-первых, я написал, что у меня получилось 7.5. Полагал, что Вы сообразите, что 5.5 это очевидно не мой результат.
Вместо того, чтобы спросить подробнее,
Вы как всегда "с лапатами и граблями немного покумекали" облили всех ... и ничего до конца не сделали вытащили нового дохлого кролика из шляпы.
Ну чтож, в очередной раз проведу лекбес.
Вот данные теста eLua по сравнению с LUA автор Богдан Маринеску
Приведенная ниже таблица суммирует использование памяти в килобайтах .
ОПТ = 0 является "режим совместимости с простой Lua) и ОПТ = 2 патч в действии eLUA.
Платформа ОПТ = 0 ОПТ = 2
AVR32................ 23.75....... 5.42
AT91SAM7X ........ 25.16..... 5.42
Str7....................... 24.92 ..... 5.42
STR9..................... 22.23..... 5.42
LPC2888.............. 22.23 ..... 5.42
i386...................... 16.90 ..... 5.42
LM3S.................... 27.14 ..... 5.42

 

[pvvx]

5.5 это очевидно не мой результат.

Результат оптимизации кода NodeMCU?

Вместо того, чтобы спросить подробнее,

Вы знаете, что СИ или ASM вообще не использует памяти RAM, только для хранения результата, если его надо хранить
И какая цель спрашивать подробнее у того, кто не понимает, что файловая система, сообщения об ошибках и главное TCP стек с разбором сетевых протоколов тоже потребляют RAM
http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html - там и писано - что эти 5.5 есть сферический конь в вакууме. Можно сложить 2+2 и получить 4 в памяти без отображения, затратив 5 кило на Lua.
Давайте конкретные данные, применительно к сетевым протоколам на ESP8266. Подсчитайте - все данные уже известны, но мне пока не известна реализация кривого "портирования" на "портирование", т.е. смесь spiffs + огрызки Lua на текущей NodeMCU. И тем более там свё сделано не так, как вы описываете, а кое как собрали НодеМСУшники и выкинули...

PS: Поддержку 16 Мег flash уже сделал, почуток разгребаю дальше... но будет долго...

 

[nikolz]

Но одному скучно. Вот вы не ответили на вопрос, а я туда ещё не долез (до как оно тама интерпретируется...). Там столько кривого, что даже не знаю как это исправлять...

pvvx,
мне Вас жаль,неужели Все так плохо?
Вот сколько я прочитал Ваших постов и ни в одном из них
Вы не сказали ничего хорошего про чужие разработки (все хорошее - это лишь Ваше творение, к сожаление все не доделано или не допилено)
Я думал,что такая мания величия лишь у новорожденных.

 

[pvvx]

pvvx,
Вы знаете, что говорите ерунду.
Ни СИ ни ASM вообще ничего не используют, так как это языки программирования - это лишь для человека а то,
что исполняется никак не похоже ни на си ни на asm.

Неужели догадались? А почему тогда для NodeMCU надо память?

 

[pvvx]

pvvx,
мне Вас жаль,неужели Все так плохо?
Вот сколько я прочитал Ваших постов и ни в одном из них
Вы не сказали ничего хорошего про чужие разработки (все хорошее - это лишь Ваше творение, к сожаление все не доделано или не допилено)

Как-же - все поставленные задачи выполнены. А вот ваша нет.

Я думал,что такая мания величия лишь у новорожденных.

Ну тут я не могу сравниться с вами. Вы же великий программист и можете запросто сделать супер Lua VM на ESP8266, правда пока только путем удаления драйверов и указками на викопедию... Пытаюсь тут помочь вам, но ничего не выходит. Оказывается всё не так.

Наверно опять ошибаетесь, у меня нет целей создания Стартапов, как у писателей NodeMCU... Всё намного проще - загибается, т.е. уже загнулась ваша любимая NodeMCU. Для соблюдения баланса надо её реанимировать и дать возможность кому-то выростить из неё что-то далее. Причитаниями и агитками о том, что якобы памяти для проектов на Lua в ESP8266 не требуется тут не поможете...

 

[Victor]

В этом холиваре добавлю масла в огонь:
Lua довольно часто используется в embedded. Почему? Не знаю, но думаю, что часть аргументов nikolz соответствует действительности.
Один из примеров: Lua является основным языком в функциях веб интерфейса OpenWRT.
Да, pvvx, тоже прав - в теперешнем состоянии (на SDK 0.9.5-0.9.6) NodeMCU никуда не годится.
Вот выйдет новый чип Espressif - с бОльшей памятью и NodeMCU вполне может выстрелить на новом SDK

 

[pvvx]

В этом холиваре добавлю масла в огонь:

холивара нема - я пытаюсь исправить NodeMCU на SDK 1.1.2 и далее с увеличением памяти, а Nicolz всеми силами пытается отговорить это делать

Lua довольно часто используется в embedded. Почему? Не знаю, но думаю, что часть аргументов nikolz соответствует действительности.

Это случайное совпадение. Всегда часть спама совпадает с реальностью

Вот выйдет новый чип Espressif - с бОльшей памятью и NodeMCU вполне может выстрелить на новом SDK

Не думаю, что вопрос у NodeMCU в SDK 1.1.2. Вся беда в бездарных портировщиках Lua и глупой бездарной пропаганде Nicolz .
Пример пожирания памяти стека в Lua неимоверными кусками:
https://github.com/nodemcu/nodemcu-firmware/blob/master/app/lua/liolib.c#L344
Структура luaL_Buffer имеет в себе буфер в 4 килобайта!
[HASHTAG]#define[/HASHTAG] LUAL_BUFFERSIZE ((BUFSIZ)*4)
[HASHTAG]#define[/HASHTAG] BUFSIZ 1024

А глубина стека у ESP8266 находящегося в RAM_BIOS не более 5 килобайт.
По адресу 0x3FFFEB30 находится блок переменных ROM_BIOS, а ниже буфер aes_data.
0x40000000 - 0x3FFFEB30 = ? (пусть Nicolz подсчитает )

Как будем называть новую версию, если запилю старую NodeMCU?
Частично уже работает, памяти уже больше чем в их версии на 0.9.5... Как будет сформировано что-то стабильное - закину на git. Но надо новое название, чтобы раздражать старых портировщиков
В старой версии стек опускается ниже 0x3FFFE000, т.е. как и писал - он более 8 килобайт.
Проверил, поставив метки...
Ниже расположены буфера UartDev.RcvMsgBuff UartDev.TrxBuff (их конец RAM_BIOS:3FFFDFC4)
Записан lua.init = print(node.heap()); :

NodeMCU 1.1.2 build 20150624  powered by Lua 5.1.4
14008
System stack overflow (low 0x3fffe004)!

 

[pvvx]

Скинул, что пока вышло: EspLua вместо NodeMCU
nikolz остается здесь и продолжает удалять модули в NodeMCU 0.9.6

 

[nikolz]

Добрый день,
Привожу результаты компиляции nodeMCU с отключением различных модулей:
----------------------------
WS2812,U8G освобождает в RAM 1152 байта
+ COAP +680
+pWM +120
+ADC +32
+MQTT +664
-------------------------------
Так как модули eLUA исполняются из флеш,
то освобождаемый объем RAM не столь существеннен, но все же с удалением указанных модулей увеличивается с 20752 до 23400.
----------------------------------------------
Но даже, если мы выкинем все модули и VM Lua,
то увеличить размер хипа более чем на 20 кбайт не получится,
так как даже при одном лишь SDK объем свободной памяти составляет всего 40 Кбайт.
---------------------------------------------
Из этого следует, что ограниченный объем RAM - это особенность любых микроконтроллеров и эту особенность надо учитывать при написании программ на любом языке.
-----------------------------
Про Луа:
Достоинство Lua - как языка высокого уровня - это высокая скорость получения готовых решений.
Обычно на это уходит (для ESP у меня) от 1 до 5 часов.
Попробуйте посчитать Ваши затраты времени на готовое решение на СИ для ESP.
Кроме того, я загружаю в ESP байт-код программы на луа.
Это не только ускоряет вычисления но и дает существенную экономию RAM примерно 4Кбайт.
Для этого я использую кросс-компилятор под виндой.
---------------------
После того, как алгоритм отлажен, если есть желание, можно перенести его исполнение во флеш.
надо учиться писать программы на луа и изучать язык.
----------------------
В результате нет ограничений на имеющийся объем хипа. К настоящему времени я истратил лишь половину его
а добавление каждого нового моего модуля уменьшает хип на 200 байт. Т е потенциально могу добавить еще полста модулей на луа.
Всем успехов.

 

[jmms]

@nikolz

Попробуйте посчитать Ваши затраты времени на готовое решение на СИ для ESP.

Смотря что писать. Что подразумевается под готовым решением? Это может быть и "Hello World" за 2 минуты и мигание светодиодом за 5 минут.
Я делал скетч для настройки ESP по Wi-Fi, сделал сначала NodeMCU+Lua, это заняло примерно рабочие сутки (8 часов). Потом еще один день разносил по файлам чтобы поделка не падала. Потом плюнул и переписал, как библиотеку на C++ за примерно такое же время. При том, что я C++ видел в последний раз в университете, а Lua для меня что то наподобие JavaScript, но раньше с ним не встречался.
И конечно же помогло наличие в сообществе ардруинщиков кучи готовых библиотек, которые или уже работают на ESP или можно при желании изменить чтобы работали, или взять как пример.

 

[nikolz]

@nikolz

Смотря что писать. Что подразумевается под готовым решением?

Готовое решение - это когда все работает и не виснет и не валится и не глючит.
-----------------------
Для примера, я написать на eLUA ESP вот это:
-------------------------
1) инициализация wi-Fi
2) инициализация клиента и сервера UDP(сервер слушает команды с компа)
3) колбек опроса датчиков
В колбеке работа с датчиками:
1.датчик температуры DS - 3 шт, с автоопределением адресов и возможностью просто повесить на провод еще 7
2. датчик BMP180
3. датчик AM2302
4. датчик HC-SR04
5.PWM - управление диммером или серво (одновременно не делал)
6. Передача данных по WI-FI на сервер на винде с выводом на графики и в базу (на винде тоже на луа)
затраты хипа 12 Кбайт. затраты флеш примерно 100 кбайт
все опросы и ответы успеваю сделать за 1 секунду
---------------------
Так как хипа еще целая гора, то можно еще написать столько же и даже больше.
Но у меня желания закончились.

 

[pvvx]

Готовое решение - это когда все работает и не виснет и не валится и не глючит.

Но на NodeMCU это невозможно. Там даже не только Lua виновата, сколько её портировщики. Они не смогли написать коммуникацию с LwIP, а сделали это через глючный espconn, плюс много ошибок с spiffs. Остальное уже описал - стек в NodeMCU затирает всё...
В итоге создание простейшего детского проекта на NodeMCU вырастает в борьбу с её глюками и поисками их обходов, на что у многих уходит времени и сил больше, чем взять готовый сторонний проект или написать свой на СИ (одновременно изучив СИ ).
Весь ажиотаж с NodeMCU (кол-во её скачиваний) произошел из-за пиара и рекламы. Но взяв/скачав её 90% бросают, т.к. она не работает, как заявлено. Время и показало всю несостоятельность реализации NodeMCU, что даже разработчики бросили проект.
Доказательство, что исправив большую часть бредо-кода и подход горе-портировшиков Lua и spiffs с новыми, менее глючными SDK, для продления жизни NodeMCU уже представлено. Ранее вы хвалили этих "разработчиков" - теперь пожинайте плоды - создав плату и продав пару штук они сгинули, т.к. оно (NodeMCU) уже изначально было не живое (бесперспективное)

 

[nikolz]

Как это не печально,
но у меня все работает.