NodeMCU heap size SDK 1.0.0 (голосование)

[Victor]

С учетом этого замечания возникает вопрос:
Сколько же памяти останется после пересборки NodeMCU с SDK 1.0.0
Если размер памяти серьезно уменьшится, то будет ли иметь смысл вообще весь проект NodeMCU?

 

[nikolz]

для отладки алгоритма смысл есть.
После отладки можно переписать на си и загнать на флеш.
-----------------------------------
У меня модули занимают не более 14 Кб
Но проблема в том, что максимальный объем занимаемой памяти хипа модулем не может быть больше 16.
получаем сообщение о нехватке памяти даже если хип начальный 23.
Во как!!!

 

[nikolz]

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

 

[pvvx]

Для работы одного соединения TCP в модуле желательно иметь свободных от 12 килобайт в 'heap'. Если остается менее, то или не будет должным образом работать это соединение (будут крахи) или используйте только UDP. С одним портом "дуплекса" на UDP можно ограничиться в 4 кило.
Эта память необходима для работы "стека" TCP и для внутренних буферов приема-передачи пакетов. Если точнее: стек TCP у модуля имеет 4 mss. Один mss (размер пакета) = ~1.5 килобайта. 4-ре туда и 4-ре сюда, плюс резервный в 1 mss - это что использует внутреннее ПО во время работы с TCP. И ещё буфер на копию одного пакета для разбора уже в Lau т.д (тоже 1 mss). И аналогичный буфер для передачи. Итого примерно, если задействовано всё сразу, от 1.5*10 = 15 килобайт

 

[nikolz]

у меня наблюдается другая проблема:
--------------------------------------
Имеем следующую программу:
dofile("wifi_1.lua")
print(node.heap());
dofile("nk_start.lc")
print("1="..collectgarbage("count")..","..node.heap());
collectgarbage()
dofile("srv_1.lua");
print("2="..collectgarbage("count")..","..node.heap());
-------------------------
function cb() -- callback
collectgarbage()
print("3="..collectgarbage("count")..","..node.heap());
dofile("cbAM2302.lua");
print("4="..collectgarbage("count")..","..node.heap());
dofile("cb18b20.lua");
print("5="..collectgarbage("count")..","..node.heap());
dofile("get_tp.lc");
dofile("norm.lc");
print("6="..collectgarbage("count")..","..node.heap());
end
----------------------------
tmr.alarm(3,2000,1,cb) -- call cb()
---end program-------------------
Как видно из программы в ней есть колбек cb() который вызывается alarm каждые две секунды
Ниже даны сообщения об использовании памяти.
Замечу, что нехватка памяти происходит на втором вызове, а не на первом. При этом еще куча свободной.
Во как!!!
-------------------------------------------------
message in debug:
NodeMCU 0.9.5 build 20150318 powered by Lua 5.1.4
> dofile('main.lua')
192.168.0.105
16040 -- free heap
40 96 209 111 6 0 0 149
40 199 186 111 6 0 0 45
1=10.84, 12040
2=12.14, 9664
> 3=10.01, 12512 ---- first callback
26;19.2
4=12.7, 8744
25.0625;25.3125
5=12.9, 8112
30.1;1000.42;10731.77
6=13.2, 8592 ---- in this line 13.2 --Busy Lua , 8592 -- free heap
-----------------------------------------------
3=11.49,10752 --second callback -- in this line 11.49 --Busy Lua , 10752 -- free heap
next we get message:
PANIC: unprotected error in call to Lua API (not enough memory)
PANIC: unprotected error in call to Lua API (attempt to call a string value)
Why not have enough memory, if you have 10,752 free heap?
H!€И©!КвDИяш
NodeMCU 0.9.5 build 20150318 powered by Lua 5.1.4
---------------------------------------
Замечу, что на 5 шаге мы имели меньше свободной памяти но паники не было.

 

[TRO]

мне вот интересно, а какой удавалось засечь минимальный хип без вылета программы?
Я специально целью не задавался, но вроде меньше восьми килобайт не видел.

 

[nikolz]

примерно 6-7.
----------------------
Для Виктора,
Я написал тест тестирования файловой системы увеличивающимися файлами.
Максимальный размер файла получил 140 Кбайт
Максимальное заполнение файлового пространства полчил 1.8 Мбайт из 4
------------------------------
Послал китайцам тест с результатами.
Получил сейчас ответ:
Re: [nodemcu-firmware] Updating to SDK 1.0 ([HASHTAG]#311[/HASHTAG])
Confirmed, this is file system bug. We will fix it.

 

[Victor]

примерно 6-7.
----------------------
Для Виктора,
Я написал тест тестирования файловой системы увеличивающимися файлами.
Максимальный размер файла получил 140 Кбайт
Максимальное заполнение файлового пространства полчил 1.8 Мбайт из 4
------------------------------
Послал китайцам тест с результатами.
Получил сейчас ответ:
Re: [nodemcu-firmware] Updating to SDK 1.0 ([HASHTAG]#311[/HASHTAG])
Confirmed, this is file system bug. We will fix it.

да, спасибо большое.
я то им тоже открывал issue https://github.com/nodemcu/nodemcu-firmware/issues/309
но мне так и не ответили.
Надеюсь теперь они исправят.
Я же тоже подписан на NodeMCU на гитхабе, так что видел

 

[pvvx]

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

В Lua обычно делают больше ошибок и в ней в тысячи раз больше неопределенностей.
Интерпретатор Lau при объеме, имеющемся объеме памяти у чипа, не актуален.
Для детей уже выпускаются законченные решения в упаковке, того что можно сделать на NodeMCU.

 

[nikolz]

поставил
nodemcu_float_0.9.6-dev_20150331.bin
heap
20536

 

[nikolz]

В Lua обычно делают больше ошибок и в ней в тысячи раз больше неопределенностей.
Интерпретатор Lau при объеме, имеющемся объеме памяти у чипа, не актуален.
Для детей уже выпускаются законченные решения в упаковке, того что можно сделать на NodeMCU.

--------------------------
Не в обиду будет замечено, но Вы опять идете другой дорогой.
-------------------------------
Традиционно сложность отладки уменьшается ASM->C(C++)->C#->(алгоритмические языки в т ч и LUA)
---------------------------------
Применительно к ESP проблема становится еще больше,
так как нет эмулятора и отладка на C требует перезагрузки всей сборки.
Сборка грузится примерно 60 секунд, скрипт на луа 4 секунды
Получаем, что исправление одной ошибки на CИ в 10 раз медленнее чем на луа.
Ну и так далее...
--------------------------------------
Для примера замечу что я уже собрал проект на луа со всеми датчиками и простым сервером и все входит и выходит.
Как говорил солдат, вернувшийся из плена:
"Мужики учите мат часть, а то там больно бьют если не знаешь ."

 

[nikolz]

вспомнил свою первую систему распознавания с ОС реального времени ( память всего была 16 Кбайт)
Во как!!!

 

[Victor]

поставил
nodemcu_float_0.9.6-dev_20150331.bin
heap
20536

вот поэтому и прошивка все еще на SDK 9.6 а не 1.0.0

 

[pvvx]

Не в обиду будет замечено, но Вы опять идете другой дорогой.
-------------------------------
Традиционно сложность отладки уменьшается ASM->C(C++)->C#->(алгоритмические языки в т ч и LUA)

В том то и дело, что традиционно - на ESP не полный и глючный вариант Lua, а СИ - полный.
Исправьте Lau за пару загрузок к примеру чтобы писала логи на все 16 мегобайт... Или проверьте, как она будет вести себя с неполной поддержкой функций HTTP и настроек WiFi
И кто вам сказал, что надо писать на Lua? Я предлагаю писать на AppInventor - там вообще ничего грузить не требуется, а загрузка готового откомпилированного решения по баркодам в телефон (у меня) происходит за 5..10 сек.
И вообще - основная цель модуля ESP8266 = коммуникации по WiFi, что в lua реализовано кусочно и алгоритмически никуда не годится из-за несоблюдения стандартов даже нативного TCP...
Когда доделают интерпретатор Lua на ESP8266 - тогда и возможен ваш разговор. А пока на нем приходится описывать только обходные пути кривости его реализации и творить несовместимые решения с другим миром коммуникационных приложений. Т.е., если конкретно - на сегодня реализация Lua в ESP только для галочки, что типа она там может быть. В целях обучения тоже мало годится - нет возможности полной реализации и поддержки языка на данном модуле даже в будущем из-за его аппаратных ограничений для него. Ардуино и то перспективнее на данном модуле, т.к. может предложить законченные и правильные решения некоторых функций, а не для галочки, как в реализации Lua.

 

[pvvx]

Странслировал NodeMCU с SDK 1.1.1.

------------------------------------------------------------------------------
Section info:
   Section|                   Description| Start (hex)|   End (hex)|Used space
------------------------------------------------------------------------------
      data|        Initialized Data (RAM)|    3FFE8000|    3FFE8AE8|    2792
    rodata|           ReadOnly Data (RAM)|    3FFE8AF0|    3FFEC18C|   13980
       bss|      Uninitialized Data (RAM)|    3FFEC190|    3FFF5F90|   40448
      text|            Cached Code (IRAM)|    40100000|    40107554|   30036
irom0_text|           Uncached Code (SPI)|    40210000|    40269380|  365440
Total Used RAM : 57220
Free RAM : 24700
Free IRam : 2750

Падает, по времени до падения, похоже на WDT:

16:38:30.277> NodeMCU 1.1.1 build 20150612  powered by Lua 5.1.4
16:38:30.277> lua: cannot open init.lua
16:38:35.632> > c_ÇRSöfJSúfJSúê8ŸŽþ†—‡‡ŽŽþ‡Š’ú‡†cþ
16:38:35.632>
16:38:35.693> NodeMCU 1.1.1 build 20150612  powered by Lua 5.1.4
16:38:35.693> lua: cannot open init.lua
16:38:37.567> > c_ÇRSöfJSúfJSúfêcþ
16:38:37.567>
16:38:37.635> NodeMCU 1.1.1 build 20150612  powered by Lua 5.1.4
16:38:37.635> lua: cannot open init.lua
16:38:39.501> > c_ÇRSöfJSúfJSúêcþ
16:38:39.501>
16:38:39.577> NodeMCU 1.1.1 build 20150612  powered by Lua 5.1.4
16:38:39.577> lua: cannot open init.lua
>

Смотрел код, как написана NodeMCU - такую бяку исправить невозможно.

Прогнозируемый heap size на NodeMCU с SDK 1.0.0 был угадан на 100%.