Что то не могу понять.
...
Значит ли это что функция dns_gethostbyname вернёт статус немедленно и без колбека её нужно вызвать ещё раз, пока не вернётся ERR_OK?
Не разбирался я с имеющимся dns пока. Ничего сказать не могу и высказал предположение, которое надо проверить, чтобы избежать ошибок в дальнейшем.
Dns то китайcкий, от Espressif... в последних "свалках" используется их покоцанная либа liblwip.a
Начальный в workspace\Web_Base4\app\lwip\core\dns.c
Там всё ок.
dns_gethostbyname(found) -> dns_enqueue(found) ->...
lwipopts.h: /** DNS maximum number of entries to maintain locally. */
[HASHTAG]#define[/HASHTAG] DNS_TABLE_SIZE 4
Т.е. предел 4 одновременных запроса.
----
Причина использования покоцанной либы liblwip.a - она дает меньше используемой RAM, чем трансляция исходников Lwip. Но есть различия в размере занимаемой IRAM. Сколько занимает в flash - это безразлично - там места много. С этим и надо доразобраться и почистить исходники Lwip.
Найденные различия указал в Web_Base4\app\lwip\iram.txt
Ещё IRAM выжимается в Web_Base4\app\lwip\core\timers.c - там китайцы забыли у static поставить ICACHE_FLASH_ATTR, т.к. ставили атрибуты в include\lwip\timers.h и к static они не пошли...
Но главное - надо что-то выкинуть в исходниках, т.к. лишнее и жрет память. При этом трогать lwipopts.h нельзя - будет несовместим с китай-SDK
И выход тут один - дореверсить SDK минимум до WiFi процедур. Это и есть главная задача "свалки" - всё остальное = второстепенно.
Такие вещи как websocket - это вообще "десятый" вопрос
Вот один из примеров первостепенных вопросов:
В текущей "свалке" вроде ошибка с установкой скорости SPI для Flash. В ROM-BIOS есть полная замена void sflash_something(uint32 mode) и надо заменить его на процедуру в ROM-BIOS:
Код:
#include "c_types.h"
#include "esp8266.h"
/*
ROM:40004644 spi_flash_attach:
ROM:40004644 addi a1, a1, 0xF0
ROM:40004647 s32i.n a0, a1, 0
ROM:40004649 call0 SelectSpiFunction
ROM:4000464C movi.n a2, 5
ROM:4000464E movi.n a3, 4
ROM:40004650 call0 SPIFlashCnfig
ROM:40004653 movi.n a2, 5
ROM:40004655 call0 SPIReadModeCnfig
ROM:40004658 l32i.n a0, a1, 0
ROM:4000465A addi a1, a1, 0x10
ROM:4000465D ret.n
*/
void SPIFlashCnfig(uint32_t parm1, uint32_t parm2)
{
uint32 a6 = 0;
uint32 a2;
HWREG(SPI0_BASE,0x1C) |= 4;
if(parm1 == 0) a6 = 0x1000000; // SPI_QIO_MODE
else if(parm1 == 1) a6 = 0x100000; // SPI_QOUT_MODE
else if(parm1 == 2) a6 = 0x800000; // SPI_DIO_MODE
else if(parm1 == 3) a6 = 0x4000; // SPI_DOUT_MODE
else if(parm1 == 4) a6 = 0x2000; // SPI_FASTRD_MODE
if(parm2 < 2) {
a2 = 0x100;
HWREG(SPI0_BASE,0x08) |= 0x1000; // ???
HWREG(IOMUX_BASE,0) |= a2;
}
else {
a2 = (((parm2 - 1) << 8) + parm2 + (((parm2 >> 1) - 1) << 4) - 1);
HWREG(SPI0_BASE,0x08) &= 0xFFFFEFFF;
HWREG(IOMUX_BASE,0) &= 0xEFF;
}
a2 |= a6;
a2 |= 0x288000; // SPI_RESANDRES | SPI_SHARE_BUS | SPI_WP_REG
HWREG(SPI0_BASE,0x08) |= a2;
HWREG(SPI0_BASE,0) = 0x100000;
while(HWREG(SPI0_BASE,0) != 0);
}
скорректировав параметры. Таким образом уменьшается задействованная IRAM...
Ну и подобные... т.к. есть желание перейти к оверлеям в IRAM, а для этого её надо высвободить по макс.
Например код первого "загрузчика" с инициализацией либов вообще переноситься в область оверлеев, а по исполнению освобождается, т.к. он больше не нужен.
И эти задачи требуют переписывания всех include, чтобы избавиться от навязанного Espressif бардака с ними. Описания ROM-BIOS отдельно от либов SDK и т.д.
В итоге задача "мало памяти" переходи в задачу "мало времени"
А на и так
редко задаваемые вопросы никто и никогда не отвечает.
