Результаты поиска

Всё можно, но реальной аппаратной беды с WDT у ESP8266 нет. Она только 'софтовская' = китайский SDK. В последних версиях WDT 'усилили', но беда в перезапуске из SDK через ROM-BIOS осталась (китай-код обработки WDT).

ТТХ изначально хуже ESP8266. Очередная реклама, без реальности.

Опять по кругу. :( Из моей прошивки у вас не исполняется ни одного байта. В вашем модуле ROM-BIOS просто не грузит её вообще, а грузит что-то своё. В итоге ничего не переключается и ничего не запускается. Тогда у всех будет работать, кроме вашего модуля.

Уже объяснил - нет контакта у чипа или кривые внешние цепи. Только китайцы выводят шины на 80MHz на выходы кое-как. По тому модули ESP-12E и прочие не беру - они жрут много из-за доп.нагрузки на линии QSPI. Коротить выходы - это зачем? Чтобы подпалить логику выходов I/O чипа? Вот оно у вас и...

Та нифига. Всё наоборот. У всех разные методы популяризации ESP8266 и не всем дозволен мой, тем более я не программист :p И ничего ROM-BIOS не проверяет, кроме ляпов китайцев. Те два транзистора в их модуле = кривизна, т.к. туда выводится 26 или 40 MHz в зависимости от кварца... А фронты у...

Сигма-дельта - это из-за отсутствия любого внешнего DAC, чтобы собрать используя только модуль ESP8266 и больше ничего :) Это не я. Это "подарок" китайцев в виде публикации регистров управления I2S. Да и основа проекта тоже не моя. Я всего добавил буфер в IRAM, пожертвовав частью "кэш" flash...

Да. Они ограничены реальными сформированными стандартами. Ошибки не в счет - это ошибки и они есть везде и всегда. PS по поводу "тамогочи": т.к. она не запускает ни одного байта из представленных программ и не верно считывает блок лоадера из flash, то это означает, что неверно работает ROM-BIOS...

С полумерами идите с просьбами к китайцам или к nikolz, можно и к Ардуинщикам :) Должно или работать, или отсутствовать (быть недописано или оставлено на пользователя). У меня такой подход :) Промежуточных вариантов типа "как-то при каких-то условиях работает" быть не должно.

Основа FS не в интерфейсе, а в том, что у нас сектора по 4 килобайта (минимальная стираемая область) и в том, что используемые на ESP8266 flash позволяют дозапись в сектор, а не как у других типов - запись только целого сектора. Это и задает основы построения FS с учетом кол-ва перезаписей...

Всё это не годиться для используемой Flash (большие накланые расходы или нет записи или не журналируемая система, или очередной тормоз, или ...). Ардунио идет своим путем и скоро закончит как NodeMCU.

Скинул что есть на последний момент тестов. Скорость стоит по умолчанию 115200. Базовый Lau можно более менее нормально портировать на ESP8266. Но извращение созданное ради рекламы = NodeMCU - неизлечимо.

Нечего там смотреть - допишет до определенного места и встанет навсегда. Далее будет всегда вываливаться, пока не форматнете диск. Причины уже описаны. Чтобы сделать что-то нормальное требуется много времени, т.к. надо переписывать всё с нуля. На этой стадии и сижу - ищу варианты нормальной...

Для @nikolz про память 'heap' и его ор, что в СИ ничего не сделать: Вот лог старта Web сервера в SDK 1.2.0 без всяких "примочек" типа чтения по протектед памяти: Simple WEB version: 0.1.3 OpenLoaderSDK v1.2 Found free IRAM: base: 0x40104c90, size: 29552 bytes System memory: data : 0x3ffe8000 ~...

Такого не наблюдается. Сколько раз не включай, после перепрошивки, всегда AP с именем "ESP8266" активна, пока не смените в WEB. Возможно вы неправильно выставляете параметры при записи проектов во flash. В "Web свалке" всегда при записи выставляется размер flash 512 килобайт, вне зависимости от...

Я ещё не выкладывал версии с подправленным spiffs. Так что тесты на кривом spiffs бесполезны. Там всегда, если диск имеет более 40 сегментов возникает ошибка в его кэш... Для просмотра что творится в разметке диске и была сделана команда file.fsstat().

Ндас... spiffffsss.... https://github.com/pellepl/spiffs/blob/master/src/spiffs_gc.c#L254 Назначается адрес для dword (s32_t *cand_scores) из байтного (fs->work) + число умноженое на 2 (sizeof(spiffs_block_ix)). Как итог в строке...

Ну вот WDT и сбросился. В прерывании WDT SDK стоит перезапуск и в конце на вектор reset. NodeMCU однозадачна и не дает SDK работать, от этого там вечный WDT и отваливание WiFi... Достаточно написать tmr.delay(10000000) и WiFi кончиться с вылетом потом.

Система SDK. У меня работает одновременно SDK и Lua. Иначе, как в NodeMCU, будет постоянно рваться связь и отваливаться WiFi. Там всё ещё хуже в spiffs. Конца записи нет - файл пишется по кругу, обнаружить конец объема диска Lua не может. Очень долгий перебор всех секторов для записи следующего...

Неа - не пора. Lua + spiffs = тормоз. Ввод строк на 16Mbуtes flash идет через 2 и более секунд, а ESPLorer не имеет таких задержек. Набивка и загрузка программ только вручную в терминале :) Если ещё запишите часть диска в 16Mbуtes flash, то последующие вводы строк и открытия файлов будут длиться...

А здесь другая сборка, на SDK 1.2.0, а не глючной полугодичной бэте 0.9.6 :)