• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Тестирование и модификация RTL SDK для автономных устройств.

pvvx

Активный участник сообщества
О медлительности старта в SDK3.5 уже описывал: Скорость подключения модуля к внешней AP

Тут будем пробовать 'модифицировать' SDK3.5 для ускорения старта и потребления для автономных устройств. Но это позже. Сейчас рассмотрим то, что позволяет последний на сегодня SDK 3.5.

Для примера RTL00 из режима deep_sleep по изменению уровня на PA_5 будет соединяться с AP на ESP8266, а ESP8266 в это время анализирует питание RTL00. Сразу после соединения и получения IP модуль RTL00 производит тестовый запрос и чтение основной страницы HTTP-Web-сервера на ESP8266 и далее отключается - переходит в режим deep_sleep.

Часть кода, для информации что примерно будем исследовать:
Код:
#define SOCKET_STACK_SIZE 250
#define SOCKET_PRIORITY tskIDLE_PRIORITY + 7 + PRIORITIE_OFFSET
extern struct netif xnetif[NET_IF_NUM];
#define rmt_port 80   
#define rmt_ip (xnetif[0].gw.addr) // 0x0104A8C0 = 192.168.4.1

char fbuf[512];
int fbuf_cnt;
gpio_t gpio_obj;

// чтение и пропуск HTTP заголовка
int http_head_read(unsigned char *buf, int len, int ff) {
int flg_head = 0;
int n, ret = 0;
fbuf_cnt = 0;
if ((n = read(ff, buf, len)) <= 0) return 0;
if(n > 11 && *((u32 *)buf) == 0x50545448) { // "HTTP" // HTTP/1.0 200 OK
int x;
for(x = 3; x < n && buf[x] != ' '; x++);
while(x < n && buf[x] == ' ') x++;
if(x < n) ret = atoi(&buf[x]);
int cnt = 0;
x = 0;
while(ret) {
int z = 0;
while (x < n) {
if (cnt++ > 16384) return 600; // Header Too Large
if (buf[x++] == ((flg_head & 1) ? 0x0a : 0x0d)) {
if ((flg_head & 3) == 1) {
#if DEBUG_MAIN_LEVEL > 0
buf[x-1] = 0;
DBG_8195A("%s\n", &buf[z]);
#endif
z = x;
}
if (flg_head >= 3) {
if (n - x > 0) {
fbuf_cnt = n - x;
rtl_memcpy(&fbuf, &buf[x], fbuf_cnt);
}
#if DEBUG_MAIN_LEVEL > 1
DBG_8195A("TST: Skip HTTP head in %d bytes\n\n", cnt);
#endif
return ret;
}
flg_head++;
}
else flg_head = 0;
}
x = 0;
while(z < n) buf[x++] = buf[z++];
if ((n = read(ff, &buf[x], len - x)) <= 0) return 601; // content ??
n += x;
};
}
fbuf_cnt = n;
return ret;
}
// Тестовый socked
void test_socked(void)
{
struct sockaddr_in remote_ip;
int sock = socket(PF_INET, SOCK_STREAM, 0);
if (sock == -1) {
#if DEBUG_MAIN_LEVEL > 0
DBG_8195A("TST: Not open socket!\n");
#endif
vTaskDelete(NULL);
return;
}
rtl_memset(&remote_ip, 0, sizeof(remote_ip));
remote_ip.sin_family = AF_INET;
remote_ip.sin_addr.s_addr = rmt_ip;
remote_ip.sin_port = htons(rmt_port);
DiagPrintf("\nSocked connect at start %d ms.\n", xTaskGetTickCount());
if (connect(sock, (struct sockaddr * )(&remote_ip), sizeof(struct sockaddr)) != 00) {
close(sock);
#if DEBUG_MAIN_LEVEL > 0
DBG_8195A("TST: Connect error!\n");
#endif
vTaskDelete(NULL);
return;
}
sprintf(&fbuf,"GET / HTTP/1.0/\r\nTime at start %d ms.\r\n\r\n", xTaskGetTickCount());
int x = strlen(&fbuf);
write(sock, &fbuf, x);
if ((x = http_head_read(fbuf, sizeof(fbuf), sock)) != 200) {
#if DEBUG_MAIN_LEVEL > 0
DBG_8195A("TST: HTTP error %d\n", x);
#endif
}
close(sock);
DiagPrintf("\nSocked close at start %d ms.\n", xTaskGetTickCount());
wifi_off();
DiagPrintf("\nDeep-sleep at start %d ms.\n", xTaskGetTickCount());
sys_log_uart_off();  // turn off log uart
HalPinCtrlRtl8195A(JTAG, 0, 0); // turn off JTAG
// Enter deep_sleep, wakeap:  PA_5
gpio_init(&gpio_obj, PA_5);
gpio_dir(&gpio_obj, PIN_INPUT);
gpio_mode(&gpio_obj, PullUp);
standby_wakeup_event_add(STANDBY_WAKEUP_BY_PA5, 0, gpio_read(&gpio_obj)? 0 :  1); deepstandby_ex();
vTaskDelete(NULL);
}

// Connect_start() вызывается при подключении WiFi к внешней AP и получении IP (встроил в свой SDK).
void connect_start(void)
{
#if DEBUG_MAIN_LEVEL > 0
DiagPrintf("\nConnected at start %d ms.\n", xTaskGetTickCount());
#endif
if (pdTRUE != xTaskCreate( test_socked, (const signed char * const)"socked", SOCKET_STACK_SIZE, NULL, SOCKET_PRIORITY, NULL))
DiagPrintf("Create Log UART Task Err!\n");
}
Main() запускает соединение WiFi по записанным ранее в Flash установкам.
Дополнительно в код включена поддержка нескольких отладочных AT команд.
В итоге, в резерве, в RTL00 остается около 200 килобайт неиспользованной RAM (пик во время открытого socked).
Код:
#interface 1 is initialized
interface 0 is initialized
Initializing WIFI ...
Start LOG SERVICE MODE
# WiFi Init after 299ms
Joining BSS by SSID ESP8266...
RTL8195A[Driver]: set ssid [ESP8266]
RTL8195A[Driver]: start auth to 1a:fe:34:99:ad:1d
RTL8195A[Driver]: auth success, start assoc
RTL8195A[Driver]: association success(res=2)
WiFi connected at start 1591ms
Connected after 1294ms
Interface 0 IP address : 192.168.4.3
Got IP after 1810ms
Connected at start 2121 ms.
Socked connect at start 2129 ms.
WIFI initialized
HTTP/1.1 200 OK
Server: PVs/0.1
Connection: close
Access-Control-Allow-Origin: *
Content-Type: text/html
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Socked close at start 2213 ms.
LwIP_DHCP: dhcp stop.
Deinitializing WIFI ...
[rltk_wlan_deinit] Wait for TX/RX Busy (1)WIFI deinitialized
Deep-sleep at start 3351 ms.

По питанию это выглядит так:
tst_start_1.gif
(1 клетка = 1 секунда, 0.58 mA - аппаратная ошибка модуля)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Как видим, похоже, что в SDK3.5 WiFi для соединения сканирует все каналы (начальная пила по питанию), а потом уже подключается. Зачем сиё действо - неизвестно - канал, куда подключаться WiFi, указан в переданных ей настройках для соединения... Так-же очень наворочены задержки отключения в wifi_off().
При смене тика RTOS эти задержки изменяются - это говорит о том, что их встроили просто так (безответственность писателей SDK!) :) Частично я уже изменил кванты некоторых опросов состояний WiFi с 1 секунды(!) на 20 ms в открытом коде SDK, но есть ещё закрытые... К примеру, инициализация или ожидание соединения WiFi опрашивается 20 секунд с интервалом 1 сек :eek:... SDK 3.5 рассчитано на 166MHz CLK CPU (а модуль от PADI стартует c reset на 83MHz :) ) но есть ошибки, описанные в Таймеры RTL8711. За счет этого при смене частоты CLK CPU тик RTOS меняется и всякие vTaskDelay() ведут себя не корректно, а приложение об этом не знает :), меняется даже пауза beacon :)...
В таком виде текущее официальное SDK пока не может позиционироваться для использования в автономных устройствах. Требуются множественные "патчи". У кого какие предложения?
 
Последнее редактирование:

pvvx

Активный участник сообщества
Ещё одна 'беда', если устройство просыпается через срок менее 120 секунд (TCP TIME_WAIT) и пытается открывать один и тот-же IP: PORT на внешнем сервере используя TCP, а закрывает соединение сервер или связь модуля была прервана путем отключения WiFi (например батарейка садится и модуль принял решение 'уснуть').
Когда модуль стартует, то у него число random в текущем SDK всегда одинаково - начинается с фиксированной последовательности. По этому номеру LwIP открывает порт для связи - см. tcp_new_port() и
Код:
void tcp_init(void)
{
#if LWIP_RANDOMIZE_INITIAL_LOCAL_PORTS && defined(LWIP_RAND)
  tcp_port = TCP_ENSURE_LOCAL_PORT_RANGE(LWIP_RAND());
#endif /* LWIP_RANDOMIZE_INITIAL_LOCAL_PORTS && defined(LWIP_RAND) */
}
А внешний сервер не может открыть опять то-же самое соединение из-за TCP TIME_WAIT или если оно ещё не закрыто - Итог: проснувшийся модуль ждет таймаута и жрет батарейку :)
Т.е. SDK требует исправления в Rand() или rand() (что назначено LwIP-у в #define LWIP_RAND()).
На RTL8710 есть где взять случайное число при старте для инициализации процедур rand()!
 

pvvx

Активный участник сообщества
Применение "хака" в виде изменения в четыре раза переменной SystemCoreClock:
tst_start_2.gif
(шаг клетки 0.5 сек)
Итог: ускорение всего процесса от старта до нового deep_sleep в 4-ре раза. При норме (SystemCoreClock=166666666) время всего процесса просыпания с приемом = 5 сек, при изменении в 4-ре раза SystemCoreClock - время процесса = 1.25 сек. А это уже приемлемо, но всё равно там лишние 'сканы' WiFi перед подключением...
Куда копать пока четко не ясно...
SystemCoreClock в SDK устанавливает эта процедура:
Код:
void SystemCoreClockUpdate (void)            /* Get Core Clock Frequency      */
{
    SystemCoreClock = SystemGetCpuClk();
}
Её вызов происходит в закрытой части либы при старте InfraStart(), до исполнения main():
Код:
//----- InfraStart
void __attribute__((section(".infra.ram.start"))) InfraStart(void) {
    NewVectorTable[2] = HalNMIHandler_Patch;
    HAL_SYS_CTRL_WRITE32(REG_SYS_CLK_CTRL0,
            HAL_SYS_CTRL_READ32(REG_SYS_CLK_CTRL0) | BIT4);
    if (HalCommonInit() != HAL_OK) DBG_8195A("Hal Common Init Failed.\n");
    DBG_8195A("===== Enter Image 2 ====\n");
    ShowRamBuildInfo(); // app_start.c: VOID ShowRamBuildInfo(VOID)
    memset(&__bss_start__, 0, &__bss_end__ - &__bss_start__);
    int clk = (HAL_SYS_CTRL_READ32(REG_SYS_CLK_CTRL0)
            >> BIT_SHIFT_PESOC_OCP_CPU_CK_SEL) & 1;
    if (clk) {
        SpicNVMCalLoadAll();
        SpicReadIDRtl8195A();
    }
    SystemCoreClockUpdate();
    SYSPlatformInit();
    En32KCalibration();
    InitSoCPM();
    SDIO_Device_Off();
    VectorTableInitForOSRtl8195A(&vPortSVCHandler, &xPortPendSVHandler,
            &xPortSysTickHandler);
    if (clk) SpicDisableRtl8195A();
    _AppStart();
}
А если путь старта другой, то по умолчанию:
[inline]uint32_t SystemCoreClock = __SYSTEM_CLOCK; /*!< System Clock Frequency (Core Clock)*/[/inline]
Используется в FreeRTOSConfig.h:
[inline]#define configCPU_CLOCK_HZ ( SystemCoreClock )[/inline]
Но суть не в этом, а как и на что она влияет в WiFi?
 
Последнее редактирование:

nikolz

Well-known member
правильно ли я вас понял, что минимальное время затрачиваемое RTL на выхода из deep-sleep+связь с сервером +вход в deep-sleep составляет в исходниках 5 секунд, в вашем варианте 1.4 секунды?
Если так, то почему Вы утверждаете что это меньше, чем 0.34 секунды в ESP?
 

pvvx

Активный участник сообщества
правильно ли я вас понял, что минимальное время затрачиваемое RTL на выхода из deep-sleep+связь с сервером +вход в deep-sleep составляет в исходниках 5 секунд, в вашем варианте 1.4 секунды?
Если так, то почему Вы утверждаете что это меньше, чем 0.34 секунды в ESP?
Как всегда вы всё искажаете :) Ещё не надоела работать на рекламу Espressif? Меняйте работу.
У ESP в стандартном SDK время активности между deep_sleep при просыпании с подключением к AP, получением IP в DHCP, передачей и приемом с внешнего WEB сервера данных составляет более 2-х секунд, обычно за 3.

У RTL, при изменении всего одной переменной - 1.2 сек. Думаю, что починят SDK, т.к. имеющаяся - бета. На прошлой версии установка связи с внешней AP была значительно быстрее, но драйвер WiFi изменили - сменили структуру обращений к таймерам на семафоры с таймерами...

Время от старта до включения WiFi в стандартном варианте SDK3.5b у RTL составляет 300 ms.
У ESP - в зависимости от режима - при использовании ранее сохраненных настроек оно меньше, при калибровке - значительно больше. У RTL в SDK не вписано сохранение настроек - оставлено на усмотрение пользователя. Вы же сравниваете именно этот параметр :) А минимальные временные характеристики для ESP были получены и реализованы мной, в большей части в моем meSDK - вы их и приводите, не уточняя что и как. Время получения IP от роутера модулем ESP у меня составляет от 0.7 секунд до 1.5. Роутер - ASUS RT-N56U. Ошибка у ESP с засыпанием-просыпанием после deep_sleep в последних SDK ESP с учетом ранее сохраненных параметров так и не исправлена. Просыпание в его SDK идет по ветке старта после критической ошибки с полной калибровкой WiFi, т.к. ошибка в последней процедуре выхода в deep_sleep - процессор выскакивает в область отключенной flash и в зависимости что там он найдет летит на вектор "протектед" с записью этого состояния причины перезагрузки в RTC и другие регистры... т.е. как повезет - как будет читаться открытая шина :) Исправлено патчем либы только в meSDK.

Пока разбирал общий случай (аналог первого холодного включения модуля после прошивки) c не фиксированным IP в роутере и без прочих предустановках. Далее, после починки глупости с таймерами в SDK, предполагаю слепить специализированный вариант. Но чуть позже..

Различия SDK RTL и ESP глобальны – в SDK RTL любой может изменить практически всё что ему требуется, т.к. есть все исходники, кроме драйвера WiFi. Драйвер WiFi общается с остальной открытой системой через глобальную структуру, в которой вы можете изменить любые процедуры. В ESP эта часть и уровнем выше (сохранение и запись установок WiFi и т.д.) является закрытой частью в SDK, как и все процедуры включений и выключений разных режимов sleep.

По этому у RTL использую понятие – стандартный SDK – это если взять исходный SDK и ничего не менять, но он на такое не рассчитан, т.к. позволяет изменять любые используемые ресурсы под вашу задачу. Разницу прочувствовали? :)

PS: кароче это надоело - постоянно уточнять безграмотному рекламщику Espressif nikolz разницу подходов в SDK RTL и ESP. Уже неоднократно сказано - по 99% параметрам RTL-ы лучше ESP, а отличия давно разобраны.
Если вас действительно интересует уровень драйвера WiFi в RTL, то в SDK дан список команд в component/common/drivers/wlan/realtek/src/osdep/wireless.h
rtl00TstMinAmebaV35a/wireless.h at master · pvvx/rtl00TstMinAmebaV35a · GitHub
Но что-то мне подсказывает, что вы не полезете на такой уровень :) Это уже уровень для написания сканеров WiFi и он открыт в данном SDK.
 
Последнее редактирование:

nikolz

Well-known member
Как всегда вы всё искажаете :) Ещё не надоела работать на рекламу Espressif? Меняйте работу.
У ESP в стандартном SDK время активности между deep_sleep при просыпании с подключением к AP, получением IP в DHCP, передачей и приемом с внешнего WEB сервера данных составляет более 2-х секунд, обычно за 3.

У RTL, при изменении всего одной переменной - 1.2 сек. Думаю, что починят SDK, т.к. имеющаяся - бета. На прошлой версии установка связи с внешней AP была значительно быстрее, но драйвер WiFi изменили - сменили структуру обращений к таймерам на семафоры с таймерами...

Время от старта до включения WiFi в стандартном варианте SDK3.5b у RTL составляет 300 ms.
У ESP - в зависимости от режима - при использовании ранее сохраненных настроек оно меньше, при калибровке - значительно больше. У RTL в SDK не вписано сохранение настроек - оставлено на усмотрение пользователя. Вы же сравниваете именно этот параметр :) А минимальные временные характеристики для ESP были получены и реализованы мной, в большей части в моем meSDK - вы их и приводите, не уточняя что и как. Время получения IP от роутера модулем ESP у меня составляет от 0.7 секунд до 1.5. Роутер - ASUS RT-N56U. Ошибка у ESP с засыпанием-просыпанием после deep_sleep в последних SDK ESP с учетом ранее сохраненных параметров так и не исправлена. Просыпание в его SDK идет по ветке старта после критической ошибки с полной калибровкой WiFi, т.к. ошибка в последней процедуре выхода в deep_sleep - процессор выскакивает в область отключенной flash и в зависимости что там он найдет летит на вектор "протектед" с записью этого состояния причины перезагрузки в RTC и другие регистры... т.е. как повезет - как будет читаться открытая шина :) Исправлено патчем либы только в meSDK.

Пока разбирал общий случай (аналог первого холодного включения модуля после прошивки) c не фиксированным IP в роутере и без прочих предустановках. Далее, после починки глупости с таймерами в SDK, предполагаю слепить специализированный вариант. Но чуть позже..

Различия SDK RTL и ESP глобальны – в SDK RTL любой может изменить практически всё что ему требуется, т.к. есть все исходники, кроме драйвера WiFi. Драйвер WiFi общается с остальной открытой системой через глобальную структуру, в которой вы можете изменить любые процедуры. В ESP эта часть и уровнем выше (сохранение и запись установок WiFi и т.д.) является закрытой частью в SDK, как и все процедуры включений и выключений разных режимов sleep.

По этому у RTL использую понятие – стандартный SDK – это если взять исходный SDK и ничего не менять, но он на такое не рассчитан, т.к. позволяет изменять любые используемые ресурсы под вашу задачу. Разницу прочувствовали? :)

PS: кароче это надоело - постоянно уточнять безграмотному рекламщику Espressif nikolz разницу подходов в SDK RTL и ESP. Уже неоднократно сказано - по 99% параметрам RTL-ы лучше ESP, а отличия давно разобраны.
Если вас действительно интересует уровень драйвера WiFi в RTL, то в SDK дан список команд в component/common/drivers/wlan/realtek/src/osdep/wireless.h
rtl00TstMinAmebaV35a/wireless.h at master · pvvx/rtl00TstMinAmebaV35a · GitHub
Но что-то мне подсказывает, что вы не полезете на такой уровень :) Это уже уровень для написания сканеров WiFi и он открыт в данном SDK.
Я был о Вас лучшего мнения, но очевидно ошибся.
В своем страстном желании оскорбить меня вы дошли до банального хамства, что не делает Вам чести.
====================
Еще раз Вам объясняю,
что в ESP время выхода из сна установления связи передача пакета по UDP прием ответа от компа составляет 0.5 сек.
----------------------
Вот пример ответа:
1.453;1;ESP_test --интервал времени от предыдущего момента связи, номер пакета, содержимое
1.468;2;ESP_test
1.453;3;ESP_test
1.438;4;ESP_test
Время сна задано 1 секунда. К этой секунде добавляется время, затрачиваемое ESP на просыпание, установление связи обмен пакетами. Это время составляет 0.45 сек.
-------------------
Этот тест я гоняю сутками и проблем нет.
Чего и Вам желаю.
 

pvvx

Активный участник сообщества
Я был о Вас лучшего мнения, но очевидно ошибся.
В своем страстном желании оскорбить меня вы дошли до банального хамства, что не делает Вам чести.
====================
Еще раз Вам объясняю,
что в ESP время выхода из сна установления связи передача пакета по UDP прием ответа от компа составляет 0.5 сек.
----------------------
Вот пример ответа:
1.453;1;ESP_test --интервал времени от предыдущего момента связи, номер пакета, содержимое
1.468;2;ESP_test
1.453;3;ESP_test
1.438;4;ESP_test
Время сна задано 1 секунда. К этой секунде добавляется время, затрачиваемое ESP на просыпание, установление связи обмен пакетами. Это время составляет 0.45 сек.
-------------------
Этот тест я гоняю сутками и проблем нет.
Чего и Вам желаю.
Ну вот сами и описали, что сравниваете разные соединения и разные условия. Так что это хамство с вашей стороны, т.к. уже более 3-х раз вам уточнял про что идет разговор и какие критерии нужны для автономных устройств.
И опять ваш пример голословен - дан без исходных кодов и остального описания условий.
Не описано даже в каком режиме sleep вы делаете замеры. :) Режимов sleep у модулей много, для некоторых, для выхода и нового входа в sleep при отсылке пакета по UDP требуется не более десятка ms.
Или вы хотите снова обсудить известную уже к году ошибку в функции deep_sleep() в SDK Espressif? Её починить обычный пользователь не может, т.к. требуется бинарный патч их библиотеки.
 
Последнее редактирование:

nikolz

Well-known member
Ну вот сами и описали, что сравниваете разные соединения и разные условия. Так что это хамство с вашей стороны, т.к. уже более 3-х раз вам уточнял про что идет разговор и какие критерии нужны для автономных устройств.
---------------------------
Вы умеете отличать хамство от обсуждения технических результатов?
Полагаю, что нет.
Хамство, это когда Вы оскорбляете собеседника ,
излагая Ваши домыслы о его физических возможностях или распространяя заведомую ложь о его намерениях.
-----------------------------
Ва можете иметь какие угодно представление о технических характеристиках устройств, которые делаете Вы.
Я имею свое мнение о технических устройствах, которые делаю я.
----------------------------------
Эти мнения могут не совпадать.
Но Вам никто не дает право оскорблять собеседника, излагая Вашу оценку его личноcти.
Вот это Ваше поведение и есть хамство.
-----------------------------------
Вам нравится Ваше поведение на форуме?
Мне нет.
Но я не буду Вам отвечать в Вашей манере.
------------------------------------------
Если Вам очень важно, чтобы Ваше мнение было единственным на форуме - ради бога.
------------------------------------
Вы не умеете признавать свои ошибки и обсуждать решения, в которых Вы не правы.
Это было и с обсуждением быстродействия SAR
Сейчас Вы ошибочно призываете всех использовать TCP вместо UDP
или рассказываете про каких-то пчел оплевывая WIFI.
А когда Вам пытаются возражать, Вы переходите на личности.
---------------------------------------
Собственно, Вы ответили на мои вопросы хоть и c хамскими выпадами в мой адрес.
-------------------------------------
Но я не обижаюсь.
------------------------------
Полагаю, что дискуссия завершена.
Хвалитесь и хамите дальше и будете Самый, Самый на этом форуме.
 

pvvx

Активный участник сообщества
Вы умеете отличать хамство от обсуждения технических результатов?
Безусловно. Но пока не видел ни одного технического результата от вас.

Всё с вами ясно - вы боритесь за звание самый-самый :) Я в этом не участвую.
Т.е. хотите написать, что вас устраивает, что процессор ESP при выходе в deep_sleep исполняет команды пустой шины и у вашего личного модуля коды с неё не дают “протектед” за время исполнения команды посланной аппаратной части модуля на отключение. :) У меня в 50% случаев на разных модулях ESP успевает сработать “протектед”, отключение модуля всё равно происходит, но при просыпании у него записано, что старт по "протектед", а не по deep_sleep и производится полная инициализация WiFi с полной "калибровкой" WiFi. Вообще не понятно, зачем нужна "калибровка WiFi" - это чудо есть только в ESP. Другие модули используют адаптивную калибровку по мере работы...
Вы не умеете признавать свои ошибки и обсуждать решения, в которых Вы не правы.
Это было и с обсуждением быстродействия SAR
Оно так и не доделано в SDK Espressif, а примеры даны мной и исправление ошибок дано в техническом изложении и с примерами как это использовать. Но вас это не устраивает, и вы следите за каждой моей опечаткой, а говорите не о личной неприязни. :)
Сейчас вы будете агитировать использовать UDP, по причине, что только оно работает нормально на ESP8266, а я буду рассматривать все варианты и с SSL, и c P2P.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Сравнение при фиксированном IP и подключении RTL00 к ESP AP:
Отсылка UDP пакета "Hello Nikolz!" (через socket(AF_INET,SOCK_DGRAM,0)):
UDP_send.gif
Открытие страницы WEB сервера (более 3-х килобайт) и прем её (через socket(PF_INET, SOCK_STREAM, 0)):
HTTP_recvest.gif
Код, работающий на ESP тут GitHub - pvvx/esp8266web: Small web server on ESP8266
Там-же и HTTP страница c выводом графиков измерения с датчика INA219 с помощью ina219.ovl.
Часть кода для RTL в первых сообщениях темы, остальное (установка с кем соединяться и установка фиксированного IP) по требованию :)
WiFi таймеры пока не исправлены. Применен 'дикий патч' по старту:
Код:
         HalCpuClkConfig(3);
        SystemCoreClockUpdate();
        En32KCalibration();
        HalCpuClkConfig(CPU_CLOCK_SEL_VALUE); // 0 - 166666666 Hz, 1 - 83333333 Hz, 2 - 41666666 Hz, 3 - 20833333 Hz, 4 - 10416666 Hz, 5 - 4000000 Hz
        HAL_LOG_UART_ADAPTER pUartAdapter;
        pUartAdapter.BaudRate = RUART_BAUD_RATE_38400;
        HalLogUartSetBaudRate(&pUartAdapter);
Из 500 ms активности RTL тратится 1196/(38400/10) = 0.311458 сек на вывод в UART лога (1196 байт):
Код:
ATST: Mem info:

CLK CPU        166666666 Hz
RAM heap    107760 bytes
RAM free    71696 bytes
TCM heap    65024 bytes
TCM free/stack    512 bytes
RAM Heap Memory List:
[0]=0x0x10041b70, 0
[1]=0x0x10002360, 15512
[2]=0x0x10047ed8, 92152
TCM Free List:
prev 10041d60, chunk 1fff0000, size 65024


#interface 1 is initialized
interface 0 is initialized
Initializing WIFI ...


Start LOG SERVICE MODE



# WiFi Init after 1173 ms


RTL8195A[Driver]: set BSSID: 1a:fe:34:99:ad:1d


RTL8195A[Driver]: start auth to 1a:fe:34:99:ad:1d


RTL8195A[Driver]: auth success, start assoc


RTL8195A[Driver]: association success(res=2)
WiFi connected at start 3549 ms
Read dhcp_config: mode = 2, ip:0x304a8c0, msk:0xffffff, gw:0x104a8c0
WIFI initialized

Socked connect at start 3802 ms.
HTTP/1.1 200 OK

Server: PVs/0.1

Connection: close

Access-Control-Allow-Origin: *

Content-Type: text/html

Cache-Control: no-store, no-cache, must-revalidate, max-age=0


Socked close at start 4428 ms.
LwIP_DHCP: dhcp stop.
Deinitializing WIFI ...


[rltk_wlan_deinit] Wait for TX/RX Busy (1)

[rltk_netif_rx] netif is DOWNWIFI deinitialized

Deep-sleep at start 5839 ms.
Время смотреть не стоит - "патч" убивает правильный ход часов RTOS. Как минимум в 4-ре раза и некорректно вычисляются IDLE.
Т.е. никаких внешних факторов, так нравящихся nikolz :)
----------
После анализа имеющегося на сегодня SDK3.5b встают такие задачи по его исправлению:

1) Ремонт WiFi либы. Добавление ускоренной инициализации драйвера WiFi и его отключения.
2) Добавление в SDK возможности отключения вывода сообщений на ходу и при компиляции (для уменьшения кода) от всех источников и увеличения производительности когда это необходимо, а не ожидания задачами вывода в DiagPrintf(), работающего с UART без DMA (да и любой буфер переполнится, если выводить много сообщений). (Частично проделано - осталась только WiFi либа. Диагностических и прочих сообщений в выходном коде стандартного SDK более 20 килобайт и полная путаница c "\n\r" - в мультизадачке прошлые сообщения затираются безбрежно напичканными переходами в начало строки и зависит от монитора, как он воспринимает код перехода в начало строки :) - встречается до десятка подряд "\r" или "\n" - писатели SDK любители кода перевода строки и перехода в начало строки расставленных то в начале сообщения, то в конце :) )
3) Добавление в SDK пользовательских настроек для WiFi, DHCP и прочего для соединения по просыпанию после deep_sleep. (У меня уже проделано – подключена моя либа flash_eep)
4) Уборка в SDK не менее 5-ти дублей кода для соединения к внешней AP, что путает всё и увеличивает код – требуется исправлять и добавлять код в каждый дубль… Особо веселит, что везде разные reconnect и итого при неудаче соединения… :)
5) Ещё много по мелочи, но это опционально.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Движений у разработчиков SDK в данную тему пока не видно...
Пока приходится вставлять кривые патчи для ускорения операций с WiFi.
Подобно таким:
Код:
extern struct net_device *rltk_wlan_info;
void patch_rltk_wlan_deinit(void)
{
    struct net_device *v0;
  int v1;
  char *v4;

  v0 = rltk_wlan_info;

  if(rltk_wlan_info->priv != NULL) {
    v1 = *(u32 *)rltk_wlan_info->priv; /* pointer to private data */
    *(u8 *)(v1 + 5892) = 1;
    rtw_wakeup_task(v1 + 5912);
    while(1) {
      save_and_cli();
      *((u8 *)&rltk_wlan_info + 16) = 0;
      *((u8 *)&rltk_wlan_info + 40) = 0;
      v4 = &(*(&rltk_wlan_info + 9))->name[(u32)*(&rltk_wlan_info + 2)
                                         + (u32)*(&rltk_wlan_info + 3)
                                         + (unsigned int)*(&rltk_wlan_info + 8)];
      restore_flags();
      if (!v4 )   break;
      rtl_printf("[%s] Wait for TX/RX Busy (%d)\n", "rltk_wlan_deinit", v4);
      vTaskDelay(10); // замена rtw_mdelay_os(1000)
    }
    while(1) {
      if ( !*(u32 *)(v1 + 5916) || *(u8 *)(v1 + 5892) == 2 )  break;
      rtl_printf("[%s] Wait for RxStop\n", "rltk_wlan_deinit");
      vTaskDelay(10); // замена rtw_mdelay_os(1000)
    }
    rtw_dev_remove(rltk_wlan_info);
    rtw_drv_halt();
    deinit_timer_wrapper();
    *((u8 *)&rltk_wlan_info + 16) = 0;
    *((u8 *)&rltk_wlan_info + 40) = 0;
    *(u64 *)&rltk_wlan_info = 0LL;
    *((u64 *)&rltk_wlan_info + 1) = 0LL;
    *((u64 *)&rltk_wlan_info + 3) = 0LL;
    *((u64 *)&rltk_wlan_info + 4) = 0LL;
    //deinit_mem_monitor(NULL, NULL);
  }
}
Т.е. менять задержки опроса в 1 сек, типа rtw_mdelay_os(1000) на 0.01 сек - на vTaskDelay(10);
 
Сверху Снизу