• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Web-свалка на RTL871x

pvvx

Активный участник сообщества
Не знаю, что ещё придумать-то...
Должно работать с чем угодно.
Если падает связь, то явно какие-то проблемы. Переполнение буфера приема говорит о том, что пакеты не пошли на обработку в LwIP. Это, возможно, если LwIP упал или его тред остановлен по каким-то причинам...
Первое, что надо проверить - питание модуля.
Второе - в логе у вас "CLK CPU 166666666 Hz". Возможно для RTL8710AF это много. Поставьте 83 MHz.
Я сейчас проверяю на RTL8195AM... У них возможны разные CLK на периферию (включая обычные устройства типа Flash), прописанные в eFuse и пока нет всех данных по закрытым частям WiFi драйвера, но ветвления по типу ID чипов там есть...
В некоторых доках указано даже различие, что типа RTL8710AF не работает на HT40. Всё это надо-бы выковырять из SDK и удалить, но времени на это пока нет...
Как пример - у меня макетка с SD на RTL8710AF на 83МГц не работает с SD - практически одни сбои данных в драйвере SDIOH. Если ставить 166 - работает без ошибок...

---
Прошло 3.5 часа при 3-х соединениях (роутер с глобал инет (фикс ip) - STA_RTL, AP_RTL - телефон, AP_RTL - Windows). Все соединения активны и не отваливаются...
 
Последнее редактирование:

aloika

Active member
Первое, что надо проверить - питание модуля.
RTL8710-WiFi.jpg_640x640.jpg
Плата вот такая, питается от USB.

Частоту еще не менял.

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

Код:
srv[80] 192.168.4.6:65135 [2] read: 518 of1[index.htm] GET f[/index.htm] head[201]:200 send: of2[menu.inc] cf2 of2[footer.inc] cf2 of2[time.inc] cf2 cf1 1939 dis
srv[80] 192.168.4.6:65135 [2] disconnect
srv[80] 192.168.4.6:65136 [1] read: 387 of1[style.css] GET f[/style.css] head[187]:200 send: 1261 cf1 dis
srv[80] 192.168.4.6:65136 [1] disconnect
srv[80] 192.168.4.6:65137 [1] listen
srv[80] 192.168.4.6:65137 [1] read: 407 of1[logo.gif] GET f[/logo.gif] head[163]:200 send: 393 cf1 dis
srv[80] 192.168.4.6:65138 [2] listen
srv[80] 192.168.4.6:65137 [2] disconnect
srv[80] 192.168.4.6:65138 [1] read: 406 of1[rtl.gif] GET f[/rtl.gif] head[163]:200 send: 750 cf1 dis
srv[80] 192.168.4.6:65138 [1] disconnect
srv[80] 192.168.4.6:65139 [1] listen
srv[80] 192.168.4.6:65139 [1] read: 453 of1[favicon.ico] GET f[/favicon.ico] head[202]:200 send: 810 cf1 dis
srv[80] 192.168.4.6:65139 [1] disconnect
srv[80] 192.168.4.6:65151 [1] listen
srv[80] 192.168.4.6:65152 [2] listen
srv[80] 192.168.4.6:65151 [2] read: 518 of1[index.htm] GET f[/index.htm] head[201]:200 send: of2[menu.inc] cf2 of2[footer.inc] cf2 of2[time.inc] cf2 cf1 1939 dis

RTL8195A[Driver]: skb_unavailable=1 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=2 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=4 in last 2 seconds
srv[80] 192.168.4.6:65151 [2] disconnect
srv[80] 192.168.4.6:65152 [1] disconnect

RTL8195A[Driver]: skb_unavailable=5 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=4 in last 2 seconds

[alloc_skb] Wait for skbdata

[alloc_skb] Wait for skbdata

[alloc_skb] Wait for skbdata

RTL8195A[Driver]: skb_unavailable=3 in last 2 seconds

[alloc_skb] Wait for skbdata

RTL8195A[Driver]: skb_unavailable=3 in last 2 seconds

[alloc_skb] Wait for skbdata

RTL8195A[Driver]: ap recv deauth reason code(3) sta:58:12:43:25:e6:0d

RTL8195A[Driver]: skb_unavailable=2 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=2 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=1 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=3 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=1 in last 2 seconds

RTL8195A[Driver]: skb_unavailable=2 in last 2 seconds

[alloc_skb] Wait for skbdata

[alloc_skb] Wait for skbdata

RTL8195A[Driver]: +OnAuth: 58:12:43:25:e6:0d

RTL8195A[Driver]: +OnAssocReq

RTL8195A[Driver]: skb_unavailable=1 in last 2 seconds
srv[80] 192.168.4.6:65162 [1] listen
srv[80] 192.168.4.6:65162 [1] read: 518 of1[index.htm] GET f[/index.htm] head[201]:200 send: of2[menu.inc] cf2 of2[footer.inc] cf2 of2[time.inc] cf2 cf1 1939 dis
srv[80] 192.168.4.6:65162 [1] disconnect
srv[80] 192.168.4.6:65163 [1] listen
srv[80] 192.168.4.6:65163 [1] read: 387 of1[style.css] GET f[/style.css] head[187]:200 send: 1261 cf1 dis
srv[80] 192.168.4.6:65163 [1] disconnect
srv[80] 192.168.4.6:65164 [1] listen
srv[80] 192.168.4.6:65164 [1] read: 407 of1[logo.gif] GET f[/logo.gif] head[163]:200 send: 393 cf1 dis
srv[80] 192.168.4.6:65165 [2] listen
srv[80] 192.168.4.6:65165 [2] read: 406 of1[rtl.gif] GET f[/rtl.gif] head[163]:200 send: 750 cf1 dis
srv[80] 192.168.4.6:65164 [2] disconnect
srv[80] 192.168.4.6:65165 [1] disconnect
srv[80] 192.168.4.6:65166 [1] listen
srv[80] 192.168.4.6:65166 [1] read: 453 of1[favicon.ico] GET f[/favicon.ico] head[202]:200 send: 810 cf1 dis
srv[80] 192.168.4.6:65166 [1] disconnect
Т.е. какой-то сбой был и восстановилось потом всё. Это я на телефоне wi-fi выключил и снова включил. А иногда не восстанавливается.
 

aloika

Active member
Итак, с большой долей вероятности причина глюков отыскалась. Дело в телефоне. Если телефон не использовать, то связь стабильна, все работает нормально. Проверял с планшетом на андроиде - никаких проблем не обнаружено (за ~3 часа вчера и ~5 часов сегодня).

С телефоном эти глюки возникают, когда телефон уходит в "глубокий сон" (или куда он там уходит). При пробуждении с большой долей вероятности веб-интерфейс на нем не открывается, и через несколько секунд модуль падает в этот режим (но не всегда). Иногда получается восстановить работу модуля, закрыв все его wi-fi соединения и снова их открыв (но опять же, не всегда).

Телефон старый китайский Changjiang N7300, на андроиде 4.1.2, перешитый на LewaOS лет пять назад.

Планшет, с которым всё работает без нареканий: Nexus 10, android 5.1.1 со всеми обновлениями.

Вот такие дела. У модуля я включил CONFIG_DEBUG_LOG 5, configUSE_TRACE_FACILITY, configUSE_STATS_FORMATTING_FUNCTIONS, в логе стало информации больше, но понятнее от этого не стало.
 

oleg_777

New member
В связи с “летом” , времени “на сидение на попе”, совсем нет. Может кто поможет, адаптировать Dygraphs или Highcharts для нормального отображения поступающих текущих данных c датчиков?
вот так может быть подойдет... Dygraph - JSFiddle

распиши в цифрах что и как надо... а то не очень понимаю...
 
Последнее редактирование:

pvvx

Активный участник сообщества
вот так может быть подойдет... Dygraph - JSFiddle
При изменении указателей области отображения в нижнем графике оно так-же всё уезжает и невозможно задать участок привязанный к концу динамически поступающих данных... Требуется переписывание самой Dygraph. В JSFiddle это работает, но там другие ограничения и тоже надо всё переписывать... Внешними командами обращения и изменением параметров данных либ ничего не сделать дельного...
Они все хорошо работает со статическими данными, но с динамическими - никак.
В общем там вопрос не как сделать, а в том, что пока нет времени на это и надеялся найти что-то готовое, более подходящее для таких целей, но оказалось, что во всем инет никто ещё не решал такой задачи (ну кроме платных заказных). Участь у меня такая - нарываться на задачи, на которые ещё нет готовых решений и пилить их самому... :)

Общая концепция желаемого отображения данных для оператора описана и должна исходить из таких условий, что устройство может отдать:
1) Текущий поток данных, идущий с дискретностью точек в полосу канала связи.
2) Накопленные усредненные данные, со значительно большим шагом между точками.

Текущий поток данных нигде не буферизируется, кроме как на устройстве отображения оператора. Т.к. он нужен только для детального анализа текущей ситуации, но может использоваться и для накопления точных измерений при произведении какого-то опыта. Это наиболее часто требуемые задачи и красивых решений для них пока нет. Конкретных концепций в данном деле не было разработано и проработано по причине отсутствия таких удаленных датчиков и появляется только сейчас, с ростом производительности сетей IoT и ростом производительности отображающих панелей (скорости обработки на конечном устройстве пользователя, хотя-бы том-же смартфоне, на стандартных интерфейсах типа javascript…).
Как альтернативный пример – современный цифровой осциллограф. В нем отображается текущий поток с выбранным разрешением и достаточно большой глубиной “пост” буфера, но отображается только выбранное окно конца этого потока или по какому условию синхронизации отображаемого окна поступающих динамических данных. Можно остановить прием и детально рассмотреть накопленный буфер.

Усредненные данные, накапливаемые устройством или на внешнем сервере – это уже статические данные и проблем с их выводом и отображением нет – есть куча готовых и реализованных вариантов.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Вроде разобрался и сделал.
Dygraph - JSFiddle
Снимок1587.gif
Но указатель 2 не подвинуть и не переместить выбранную область. Так-же нет ограничения размера накопительного буфера. Он при более 10 тысяч точек начинает тормозить до ужаса на разных устройствах типа телефонов. Расчетный поток точек необходим с 10 до 1000 точек в секунду. Более у Dygraph проблемы.
RTL00_WEB/ExampleHTM/dygraph at master · pvvx/RTL00_WEB · GitHub
В моем видео поток ~20 тысячи точек
- скорость работы ADC RTL по умолчанию (макс за 60 кГц), а для простейших датчиков, типа INA219, всякие 3D компасы и акселерометры на I2C, следует ориентироваться на 1000 точек в секунду.
Скорость отображения сильно повышается (в разы), если в нем отключить вывод точек.
С включенным отображением тормозит и на компе:
Т.е. уже идут пропуски в приеме с websocket (javascript перегружен отображением и не успевает, надо разделять на отдельные потоки...)

Dygraph - JSFiddle
При потоке в 1 точку в секунду делать ничего не надо - на то есть и благополучно обрабатывает Highcharts
Звуковые файлы (потоки) javascript, используя Audio API отображает без проблем. А там сотни тысяч точек в секунду... A simple spectrum analyser & oscilloscope using Web Audio API

Короче задача комплексная и решить её в JSFiddle путем внешних манипуляций с Dygraph не выйдет. Иначе бы и не вопрошал о помощи :)
 
Последнее редактирование:

aloika

Active member
pvvx, что с этой проблемой-то делать?

RTL8195A[Driver]: skb_unavailable=1 in last 2 seconds
Я попробовал переключить частоту модуля на 83 МГц - всё то же самое.
Это однозначно связано с телефоном, без него всё работает без нареканий. Если при попадании в этот режим отключить все wi-fi соединения, то модуль восстанавливает работу, можно снова подключиться к нему и пользоваться.

Может быть ещё какие-нибудь эксперименты провести (раз уж у меня такой телефон), может, что-то натолкнет на решение? Кроме вас вряд ли кто разберется в этом...
 

pvvx

Активный участник сообщества
pvvx, что с этой проблемой-то делать?
А пока от вас нет никаких данных, кроме того, что пишет переполнение буфера по приему до LwIP, и то неизвестно это последствие чего-то (сбоя на уровне и выше LwIP) или причина самого сбоя на уровне драйвера WiFi. Там может много чего быть - например ошибка где-то и кто-то попадает не в свою память. Это возможно и с помощью отладочных команд web-серверу типа записать куда в память значение :) ...
В общем ситуация такая - информация только о том, что у вас что-то не работает, а перебрать все варианты я не могу и телепатически подключаться к вашему модулю ещё не научился и в продаже таких фич нет... :)

Всё что пока вы пишите не является технической информацией. Вот смотрим:
Это однозначно связано с телефоном, без него всё работает без нареканий. Если при попадании в этот режим отключить все wi-fi соединения, то модуль восстанавливает работу, можно снова подключиться к нему и пользоваться.
Не указано что “отваливается” – не пингуется, или сменен ip, или … т.е. не указали и не локализовали даже уровень где происходит сбой и что за сбой (что остается рабочим, а что недоступно).
Приводите только надпись о переполнении входного буфера драйвера WiFi.
 
Последнее редактирование:

aloika

Active member
А пока от вас нет никаких данных, кроме того, что пишет переполнение буфера по приему до LwIP
Так я бы рад все данные дать, просто не знаю, что ещё можно сделать и куда смотреть. Если вы подскажете, что еще можно сделать - сделаю и и отчет выдам.
Просто если это с моим телефоном такие глюки проявились, то не исключено, что они же ещё при каких-нибудь условиях в самый неподходящий и ответственный момент вылезут.
 

pvvx

Активный участник сообщества
Так я бы рад все данные дать, просто не знаю, что ещё можно сделать и куда смотреть.
На прошлых вариантах, типа SDK 3.5 это тоже актуально? Последними менялись процедуры взаимодействия настроек с WiFi драйвером... Возможно что пропустил что-то, т.к. есть различия в основных структурах драйвера WiFi и стыковки его с системой у SDK 3.5 и 4.0 ...
 

aloika

Active member
Не указано что “отваливается” – не пингуется, или сменен ip, или …
Проверил - когда "отваливается" - не пингуется.
Проверил - на SDK 3.5.3 та же самая история (возникает тот же глюк при тех же условиях).

Что такое "или сменен IP"? Подключения: SoftAP - Win10, SoftAP - Android. ST (станция) не активна. У кого сменён?

Скачал и прошил новую сборку с патчем (4.0.2). Проверяю...
Эх, грусть-тоска :( Та же самая история. Не помог патч. :(

Что ещё проверить, куда смотреть?
 
Последнее редактирование:

pvvx

Активный участник сообщества
Что такое "или сменен IP"?
DHCP мог что натворить...
Вы так и не описали конкретно что происходит, т.е. "кто отваливается" - все или кто-то один... И пишите в личку, а то тут всё завалим логами и прочим :)
 

oleg_777

New member
Доработал Dygraphs - Dygraph - JSFiddle

Также сделано что отображение и получение потока данных разделено и настраивается.

Галочка "Fix to end." привязывает просмотр к концу данных.
 

oleg_777

New member
а вот версия где чуток переделана сама Dygraphs - Plunker

в ней введено прореживание вывода если точек больше xStepLimit (по умолчанию = 4000).

также введено прореживание вывода в RangeSelector

Эта самый быстрый вариант.
 
Последнее редактирование:
Столкнулся с неприятной особенностью компилятора. К самой Web-свалке это вряд ли имеет отношение, скорее к gcc. Написал вот такой код
Код:
  gpio_write(&rts_pin, 1);
  vTaskDelay(1000/portTICK_RATE_MS);
  gpio_write(rts_pin, 0);
Его компилятор молча превратил в такое:
Код:
100078ec:    2101          movs    r1, #1
100078ee:    4620          mov    r0, r4
100078f0:    f011 fdd4     bl    1001949c <gpio_write>
100078f4:    f44f 707a     mov.w    r0, #1000    ; 0x3e8
100078f8:    f00f ff36     bl    10017768 <vTaskDelay>
100078fc:    2300          movs    r3, #0
100078fe:    9302          str    r3, [sp, #8]
10007900:    f104 0310     add.w    r3, r4, #16
10007904:    e893 0003     ldmia.w    r3, {r0, r1}
10007908:    e88d 0003     stmia.w    sp, {r0, r1}
1000790c:    e894 000f     ldmia.w    r4, {r0, r1, r2, r3}
10007910:    f011 fdc4     bl    1001949c <gpio_write>
10007914:    b004          add    sp, #16
Потом все собрал, выдал результат, только оно не работало, разумеется. Первый вызов gpio_write правильный, во втором я ошибся, но контроль типов почему-то не сработал, компилятор это спокойно переварил. Как вернуть контроль типов? Кстати, IAR на подобное ругается. GCC взят с arm.com
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
Copyright (C) 2016 Free Software Foundation, Inc.
 

pvvx

Активный участник сообщества
Как вернуть контроль типов? Кстати, IAR на подобное ругается. GCC взят с arm.com
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
Copyright (C) 2016 Free Software Foundation, Inc.
Смотрите объявление gpio_write() и опции компилятору. Скорее всего у вас нет объявления void gpio_write(gpio_t *obj, int value), а компилятору не указано орать на не объявленные функции...
Код:
project/src/console/gpio_irq_test.c:83:13: error: incompatible type for argument 1 of 'gpio_write'
  gpio_write(gpio_led, 0);
             ^~~~~~~~
In file included from project/src/console/gpio_irq_test.c:10:0:
USDK/component/common/mbed/hal/gpio_api.h:37:6: note: expected 'gpio_t * {aka struct gpio_s *}' but argument is of type 'gpio_t {aka struct gpio_s}'
 void gpio_write(gpio_t *obj, int value);
      ^~~~~~~~~~
Для большего поставьте опции: -Wall -Werror -Wpedantic -Wextra

Так-же у IAR используется либа rom.a или rom_v01.nodbg.a и нет списка функций ROM в *.ld. Т.е. имеются глобальные различия для сборщика... Большинство параметров к функциям объявлено как * void, что вызывает подобные вещи...
 
Последнее редактирование:
Сверху Снизу