Тестирование и модификация 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);
 
Сверху Снизу