Web-свалка на RTL871x

[aloika]

Неужели трудно поискать сообщение об ошибке, чтобы понять где она появляется?

Трудно. Сообщение об ошибке находится в файле lib_wlan.a (вроде бы). Т.е. исходников сообщения об ошибке нет. То, что вы прочитали - это не тот случай...

Насколько я понимаю природу этой ошибки, имеются некие сокет-буферы (skb), которые как-то используются при приеме и передаче пакетов. Это всё происходит сразу после физического интерфейса на входе в lwip (если говорить о приеме модулем пакета). В какой-то момент по какой-то причине эти буферы оказываются заполненными и прием и передача по интерфейсу прекращаются.

То, что вы прочитали - это если пересылать много пакетов по UDP, то может наступить момент, когда не окажется свободного буфера для очередного пакета. Предлагается сделать паузу, подождать освобождения буфера.
Это описано здесь UDP fast packet transmission – Realtek IoT/Arduino Solution и здесь: UDP throughput error message in LOG UART - RTL8710 Community Forum

Там товарищ kissste предлагает критерий заполненности буфера:

if ( max_local_skb_num - 2 <= skbbuf_used_num || max_skb_buf_num - 2 <= skbdata_used_num ) { wait }

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

or enlarge the skb buffer configuration.

Интересно, что это имеется ввиду?

 

[pvvx]

Запустил я поиск по проекту слова ,"skb_unavailable" и вот что нашлось в файле /RTL00_WEB/USDK/component/common/example/bcast/readme.txt:
Note:
If you encounter some message like:
ERROR: sendto broadcast
[Driver]: skb_unavailable=1 in last 2 seconds
It means that the skb buffer is not enough for the massive UDP packets to be sent.
If you want to prevent the error you can add some delay time between sending packets or enlarge the skb buffer configuration.

Неужели трудно поискать сообщение об ошибке, чтобы понять где она появляется?

Это всё уже обжевывалось и в рот положено. Переполнение этих буферов бывает и при малых пакетиках, но часто следующих и демонстрации уже были...
Но пользователь считает, что он всегда прав, когда ещё нет товара и он его не оплатил
Ну а т.к. тут не торгуют за $, то обмена в местной валюте (информации) пользователем не представлено.
Та и буфера тут не при делах - это всего следствия других действий...
В итоге пользователю напеваю песни вокруг да около:
Вот сегодня, к примеру, "проапгредил" BIOS у мамки на один из Ryzen-ов. В ней 2 Гегбитных сетевухи. После "упграда", при включении и входе в биос одна из них устраивает DDOS в местной проводной интрасети, пока ОСЬ её не исправит. Ложится всё Детям мультики не посмотреть... кроме как непрерывного мигания светодиодков во всех свичах и роутерах по сети (наверно это такая эмуляция новогодних огоньков под ёлку - накиданных на самой плате десятков мигающих светодиодов им показалось мало)... Никакими опциями это дело не устраняетcя, кроме как прошить или переключить на второй чип Flash с резервным старым BIOS. Ну и ещё там с десяток "новогодних" косяков, из-за которых использовать эту новую версию незя... (Сходу пытается зажарить проц превышением напруги за физический предел CPU на 30% - эмуляция питарды?) Так ныне пишут большие корпорации на сегмент средней ценовой категории товара... Что творится в low-cost сфере - вы сами наверняка знаете

 

[pvvx]

Кто может прояснить ситуацию(?) :
Беру ESP12E DevKit и модуль RAK Creator Pro c RAK473 c прошивкой web-свалки.
Установки везде одинаковы: вывод лога отключен, CPU на 160 MHz, WiFi в режиме AP+ST.
Смотрю скорость вывода дампа Flash в dword в меню web.
Получаю:
ESP8266 - вывод 512 килобайт занимает 9..10 секунд (генерация и отсылка текста в 2 МБ):

(230 килобайт в сек)
RTL8711AM - вывод 1024 килобайт занимает 6..7 секунд (генерация и отсылка текста в 4 МБ):

(700 килобайт в сек)
Проверку делаю неоднократно чтобы получить среднее значение, с разным подключением: через роутер к ST модуля, через USB-WiFi к AP модуля.
От куда разница по скорости в 3 раза? Программы то не отличаются...
Это разница от типа CPU? Cortex M3 быстрее Xtensa (Tensilica) CPU в 3 раза в средней задаче?
Подозрение, что сказывается именно архитектурное решение самого SoC...

 

[pvvx]

Походу сравнивал вывод графика в web с INA219 и обнаружил, что TI опять врет. Менял несколько платок с INA219 и разброс максимальных параметров по внутреннему генератору у них выходит за пределы описанные в PDF. Замеры делал на предел опроса датчика при 12 бит (с опросом флага готовности), что дает в среднем около 936 замеров тока и напряжения с самого хорошего датчика в секунду... т.е. ADC TIMING: ADC conversion time 12 bit: typ 532 max 586 μs из PDF (1/(0.000532*2)=939.849624) выполняется не для всех датчиков и в PDF заявлены завышенные характеристики, т.к. проверял только в узкой температуре при +25С и номинале 3.3В. Некоторые INA219 тупят больше, чем указанный max.

 

[GDI]

Я бы грешил на китайские платы, может они туда отбраковку ставят, отсюда и разброс параметров. Купите пару микросхем у TI или семплами закажите.

 

[pvvx]

Я бы грешил на китайские платы, может они туда отбраковку ставят, отсюда и разброс параметров. Купите пару микросхем у TI или семплами закажите.

Тут не такие и большие отклонения, чтобы ругаться. Бывают и хуже, как пример, неверная инициализация внутренних триггеров при включении питания у более сложной микросхемы приводящая к плавающим глюкам если не использовать аппаратный сброс. Использование с подключенным к Vcc reset при этом нормировано в документации от TI... Это ошибка TI встретившая в этом году и повлекшая доп.затраты в размерах более полумиллиона руб у нашей фирмы (выезды на объекты и замена ПО). Ну и других ошибок у TI всегда было достаточно.
У того, кто ничего не делает и ошибок нет. TI просто любит завышать параметры для "рекламной борьбы с конкурентами" и представлять данные без учета побочек Другие большие конторы чаще занижают характеристики и стараются выпускать errata в общий доступ побыстрее...

А с INA219 – просто для примера решил сделать опрос по таймеру, выставил и отработал время таймера на первом модуле с уверенностью, что другие микрухи INA219 не будут отличаться от указанного в PDF “типичное” время оцифровки. Но вставив другой модуль с INA пошли дырки… Ну а т.к. из этого не стрелять, а просто тупой пример для тестов и проб – надо как-то подстроить время для серии, а для этого надо определиться с разбраковкой... Думал, что замер влезет в какой-то кратный шаг типа 1 мс… Но не выходит, а хотелось бы просто отладить саму систему передачи/обработки для построения графиков с 1000 sps, а под руку попался INA219...

 

[GDI]

Лично я всегда беру запас относительно каких то параметров как раз на такой случай.

 

[pvvx]

Лично я всегда беру запас относительно каких то параметров как раз на такой случай.

Тут хотелось то 1000 точек графика в сек, чтобы освоить рубеж в построении графиков с использованием web/html/websocket c javascript с точками в 1 мс. Сколько уже можно одну точку в сек мусолить...
А измеряющие другие физ.явления датчики как-то не катят для тысячи точек - от температуры или влажности столько не требуется...
Акселерометры выводить на график тоже нет нужды... В основном такие замеры и с большей дискретностью снимают с ADC. Но более практично для примера (и в хозяйстве пригодятся) именно графики тока и напряжения, да и цена, доступность, простота включения модулей с али на INA219 как раз сгодится...
В трафик WiFi HT40 у RTL-ок и местной интрасети с 1000 точками в сек через websocket мы не упираемся. Общий поток может достигать 1.8 МБайт/сек в TCP. Чтобы дать ещё кому-то работать на канале, если взять на данное дело 20% трафика, то имеем более 300 килобайт в сек. Этого достаточно для передачи более 150 каналов/источников c дискретом в 1 мс при 16 битных замерах
Проблема в либах графиков на javascript. Они тянут всего до 5..10 тысяч точек при плавном скроллинге графика (уровень среднего компа и хорошего смартфона). Это очень мало и надо их дорабатывать... На нереальных измерениях выходит одна ерунда. По тому и надо какой-то базовый пример варианта устройства, годящийся для реальных измерений и работы с ним для отработки... А загубить скорость опроса всегда можно.

 

[sharikov]

Тут хотелось то 1000 точек графика в сек, чтобы освоить рубеж

Как вы смотрите измерения с потоком 1000 точек в сек ?
Признавайтесь вы человек или кто ?

 

[pvvx]

Как вы смотрите измерения с потоком 1000 точек в сек ?
Признавайтесь вы человек или кто ?

Очень просто - если писать специальное приложение на комп, то оно от осциллографа не отличается. Отображаете в каждую току реального разрешения графика в окне вывода в виде 3-х - среднюю за период графической точки и мин + мах с заливкой.
Чудесно смотрится и ползет... Ничего не пропустите Остановите и развернете (масштабируете) интересный кусок... Но все пока имеющиеся javascript либы с графиками не успевает обработать нормальный требуемый для большинства процессов период (от десятков секунд) набора со сдвигом в виде постоянного потока... т.к. рассчитаны на показ статических графиков или потока в виде одной точки в сек Они мигают, переливаются, тормозят, прыгает масштаб и прочие бяки. Как специально сделаны чтобы не работать нормально (кривые алго). Писать самому в лом, но явно это всё успеет любой современный смарт или средний комп (у них у всех есть даже графические ускорители и 3D игры играют, а тут псего 1000 точек в сек !). Надежда найти готовую граф.либу на javascript-е и правильно работающую в описанных планах - ещё не умерла. Ну и маюсь пока...
Мне не интересно капаться в решениях того века, как это делаете вы. На дворе уже всё другое и динамическое отображение любых структур должно быть проработано на уровень бытового плана. Производительности любой козявки/MCU уже достаточна для таких дел.

 

[Alexey_new]

Продолжаю разбираться с серверной частью, дошел до WebSocket-а. Не понятно, зачем там сделан регулярный обмен текстовыми сообщениями клиента с сервером ("wsing" - "wsong")? Каждые 2,5сек. Вроде бы они не нужны, или без них будут проблемы?

 

[kab]

Продолжаю разбираться с серверной частью, дошел до WebSocket-а. Не понятно, зачем там сделан регулярный обмен текстовыми сообщениями клиента с сервером ("wsing" - "wsong")? Каждые 2,5сек. Вроде бы они не нужны, или без них будут проблемы?

Вроде бы ESP автоматически разрывает коннект когда время простоя превышает заданное(пороговое)

 

[pvvx]

Вроде бы ESP автоматически разрывает коннект когда время простоя превышает заданное(пороговое)

Соединение многие разрывают, если нет активности (или впадают в спячку).
А тут, в Web - он сам иначе разорвет соединение, если не будет активности, при настройке по умолчанию в 5 сек. Зачем ему "висящие" клиенты?
В базовой редакции websocket есть специальный ping-pong, но его игнорировали.

 

[aloika]

Это всё уже обжевывалось и в рот положено. Переполнение этих буферов бывает и при малых пакетиках, но часто следующих и демонстрации уже были...
Но пользователь считает, что он всегда прав, когда ещё нет товара и он его не оплатил
Ну а т.к. тут не торгуют за $, то обмена в местной валюте (информации) пользователем не представлено.
Та и буфера тут не при делах - это всего следствия других действий...

Дорогой pvvx, вы были правы. Дело действительно не в буферах. Вы (как и остальные присутствующие) меня сейчас запозорите, наверное, и тоже будете правы.

Так вот.

Я запитал модуль от отдельного хорошего блока питания, и глюк пропал. Уже вторые сутки работает без нареканий. Дело было в питании.

 

[A_D]

Дорогой pvvx, вы были правы. Дело действительно не в буферах. Вы (как и остальные присутствующие) меня сейчас запозорите, наверное, и тоже будете правы.
Так вот.
Я запитал модуль от отдельного хорошего блока питания, и глюк пропал. Уже вторые сутки работает без нареканий. Дело было в питании.

Главное нашли причину и отписались о решении! А это опыт для всех (никто не застрахован от ошибок, наоборот - они как раз и набивают шишек и опыта).

 

[pvvx]

Я запитал модуль от отдельного хорошего блока питания, и глюк пропал. Уже вторые сутки работает без нареканий. Дело было в питании.

А что вы хотите от HT40 PHY при полном трансфере? Там должно валить за 250 мА. Для TCP это уже к 1.8 Мегабайта в сек, а не 1.2 как у ESP8266 при максимуме её возможностей при том-же потреблении...
Ущё о потреблении: У RTL при работе AP немного больше жручка, т.к. она выдает beacon более длинный, c множеством параметров, в отличии от укороченного в предел у ESP. А он передается на самой низкой скорости модуляции для совместимости со всем устаревшим и на это уходит время передачи больше чем на пакет HT40 ... Это тоже может давать импульсы по питанию, если даже ничего не делается..
Рад за вас, что нашли причину, а то я уже кучу потрохов в стыке дров перекопал, но не нашел ничего. Вчера специально полез в https://esp8266.ru/forum/threads/povtoritel-na-esp8266.273/page-2#post-46764 , чтобы не просто так копаться в поисках ошибок.
Заодно нашел как переключить дрова чтобы работала IP_FORWARD в LwIP. Ameba встроила фильтр пакетов по IP и типу до LwIP - его надо отключать,чтобы заработало общение между netif-ами (ST и AP)...

Для включения работы NAT в lwipopts.h надо менять эти переменные:
#define IP_FORWARD 1
#define IP_NAPT 1
Пока оставил включенными по умолчанию...
Присоединившийся к AP (в режиме AP+ST) будет иметь доступ в сеть ST с 5..6 Мегабит/сек.
В DHCP SoftAP ставить Gateway сети station.

PS: Всё это сообщение и обновление на git передано через RTL NAT... Вроде пашет нормально.

 

[aloika]

PS: Всё это сообщение и обновление на git передано через RTL NAT... Вроде пашет нормально.

RTL NAT работает, здорово!

А вот прошить через jlink в новой версии теперь не получается, пишет следующее:

Flash Info:
Image1Size = 8528
Image1LoadAddr = 0x10000bc8
Image2FlashAddr = 0x0000b000
Image2Size = 269160
Image2LoadAddr = 0x10006000
Image3 - None
Get ImagesSize:
Restoring binary file build/bin/ram_all.bin into memory (0x10000300 to 0x10000320)
Image1Size = 8528
Image1LoadAddr = 0x10000bc8
Image2FlashAddr = 0x0000b000
Restoring binary file build/bin/ram_all.bin into memory (0x10000300 to 0x10000308)
Image2Size = 268760
Image2LoadAddr = 0x10006000
flasher/gdb_wrflash.jlink:144: Error in sourced command file:
Start address is greater than length of binary file build/bin/ram_all.bin.
(gdb) quit

14:37:48 Build Finished (took 1s.788ms)

Поэтому пришлось откатить обратно Makefile и USDK/flasher.

Pvvx, а в чем смысл собирать бинарники питоном? Чем это лучше, чем было?

По питанию - припаял к модулю 100 мкФ танталовый и 1 мкФ керамику, cнова запитал от USB - работает, сбоев нет.

 

[pvvx]

RTL NAT работает, здорово!

Но не совсем. Сложно переключается и в Windows вообще с USB-WiFi свистком не переключается route, пока не отключить и заново включить свисток. Такое если до этого были другие соединения через этот USB-WiFi с модулями без NAT.

А вот прошить через jlink в новой версии теперь не получается, пишет следующее:

Я уже знаю, что ошибка в сборке ram_all.bin, глупая, скоро заменю на git, как до этого доберусь... Когда писал не проверял сборку ram_all.bin. Отдельные бинарники собирает верно...

Pvvx, а в чем смысл собирать бинарники питоном? Чем это лучше, чем было?

Чтобы без путей к gcc работало и так быстрее. Актуально для Arduino и прочих сред типа VS и нет зависимости от типа ОС. В Win10 собираюсь все сборки пустить в WSL... Замучал меня mingw своими багами и фичами... А там посмотрим...

 

[aloika]

Я уже знаю, что ошибка в сборке ram_all.bin, глупая, скоро заменю на git, как до этого доберусь... Когда писал не проверял сборку ram_all.bin. Отдельные бинарники собирает верно...

Осталась ошибка, всё равно не работает.

Вот бинарники из одних и тех же исходников:

Бинарник, собранный по-старому (нормально грузится): ram_all-old.bin
Бинарник, собранный по-новому (не грузится): ram_all.bin

 

[pvvx]

Осталась ошибка, всё равно не работает.

Вот бинарники из одних и тех же исходников:

Бинарник, собранный по-старому (нормально грузится): ram_all-old.bin
Бинарник, собранный по-новому (не грузится): ram_all.bin

Вы бы конкретней писали. Какой модуль?
С загрузкой sdram блока была неучтенка в rtl_boot.c (разные версии для моих сборок SDK3.5 и 4.0 - короче напутал там...)

Сравнение файлов ram_all-old.bin и RAM_ALL.BIN
0000215C: 00 FF
.....
0000AFFF: 00 FF
FC: ram_all-old.bin длиннее, чем RAM_ALL.BIN

Т.е. они не отличаются. Часть заполненная нулями не пишется. Но на всякий случай в новой версии поменял на заполнение 0xff. Не работает у вас по причине ошибки в boot. Даже не ошибки, а фичи - чем должен оканчиваться список загружаемых image? В новой версии ввел доп. проверку.
В итоге виновна не сборка в rtlaimage, а код, прописанный в boot