Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

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

Тема в разделе "Realtek - SDK, прошивки и утилиты", создана пользователем pvvx, 4 ноя 2016.

  1. pvvx

    pvvx Активный участник сообщества

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

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

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

    Часть кода, для информации что примерно будем исследовать:
    код (раскрыть)
    Код (C):
    1.  
    2. #define SOCKET_STACK_SIZE 250
    3. #define SOCKET_PRIORITY tskIDLE_PRIORITY + 7 + PRIORITIE_OFFSET
    4. extern struct netif xnetif[NET_IF_NUM];
    5. #define rmt_port 80  
    6. #define rmt_ip (xnetif[0].gw.addr) // 0x0104A8C0 = 192.168.4.1
    7.  
    8. char fbuf[512];
    9. int fbuf_cnt;
    10. gpio_t gpio_obj;
    11.  
    12. // чтение и пропуск HTTP заголовка
    13. int http_head_read(unsigned char *buf, int len, int ff) {
    14. int flg_head = 0;
    15. int n, ret = 0;
    16. fbuf_cnt = 0;
    17. if ((n = read(ff, buf, len)) <= 0) return 0;
    18. if(n > 11 && *((u32 *)buf) == 0x50545448) { // "HTTP" // HTTP/1.0 200 OK
    19. int x;
    20. for(x = 3; x < n && buf[x] != ' '; x++);
    21. while(x < n && buf[x] == ' ') x++;
    22. if(x < n) ret = atoi(&buf[x]);
    23. int cnt = 0;
    24. x = 0;
    25. while(ret) {
    26. int z = 0;
    27. while (x < n) {
    28. if (cnt++ > 16384) return 600; // Header Too Large
    29. if (buf[x++] == ((flg_head & 1) ? 0x0a : 0x0d)) {
    30. if ((flg_head & 3) == 1) {
    31. #if DEBUG_MAIN_LEVEL > 0
    32. buf[x-1] = 0;
    33. DBG_8195A("%s\n", &buf[z]);
    34. #endif
    35. z = x;
    36. }
    37. if (flg_head >= 3) {
    38. if (n - x > 0) {
    39. fbuf_cnt = n - x;
    40. rtl_memcpy(&fbuf, &buf[x], fbuf_cnt);
    41. }
    42. #if DEBUG_MAIN_LEVEL > 1
    43. DBG_8195A("TST: Skip HTTP head in %d bytes\n\n", cnt);
    44. #endif
    45. return ret;
    46. }
    47. flg_head++;
    48. }
    49. else flg_head = 0;
    50. }
    51. x = 0;
    52. while(z < n) buf[x++] = buf[z++];
    53. if ((n = read(ff, &buf[x], len - x)) <= 0) return 601; // content ??
    54. n += x;
    55. };
    56. }
    57. fbuf_cnt = n;
    58. return ret;
    59. }
    60. // Тестовый socked
    61. void test_socked(void)
    62. {
    63. struct sockaddr_in remote_ip;
    64. int sock = socket(PF_INET, SOCK_STREAM, 0);
    65. if (sock == -1) {
    66. #if DEBUG_MAIN_LEVEL > 0
    67. DBG_8195A("TST: Not open socket!\n");
    68. #endif
    69. vTaskDelete(NULL);
    70. return;
    71. }
    72. rtl_memset(&remote_ip, 0, sizeof(remote_ip));
    73. remote_ip.sin_family = AF_INET;
    74. remote_ip.sin_addr.s_addr = rmt_ip;
    75. remote_ip.sin_port = htons(rmt_port);
    76. DiagPrintf("\nSocked connect at start %d ms.\n", xTaskGetTickCount());
    77. if (connect(sock, (struct sockaddr * )(&remote_ip), sizeof(struct sockaddr)) != 00) {
    78. close(sock);
    79. #if DEBUG_MAIN_LEVEL > 0
    80. DBG_8195A("TST: Connect error!\n");
    81. #endif
    82. vTaskDelete(NULL);
    83. return;
    84. }
    85. sprintf(&fbuf,"GET / HTTP/1.0/\r\nTime at start %d ms.\r\n\r\n", xTaskGetTickCount());
    86. int x = strlen(&fbuf);
    87. write(sock, &fbuf, x);
    88. if ((x = http_head_read(fbuf, sizeof(fbuf), sock)) != 200) {
    89. #if DEBUG_MAIN_LEVEL > 0
    90. DBG_8195A("TST: HTTP error %d\n", x);
    91. #endif
    92. }
    93. close(sock);
    94. DiagPrintf("\nSocked close at start %d ms.\n", xTaskGetTickCount());
    95. wifi_off();
    96. DiagPrintf("\nDeep-sleep at start %d ms.\n", xTaskGetTickCount());
    97. sys_log_uart_off();  // turn off log uart
    98. HalPinCtrlRtl8195A(JTAG, 0, 0); // turn off JTAG
    99. // Enter deep_sleep, wakeap:  PA_5
    100. gpio_init(&gpio_obj, PA_5);
    101. gpio_dir(&gpio_obj, PIN_INPUT);
    102. gpio_mode(&gpio_obj, PullUp);
    103. standby_wakeup_event_add(STANDBY_WAKEUP_BY_PA5, 0, gpio_read(&gpio_obj)? 0 :  1); deepstandby_ex();
    104. vTaskDelete(NULL);
    105. }
    106.  
    107. // Connect_start() вызывается при подключении WiFi к внешней AP и получении IP (встроил в свой SDK).
    108. void connect_start(void)
    109. {
    110. #if DEBUG_MAIN_LEVEL > 0
    111. DiagPrintf("\nConnected at start %d ms.\n", xTaskGetTickCount());
    112. #endif
    113. if (pdTRUE != xTaskCreate( test_socked, (const signed char * const)"socked", SOCKET_STACK_SIZE, NULL, SOCKET_PRIORITY, NULL))
    114. DiagPrintf("Create Log UART Task Err!\n");
    115. }
    Main() запускает соединение WiFi по записанным ранее в Flash установкам.
    Дополнительно в код включена поддержка нескольких отладочных AT команд.
    В итоге, в резерве, в RTL00 остается около 200 килобайт неиспользованной RAM (пик во время открытого socked).

    Console log (раскрыть)
    Код (Text):
    1. #interface 1 is initialized
    2. interface 0 is initialized
    3. Initializing WIFI ...
    4. Start LOG SERVICE MODE
    5. # WiFi Init after 299ms
    6. Joining BSS by SSID ESP8266...
    7. RTL8195A[Driver]: set ssid [ESP8266]
    8. RTL8195A[Driver]: start auth to 1a:fe:34:99:ad:1d
    9. RTL8195A[Driver]: auth success, start assoc
    10. RTL8195A[Driver]: association success(res=2)
    11. WiFi connected at start 1591ms
    12. Connected after 1294ms
    13. Interface 0 IP address : 192.168.4.3
    14. Got IP after 1810ms
    15. Connected at start 2121 ms.
    16. Socked connect at start 2129 ms.
    17. WIFI initialized
    18. HTTP/1.1 200 OK
    19. Server: PVs/0.1
    20. Connection: close
    21. Access-Control-Allow-Origin: *
    22. Content-Type: text/html
    23. Cache-Control: no-store, no-cache, must-revalidate, max-age=0
    24. Socked close at start 2213 ms.
    25. LwIP_DHCP: dhcp stop.
    26. Deinitializing WIFI ...
    27. [rltk_wlan_deinit] Wait for TX/RX Busy (1)WIFI deinitialized
    28. Deep-sleep at start 3351 ms.


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

    pvvx Активный участник сообщества

    Сообщения:
    8.965
    Симпатии:
    1.301
    Как видим, похоже, что в 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 пока не может позиционироваться для использования в автономных устройствах. Требуются множественные "патчи". У кого какие предложения?
     
    Последнее редактирование: 4 ноя 2016
  3. pvvx

    pvvx Активный участник сообщества

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

    pvvx Активный участник сообщества

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

    nikolz Гуру

    Сообщения:
    4.925
    Симпатии:
    454
    правильно ли я вас понял, что минимальное время затрачиваемое RTL на выхода из deep-sleep+связь с сервером +вход в deep-sleep составляет в исходниках 5 секунд, в вашем варианте 1.4 секунды?
    Если так, то почему Вы утверждаете что это меньше, чем 0.34 секунды в ESP?
     
  6. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.965
    Симпатии:
    1.301
    Как всегда вы всё искажаете :) Ещё не надоела работать на рекламу 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.
     
    Последнее редактирование: 6 ноя 2016
  7. nikolz

    nikolz Гуру

    Сообщения:
    4.925
    Симпатии:
    454
    Я был о Вас лучшего мнения, но очевидно ошибся.
    В своем страстном желании оскорбить меня вы дошли до банального хамства, что не делает Вам чести.
    ====================
    Еще раз Вам объясняю,
    что в 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 сек.
    -------------------
    Этот тест я гоняю сутками и проблем нет.
    Чего и Вам желаю.
     
  8. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.965
    Симпатии:
    1.301
    Ну вот сами и описали, что сравниваете разные соединения и разные условия. Так что это хамство с вашей стороны, т.к. уже более 3-х раз вам уточнял про что идет разговор и какие критерии нужны для автономных устройств.
    И опять ваш пример голословен - дан без исходных кодов и остального описания условий.
    Не описано даже в каком режиме sleep вы делаете замеры. :) Режимов sleep у модулей много, для некоторых, для выхода и нового входа в sleep при отсылке пакета по UDP требуется не более десятка ms.
    Или вы хотите снова обсудить известную уже к году ошибку в функции deep_sleep() в SDK Espressif? Её починить обычный пользователь не может, т.к. требуется бинарный патч их библиотеки.
     
    Последнее редактирование: 6 ноя 2016
  9. nikolz

    nikolz Гуру

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

    pvvx Активный участник сообщества

    Сообщения:
    8.965
    Симпатии:
    1.301
    Безусловно. Но пока не видел ни одного технического результата от вас.

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

    pvvx Активный участник сообщества

    Сообщения:
    8.965
    Симпатии:
    1.301
    Сравнение при фиксированном 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 таймеры пока не исправлены. Применен 'дикий патч' по старту:
    Код (C):
    1.          HalCpuClkConfig(3);
    2.         SystemCoreClockUpdate();
    3.         En32KCalibration();
    4.         HalCpuClkConfig(CPU_CLOCK_SEL_VALUE); // 0 - 166666666 Hz, 1 - 83333333 Hz, 2 - 41666666 Hz, 3 - 20833333 Hz, 4 - 10416666 Hz, 5 - 4000000 Hz
    5.         HAL_LOG_UART_ADAPTER pUartAdapter;
    6.         pUartAdapter.BaudRate = RUART_BAUD_RATE_38400;
    7.         HalLogUartSetBaudRate(&pUartAdapter);
    Из 500 ms активности RTL тратится 1196/(38400/10) = 0.311458 сек на вывод в UART лога (1196 байт):
    UART log (раскрыть)
    Код (Text):
    1.  
    2. ATST: Mem info:
    3.  
    4. CLK CPU        166666666 Hz
    5. RAM heap    107760 bytes
    6. RAM free    71696 bytes
    7. TCM heap    65024 bytes
    8. TCM free/stack    512 bytes
    9. RAM Heap Memory List:
    10. [0]=0x0x10041b70, 0
    11. [1]=0x0x10002360, 15512
    12. [2]=0x0x10047ed8, 92152
    13. TCM Free List:
    14. prev 10041d60, chunk 1fff0000, size 65024
    15.  
    16.  
    17. #interface 1 is initialized
    18. interface 0 is initialized
    19. Initializing WIFI ...
    20.  
    21.  
    22. Start LOG SERVICE MODE
    23.  
    24.  
    25.  
    26. # WiFi Init after 1173 ms
    27.  
    28.  
    29. RTL8195A[Driver]: set BSSID: 1a:fe:34:99:ad:1d
    30.  
    31.  
    32. RTL8195A[Driver]: start auth to 1a:fe:34:99:ad:1d
    33.  
    34.  
    35. RTL8195A[Driver]: auth success, start assoc
    36.  
    37.  
    38. RTL8195A[Driver]: association success(res=2)
    39. WiFi connected at start 3549 ms
    40. Read dhcp_config: mode = 2, ip:0x304a8c0, msk:0xffffff, gw:0x104a8c0
    41. WIFI initialized
    42.  
    43. Socked connect at start 3802 ms.
    44. HTTP/1.1 200 OK
    45.  
    46. Server: PVs/0.1
    47.  
    48. Connection: close
    49.  
    50. Access-Control-Allow-Origin: *
    51.  
    52. Content-Type: text/html
    53.  
    54. Cache-Control: no-store, no-cache, must-revalidate, max-age=0
    55.  
    56.  
    57. Socked close at start 4428 ms.
    58. LwIP_DHCP: dhcp stop.
    59. Deinitializing WIFI ...
    60.  
    61.  
    62. [rltk_wlan_deinit] Wait for TX/RX Busy (1)
    63.  
    64. [rltk_netif_rx] netif is DOWNWIFI deinitialized
    65.  
    66. 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) Ещё много по мелочи, но это опционально.
     
    Последнее редактирование: 6 ноя 2016
  12. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.965
    Симпатии:
    1.301
    Движений у разработчиков SDK в данную тему пока не видно...
    Пока приходится вставлять кривые патчи для ускорения операций с WiFi.
    Подобно таким:
    rltk_wlan_deinit() (раскрыть)
    Код (C):
    1.  
    2. extern struct net_device *rltk_wlan_info;
    3. void patch_rltk_wlan_deinit(void)
    4. {
    5.     struct net_device *v0;
    6.   int v1;
    7.   char *v4;
    8.  
    9.   v0 = rltk_wlan_info;
    10.  
    11.   if(rltk_wlan_info->priv != NULL) {
    12.     v1 = *(u32 *)rltk_wlan_info->priv; /* pointer to private data */
    13.     *(u8 *)(v1 + 5892) = 1;
    14.     rtw_wakeup_task(v1 + 5912);
    15.     while(1) {
    16.       save_and_cli();
    17.       *((u8 *)&rltk_wlan_info + 16) = 0;
    18.       *((u8 *)&rltk_wlan_info + 40) = 0;
    19.       v4 = &(*(&rltk_wlan_info + 9))->name[(u32)*(&rltk_wlan_info + 2)
    20.                                          + (u32)*(&rltk_wlan_info + 3)
    21.                                          + (unsigned int)*(&rltk_wlan_info + 8)];
    22.       restore_flags();
    23.       if (!v4 )   break;
    24.       rtl_printf("[%s] Wait for TX/RX Busy (%d)\n", "rltk_wlan_deinit", v4);
    25.       vTaskDelay(10); // замена rtw_mdelay_os(1000)
    26.     }
    27.     while(1) {
    28.       if ( !*(u32 *)(v1 + 5916) || *(u8 *)(v1 + 5892) == 2 )  break;
    29.       rtl_printf("[%s] Wait for RxStop\n", "rltk_wlan_deinit");
    30.       vTaskDelay(10); // замена rtw_mdelay_os(1000)
    31.     }
    32.     rtw_dev_remove(rltk_wlan_info);
    33.     rtw_drv_halt();
    34.     deinit_timer_wrapper();
    35.     *((u8 *)&rltk_wlan_info + 16) = 0;
    36.     *((u8 *)&rltk_wlan_info + 40) = 0;
    37.     *(u64 *)&rltk_wlan_info = 0LL;
    38.     *((u64 *)&rltk_wlan_info + 1) = 0LL;
    39.     *((u64 *)&rltk_wlan_info + 3) = 0LL;
    40.     *((u64 *)&rltk_wlan_info + 4) = 0LL;
    41.     //deinit_mem_monitor(NULL, NULL);
    42.   }
    43. }

    Т.е. менять задержки опроса в 1 сек, типа rtw_mdelay_os(1000) на 0.01 сек - на vTaskDelay(10);
     

Поделиться этой страницей