EspLua вместо NodeMCU

[pvvx]

Текущая версия на SDK 1.3.0 https://github.com/pvvx/EspLua/releases
node.heap() 41576
----------
Начало переделки NodeMCU на SDK 1.2.0 и новый лад = EspLua.
Первый шаг:
1) Адаптация SDK 1.2.0 для данной задачи. Проделано + подключен ускоряющий загрузку системы в десятки раз "Rapid Loader".
2) Выкидывание глупостей портировщиков Lua, Spiffs и прочих либ вошедших в сборку. Проделано в основном для связи с новыми SDK. Встроенные модули Lua практически не трогались. Необходим их тест и ревизия.
3) Изменения связанные с поддержкой Spiffs до 16 мегабайтных flash включительно. Проделано, с увеличением скорости файловой системы...
4) Переписывание частей связанных с памятью. Частично проделано - ещё не задействован полностью буфер в IRAM. Имеется возможность увеличения буфера в IRAM к 20 килобайтам.
5) Исправления lua функций на SDK 1.2.0. Ещё не делалось, кроме tmr.wdclr() - теперь это не сброс WDT, а запуск процессов SDK если им требуется. Там, в SDK и происходит сброс WDT. Вставляем в скрипты Lua во все циклы, где время исполнения более пары десятков ms и нет обращений к файловой системе (там уже вставлено), чтобы SDK c WiFi работало.
6) Добавление новых функций Lua из SDK 1.2.0. Введено только пару необходимых команд: file.fsstat(), wifi.sta.rssi(), wifi.max_tpw().

Пока имеется:

EspLua.ru 1.2.0 build 20150718  powered by Lua 5.1.4
lua: cannot open init.lua
=node.heap()
38648

и отладка в TX1:

Start Heap size: 46000 bytes.
Real Flash size: 16777216 bytes.
Found free IRAM: base: 0x4010ae48, size: 4536 bytes

Глубину стека пока сильно не чинил... Базовая версия NodeMCU имеет ещё больше глубину и затирает данные ROM-BIOS

Работать на Lua не хочу - проверяем и пишем что там из команд не работает. Тогда по возможности исправлю...

 

[pvvx]

ESPlorer пишет неправильно:

EspLua.ru 1.1.2 build 20150626  powered by Lua 5.1.4
Hello, world.
>
Communication with MCU...
Got answer! AutoDetect firmware...

NodeMCU firmware detected.
=node.heap()
19184
>

Нет там больше NodeMCU. Там EspLua.ru!
И что такое "firmware detected" ? 'Обнаружена фирм-посуда' ?

PS: Вы ещё не заняли доменное имя EspLua.ru ? Тогда мы идем к вам

 

[pvvx]

Кто знает, куда spifs или ESPlorer девает память Flash?

Спойлер: полный лог формата 16M flash с включенной отладкой

SDK version: 1.1.2
data  : 0x3ffe8000 ~ 0x3ffe8ae8, len: 2792
rodata: 0x3ffe8af0 ~ 0x3ffeb87c, len: 11660
bss   : 0x3ffeb880 ~ 0x3fff5660, len: 40416
heap  : 0x3fff5660 ~ 0x3fffc000, len: 27040
Heap size: 26720 bytes.
Found free IRAM: base:0x40106fc8, size:20536 bytes
Real Flash size: 16777216 bytes.
fs.start: 0x00080000, size: 16252928
mount res: 0
Task task_lua started.
SIG_LUA received.

EspLua.ru 1.1.2 build 20150626  powered by Lua 5.1.4
Heap size::15880.
System stack overflow (Low 0x3fffe490)!
> print(uart.setup(0, 74880, 8, 0, 1, 1 ))
74880
>
file.format()
addr_first: 0x00080000, size: 16252928
fs.erase_blk: 0x80
fs.erase_blk: 0x90
fs.erase_blk: 0xa0
fs.erase_blk: 0xb0
fs.erase_blk: 0xc0
fs.erase_blk: 0xd0
fs.erase_blk: 0xe0
fs.erase_blk: 0xf0
fs.erase_blk: 0x100
fs.erase_blk: 0x110
fs.erase_blk: 0x120
fs.erase_blk: 0x130
fs.erase_blk: 0x140
fs.erase_blk: 0x150
fs.erase_blk: 0x160
fs.erase_blk: 0x170
fs.erase_blk: 0x180
fs.erase_blk: 0x190
fs.erase_blk: 0x1a0
fs.erase_blk: 0x1b0
fs.erase_blk: 0x1c0
fs.erase_blk: 0x1d0
fs.erase_blk: 0x1e0
fs.erase_blk: 0x1f0
fs.erase_blk: 0x200
fs.erase_blk: 0x210
fs.erase_blk: 0x220
fs.erase_blk: 0x230
fs.erase_blk: 0x240
fs.erase_blk: 0x250
fs.erase_blk: 0x260
fs.erase_blk: 0x270
fs.erase_blk: 0x280
fs.erase_blk: 0x290
fs.erase_blk: 0x2a0
fs.erase_blk: 0x2b0
fs.erase_blk: 0x2c0
fs.erase_blk: 0x2d0
fs.erase_blk: 0x2e0
fs.erase_blk: 0x2f0
fs.erase_blk: 0x300
fs.erase_blk: 0x310
fs.erase_blk: 0x320
fs.erase_blk: 0x330
fs.erase_blk: 0x340
fs.erase_blk: 0x350
fs.erase_blk: 0x360
fs.erase_blk: 0x370
fs.erase_blk: 0x380
fs.erase_blk: 0x390
fs.erase_blk: 0x3a0
fs.erase_blk: 0x3b0
fs.erase_blk: 0x3c0
fs.erase_blk: 0x3d0
fs.erase_blk: 0x3e0
fs.erase_blk: 0x3f0
fs.erase_blk: 0x400
fs.erase_blk: 0x410
fs.erase_blk: 0x420
fs.erase_blk: 0x430
fs.erase_blk: 0x440
fs.erase_blk: 0x450
fs.erase_blk: 0x460
fs.erase_blk: 0x470
fs.erase_blk: 0x480
fs.erase_blk: 0x490
fs.erase_blk: 0x4a0
fs.erase_blk: 0x4b0
fs.erase_blk: 0x4c0
fs.erase_blk: 0x4d0
fs.erase_blk: 0x4e0
fs.erase_blk: 0x4f0
fs.erase_blk: 0x500
fs.erase_blk: 0x510
fs.erase_blk: 0x520
fs.erase_blk: 0x530
fs.erase_blk: 0x540
fs.erase_blk: 0x550
fs.erase_blk: 0x560
fs.erase_blk: 0x570
fs.erase_blk: 0x580
fs.erase_blk: 0x590
fs.erase_blk: 0x5a0
fs.erase_blk: 0x5b0
fs.erase_blk: 0x5c0
fs.erase_blk: 0x5d0
fs.erase_blk: 0x5e0
fs.erase_blk: 0x5f0
fs.erase_blk: 0x600
fs.erase_blk: 0x610
fs.erase_blk: 0x620
fs.erase_blk: 0x630
fs.erase_blk: 0x640
fs.erase_blk: 0x650
fs.erase_blk: 0x660
fs.erase_blk: 0x670
fs.erase_blk: 0x680
fs.erase_blk: 0x690
fs.erase_blk: 0x6a0
fs.erase_blk: 0x6b0
fs.erase_blk: 0x6c0
fs.erase_blk: 0x6d0
fs.erase_blk: 0x6e0
fs.erase_blk: 0x6f0
fs.erase_blk: 0x700
fs.erase_blk: 0x710
fs.erase_blk: 0x720
fs.erase_blk: 0x730
fs.erase_blk: 0x740
fs.erase_blk: 0x750
fs.erase_blk: 0x760
fs.erase_blk: 0x770
fs.erase_blk: 0x780
fs.erase_blk: 0x790
fs.erase_blk: 0x7a0
fs.erase_blk: 0x7b0
fs.erase_blk: 0x7c0
fs.erase_blk: 0x7d0
fs.erase_blk: 0x7e0
fs.erase_blk: 0x7f0
fs.erase_blk: 0x800
fs.erase_blk: 0x810
fs.erase_blk: 0x820
fs.erase_blk: 0x830
fs.erase_blk: 0x840
fs.erase_blk: 0x850
fs.erase_blk: 0x860
fs.erase_blk: 0x870
fs.erase_blk: 0x880
fs.erase_blk: 0x890
fs.erase_blk: 0x8a0
fs.erase_blk: 0x8b0
fs.erase_blk: 0x8c0
fs.erase_blk: 0x8d0
fs.erase_blk: 0x8e0
fs.erase_blk: 0x8f0
fs.erase_blk: 0x900
fs.erase_blk: 0x910
fs.erase_blk: 0x920
fs.erase_blk: 0x930
fs.erase_blk: 0x940
fs.erase_blk: 0x950
fs.erase_blk: 0x960
fs.erase_blk: 0x970
fs.erase_blk: 0x980
fs.erase_blk: 0x990
fs.erase_blk: 0x9a0
fs.erase_blk: 0x9b0
fs.erase_blk: 0x9c0
fs.erase_blk: 0x9d0
fs.erase_blk: 0x9e0
fs.erase_blk: 0x9f0
fs.erase_blk: 0xa00
fs.erase_blk: 0xa10
fs.erase_blk: 0xa20
fs.erase_blk: 0xa30
fs.erase_blk: 0xa40
fs.erase_blk: 0xa50
fs.erase_blk: 0xa60
fs.erase_blk: 0xa70
fs.erase_blk: 0xa80
fs.erase_blk: 0xa90
fs.erase_blk: 0xaa0
fs.erase_blk: 0xab0
fs.erase_blk: 0xac0
fs.erase_blk: 0xad0
fs.erase_blk: 0xae0
fs.erase_blk: 0xaf0
fs.erase_blk: 0xb00
fs.erase_blk: 0xb10
fs.erase_blk: 0xb20
fs.erase_blk: 0xb30
fs.erase_blk: 0xb40
fs.erase_blk: 0xb50
fs.erase_blk: 0xb60
fs.erase_blk: 0xb70
fs.erase_blk: 0xb80
fs.erase_blk: 0xb90
fs.erase_blk: 0xba0
fs.erase_blk: 0xbb0
fs.erase_blk: 0xbc0
fs.erase_blk: 0xbd0
fs.erase_blk: 0xbe0
fs.erase_blk: 0xbf0
fs.erase_blk: 0xc00
fs.erase_blk: 0xc10
fs.erase_blk: 0xc20
fs.erase_blk: 0xc30
fs.erase_blk: 0xc40
fs.erase_blk: 0xc50
fs.erase_blk: 0xc60
fs.erase_blk: 0xc70
fs.erase_blk: 0xc80
fs.erase_blk: 0xc90
fs.erase_blk: 0xca0
fs.erase_blk: 0xcb0
fs.erase_blk: 0xcc0
fs.erase_blk: 0xcd0
fs.erase_blk: 0xce0
fs.erase_blk: 0xcf0
fs.erase_blk: 0xd00
fs.erase_blk: 0xd10
fs.erase_blk: 0xd20
fs.erase_blk: 0xd30
fs.erase_blk: 0xd40
fs.erase_blk: 0xd50
fs.erase_blk: 0xd60
fs.erase_blk: 0xd70
fs.erase_blk: 0xd80
fs.erase_blk: 0xd90
fs.erase_blk: 0xda0
fs.erase_blk: 0xdb0
fs.erase_blk: 0xdc0
fs.erase_blk: 0xdd0
fs.erase_blk: 0xde0
fs.erase_blk: 0xdf0
fs.erase_blk: 0xe00
fs.erase_blk: 0xe10
fs.erase_blk: 0xe20
fs.erase_blk: 0xe30
fs.erase_blk: 0xe40
fs.erase_blk: 0xe50
fs.erase_blk: 0xe60
fs.erase_blk: 0xe70
fs.erase_blk: 0xe80
fs.erase_blk: 0xe90
fs.erase_blk: 0xea0
fs.erase_blk: 0xeb0
fs.erase_blk: 0xec0
fs.erase_blk: 0xed0
fs.erase_blk: 0xee0
fs.erase_blk: 0xef0
fs.erase_blk: 0xf00
fs.erase_blk: 0xf10
fs.erase_blk: 0xf20
fs.erase_blk: 0xf30
fs.erase_blk: 0xf40
fs.erase_blk: 0xf50
fs.erase_blk: 0xf60
fs.erase_blk: 0xf70
fs.erase_blk: 0xf80
fs.erase_blk: 0xf90
fs.erase_blk: 0xfa0
fs.erase_blk: 0xfb0
fs.erase_blk: 0xfc0
fs.erase_blk: 0xfd0
fs.erase_blk: 0xfe0
fs.erase_sec: 0xff0
fs.erase_sec: 0xff1
fs.erase_sec: 0xff2
fs.erase_sec: 0xff3
fs.erase_sec: 0xff4
fs.erase_sec: 0xff5
fs.erase_sec: 0xff6
fs.erase_sec: 0xff7
fs.erase_sec: 0xff8
fs.erase_sec: 0xff9
fs.erase_sec: 0xffa
fs.erase_sec: 0xffb
fs.erase_sec: 0xffc
fs.erase_sec: 0xffd
fs.erase_sec: 0xffe
fs.erase_sec: 0xfff
fs.start: 0x00080000, size: 16252928
mount res: 0
format done.
>
total: 14932241, used:0
Total : 14932241 bytes
Used  : 0 bytes
Remain: 14932241 bytes

Смысл: fs.start: 0x00080000, size: 16252928
А info пишет:
total: 14932241, used:0
Total : 14932241 bytes
Used : 0 bytes
Remain: 14932241 bytes
Куда оно сожрало 16252928-14932241=1320687 байт?
Или так:

----------------------------
init.lc         : 296 bytes
init.lua        : 123 bytes
script4.lc      : 260 bytes
script4.lua     : 131 bytes
----------------------------
Total file(s)   : 4
Total size      : 810 bytes

Total : 14932241 bytes
Used  : 2510 bytes
Remain: 14929731 bytes

 

[pvvx]

Пока добавил новую команду file.fsstat(). Показывает разметку spiffs.

Спойлер: log

----------------------------
init.lc         : 296 bytes
init.lua        : 123 bytes
script4.lc      : 260 bytes
script4.lua     : 131 bytes
----------------------------
Total file(s)   : 4
Total size      : 810 bytes

Total : 71786 bytes
Used  : 2510 bytes
Remain: 69276 bytes

> file.fsstat()
   0 idid/ddi/ddi___    era_cnt: N/A
   1 _______________    era_cnt: N/A
   2 _______________    era_cnt: N/A
   3 _______________    era_cnt: N/A
   4 _______________    era_cnt: N/A
   5 _______________    era_cnt: N/A
   6 _______________    era_cnt: N/A
   7 _______________    era_cnt: N/A
   8 _______________    era_cnt: N/A
   9 _______________    era_cnt: N/A
  10 _______________    era_cnt: N/A
  11 _______________    era_cnt: N/A
  12 _______________    era_cnt: N/A
  13 _______________    era_cnt: N/A
  14 _______________    era_cnt: N/A
  15 _______________    era_cnt: N/A
  16 _______________    era_cnt: N/A
  17 _______________    era_cnt: N/A
  18 _______________    era_cnt: N/A
  19 _______________    era_cnt: N/A
  20 _______________    era_cnt: N/A
phys_addr:   0x00067000
phys_size:   86016
era_cnt_max: 1
last_errno:  -10072
blocks:      21
free_blocks: 20
page_alloc:  10
page_delet:  2
used:        2510 of 71786
>

Вывод сообщений об ошибках исправил... Перерождение NodeMCU в EspLua.ru продолжается

 

[Tomahawk]

collectgarbage() там не понять как работает, в теории он должен освобождать память от мусора, но на деле если мы проследим за Heap, то увидим, что он память только съедает. Надёжнее просто обнулять переменные и функции через nil, тогда сразу и гарантированно освободим.

 

[Tomahawk]

Как только добавляю в код событие сокета connn("disconnection", function(conn, msg) print("Disconnect") end) начинаются проблемы, событие Sent по 2 раза срабатывает, а оттуда и до Panic недалеко. А без этой строчки Heap стабилен вплоть до байта.

 

[pvvx]

Tomahawk - работа над кривизной NodeMCU только начата. Пока на стадии осмотра что там и как и куда закинуть. Надо определиться что там "самое главное" и что второстепенное. Потом выбрать, что переносить в буфера IRAM. На этой стадии пока дело стоит - нет времени проанализировать всё и сразу (лето-дети-дача-строительство-...) Но картинка уже формируется.

Как только добавляю в код событие сокета connn("disconnection", function(conn, msg) print("Disconnect") end) начинаются проблемы, событие Sent по 2 раза срабатывает, а оттуда и до Panic недалеко. А без этой строчки Heap стабилен вплоть до байта.

Все обращения к TCP с версии SDK 0.9.5 сменились. В указанном примере идет потеря памяти от двух несовместимостей с новыми SDK... Это тоже модуль "писателя" NodeMCU Потом исправлю - счас главное стабальность ядра и перераспределить память.

 

[Vladimir555]

Привет pvvx,
Тестировал EspLua.ru 1.1.2
file.format() работает быстрее!?.
Total : 14932241 bytes
После отключения модулей, оставил первые 5 модулей +TMR+UART.
EspLua.ru 1.1.2 build 20150627
> =node.heap()
22528
NodeMCU 0.9.5 build 20150318
> =node.heap()
24712
Мои проекты с NodeMCU не запустились, сразу рестарт (мало памяти) .
Пока глубоко не разбирался.
Еще бы добавить команду dofileFlash("script1.lua")
не загружать все в RAM, а читать построчно из файла Flash.
Будет работать медленнее, но ограничение размера кода исчезнут.
или ждать обещанный чип с RAM 200кб.

 

[Vladimir555]

nikolz,

А вот сборка без выкрутасов:
NodeMCU 1.1.2 build 20150630 powered by Lua 5.1.4

Где скачать не подскажите?

 

[Vladimir555]

Привет nikolz,
Поставил.
NodeMCU 0.9.6 build 20150627 powered by Lua 5.1.4
=node.heap()
35296 - это хорошо.

 

[pvvx]

После отключения модулей, оставил первые 5 модулей +TMR+UART.
EspLua.ru 1.1.2 build 20150627
> =node.heap()
22528

Я измеряю со всеми какие только есть модули, + float, включена STATION и т.д. Ничего не отключено + на несколько команд больше в последней версии чем у NodeMCU 0.9.6
wifi.sta.rssi() работает... В NodeMCU 0.9.6 [HASHTAG]#define[/HASHTAG] LUAL_BUFFERSIZE 1024, а у меня пока 4096...
Ещё в NodeMCU 0.9.6 практически каждый байт сообщений, перенесенный в Flash, читается с помощью прерывания по ошибке, т.е. для считывания байта уходит более нескольких сотен команд CPU + время "кеширования" Flash (чтения в память блока из flash в спец память)

Еще бы добавить команду dofileFlash("script1.lua")
не загружать все в RAM, а читать построчно из файла Flash.
Будет работать медленнее, но ограничение размера кода исчезнут.
или ждать обещанный чип с RAM 200кб.

Не дождетесь - это пока выдумки... Надо перекидывать что-то в IRAM буфер. Его можно организовать до 32 кило из 48.
Основная беда падений - большой стек и WDT при 9600 Baud. Сообщения вылезают дольше, чем период WDT (1.6 сек).

 

[Tomahawk]

А зачем в принципе общаться с модулем на 9600? Такая скорость нужна лишь на большой линии, чтобы помехи не сильно сказывались, а мы отлаживаем модули на столе, тут и на 115200 работать будет. Например, в стандарте Modbus скорость по умолчанию 19200, а ведь он часто используется в промышленном применении и ничего работает же как-то. А здесь условия стерильные и 9600 по умолчанию везде ставят
*Так что я за скорость 115200 по умолчанию, прошивают модуль первоначально всё равно на столе. Даже если он потом будет работать в сложных условиях, кому надо через uart.setup(0, 9600, 8, 0, 1, 0) обратно поменяет. pvvx, осталось только добавить, чтобы через команду uart.setup... скорость сохранялась в ПЗУ, сейчас же после сброса питания возвращается на 9600.

 

[pvvx]

скорость сохранялась в ПЗУ, сейчас же после сброса питания возвращается на 9600.

Попробую сделать. Но ныне всё застряло на ошибке esptool.py в зловещей строке 666. Выложить ничего не могу, но уже heap за 30 килобайт - данные из IRAM, если запрос не align(4), читаются через примочку на прерывании через "протектед". У новой NodeMCU так читаются данные из Flash, но "кеширование" Flash при чтении и записи, к примеру диска, отключается и у них каюк - зависон и т.д... Пусть думают как исправлять SDK 0.9.6(b1) .

 

[Vladimir555]

в NodeMCU первое что сделал по умолчанию 230400/921600 удобнее,
надоело после каждого сброса выставлять.
\app\user\user_main.с

/******************************************************************************
* FunctionName : user_init
* Description  : entry of user application, init user function here
* Parameters   : none
* Returns      : none
*******************************************************************************/
    // NODE_DBG("SDK version:%s\n", system_get_sdk_version());
    // system_print_meminfo();
    // os_printf("Heap size::%d.\n",system_get_free_heap_size());
    // os_delay_us(50*1000);   // delay 50ms before init uart

#ifdef DEVELOP_VERSION
    uart_init(BIT_RATE_74880, BIT_RATE_74880);
#else
    uart_init(BIT_RATE_230400, BIT_RATE_230400);
    //uart_init(BIT_RATE_921600, BIT_RATE_921600);
#endif
    // uart_init(BIT_RATE_115200, BIT_RATE_115200);
   
    #ifndef NODE_DEBUG
    system_set_os_print(0);
    #endif
    system_init_done_cb(nodemcu_init);
}

ну и модули лишние по выключал,
а вот свой майк файл, для новой версии, делать еще не научился

 

[pvvx]

В новой версии nodeMCU от 27.06.2015 все константы из RAM переброшены во флеш и таким образом освободили память.
у меня эта сборка собирается , но после загрузки в ESP горит синий диод и на уарте мусор.

Там неверная реализация на основе аппаратного прерывания процессора при неверном обращении к памяти - с неверным не кратным смещением или при обращении к слову менее чем позволяет оборудование (шины). Flash и IRAM по 4 байта align(4), а большинство процедур в SDK обращаются к своим данным побайтно. Как итог происходит прерывание CPU по ошибке и встроена процедура обрабатывающая такое событие. Код у неё длинный и тормозной, т.к. не расcчитно это всё для таких дел. Но главное это прерывание быстро не замаскировать, а когда читается или пишется Flash, то "кэш" Flash отключается и доступа к данным нет. В этот момент код SDK работает и требует чтения своих перенесенных данных в Flash (а она отключена)... Китайцы - что тут сказать. Работать этот метод может, если все данные перенести в IRAM, а не в Flash. Она никогда не отключается. Но остаются время-зависимые процедуры. Скорость чтения данных стандартными процедурами через прерывание "протектед" достаточно низкая. Но для Lua - это всё безразлично - ну ещё скорость обработки упала в пару раз... Всё равно 9600 бод...
А чтобы разместить все данные в IRAM её стандартных 32 кило не хватает. При увеличении до 48 - всё Ok с данным методом, но требуются другие изменения. Недавно запилил несколько дополнений для возможности использовать 48к IRAM в EspLua и включил этот "протектед".
Но ещё не всё гладко и очень многое надо переделывать для нормальной поддержки самого интерпретатора Lua. Особенно системного, т.к. прошлые портировщики вообще этому не уделяли никакого времени и значения.

Начальная загрузка ROM-BIOS 48 кило IRAM тоже дало увеличение времени до старта.
Сделал предварительную версию одноблочного "rapid_loader.bin" - грузиться всего 172 байта на низкой скорости (как грузит ROM-BIOS):

ets Jan  8 2013,rst cause:1, boot mode:(3,6)

load 0x40100000, len 172, room 16
tail 12
chksum 0x00
csum 0x00

Далее этот загрузчик включает 80 MHz QSPI и "кэш" для доступа к Flash и разгребает - раскидывает остальные коды стандартной загрузки (~50 килобайт из flash). С ним ещё есть некоторые полезные завязки, но пока "сикрет" . Память, кроме 192 байт в flash он не потребляет, а увеличивает (выставляет) стек процессора по максимуму на начало (0x40000000), в отличии от ROM-BIOS.
С ним уже грузиться быстрее. После тестов отключу и эти сообщения о загрузке ROM-BIOS на низкой скорости UART и загрузка от включения питания модуля до старта пользовательского кода станет 30..35 ms...
Этот загрузчик ставиться в любую версию кода/проектов на SDK путем копирования в начало бинарника первой половины прошивки. Написан на СИ и не оптимизирован На чистом ASM можно уменьшить ещё на треть

 

[Vladimir555]

у меня эта сборка собирается , но после загрузки в ESP горит синий диод и на уарте мусор.

У меня похожее было не раз при загрузке разных прошивок, нужно почистить полностью всю flash.
Странно, но сразу помогает.

 

[windalser]

https://cesanta.com/blog/esp8266_vs_stack.shtml
https://cesanta.com/blog/esp8266_using_flash.shtml
Здесь описаны несколько экспериментов по переполнению стека esp8266 , также про выравнивание при обращении к Flash.
Похоже, они решают близкую задачу - портирование виртуальной машины V7 - java script на esp8266 и сталкиваются с подобными проблемами.

 

[pvvx]

https://cesanta.com/blog/esp8266_vs_stack.shtml
https://cesanta.com/blog/esp8266_using_flash.shtml
Здесь описаны несколько экспериментов по переполнению стека esp8266 , также про выравнивание при обращении к Flash.
Похоже, они решают близкую задачу - портирование виртуальной машины V7 - java script на esp8266 и сталкиваются с подобными проблемами.

Глубина стека указана в первых кодах старта в ROM-BIOS. Минимальный адрес = 0x3FFFEB30. Там находится одноразовая таблица загрузки спец.регистров CPU используемая только при страте. Ниже идет буфер aes_data.
Начало стека в 0x40000000. Итого, что можно задействовать : 0x40000000-0x3FFFEB30=0x14D0 (5328 байт)
В NodeMCU стек опускается ниже 0x3FFFDF00 и используются запросы gpio_init(), gpio_intr_pending(),... (все процедуры gpio_???) а они используют переменные, расположенные в 0x3FFFDFE0..3FFFDFF0 (т.е. это уже совсем критически). Выше идет буфер sip_ptr (0x3FFFDFF0), sip_task и т.д. А ниже - буфер UartDev.TrxBuff и UartDev.RcvMsgBuff.
NodeMCU иногда попадает стеком и в приемный буфер UART
Можно вообще не задействовать процедуры ROM-BIOS и тогда повляется возможность использовать всю её память 0x3fffc000..0x40000000. Такая попытка предпринята в ESP-RTOS. Но не совсем удачно и до конца. Перенесена часть таблиц прерываний, но не все переменные процедур WiFi и т.д. На этом ESP-RTOS и заброшена ....
Указанные в ссылках размеры стека и прочее - устарело и относятся к старым ld файлам, когда стек размешался в памяти, отъедая от общей доступной памяти или был описан в ld файле. В текущих ld используется стек от ROM-BIOS по умолчанию, в её малой области памяти.
Пример пожирания памяти стека в Lua неимоверными кусками:
https://github.com/nodemcu/nodemcu-firmware/blob/master/app/lua/liolib.c#L344
Структура luaL_Buffer имеет в себе буфер в 4 килобайта!
#define LUAL_BUFFERSIZE ((BUFSIZ)*4)
#define BUFSIZ 1024

PS: C EspLua я пока пытаюсь решить, как сделать две задачи - Lua и всё остальное. Иначе это работать не будет - происходит падение по WDT или останов обслуживания WiFi. Однозадачка для Lua никак не катит. Только после этого можно будет начинать что-то корректировать с самим интерпретатором Lua.

 

[igrr]

PS: C EspLua я пока пытаюсь решить, как сделать две задачи - Lua и всё остальное. Иначе это работать не будет - происходит падение по WDT или останов обслуживания WiFi. Однозадачка для Lua никак не катит. Только после этого можно будет начинать что-то корректировать с самим интерпретатором Lua.

Переключение контекстов уже давно сделано — странно что в NodeMCU его до сих пор не прикрутили (всего-то два файла добавить).
Например, в "ардурине", как Вы любите выражаться, все функции с блокирующим поведением переключают контекст на системный, и возврат в контекст скетча происходит по таймеру/коллбэку/событию. В lua вполне подойдет такая модель.

 

[Vladimir555]

Привет, pvvx
залил bin файлы из
"EspLua.ru 1.1.2"
"build 20150702"
Постоянно горит синий светодиод, поток на UART:

0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x40200064, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):

что не правильно делаю?