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

RTL00 MP3 player

pvvx

Активный участник сообщества
Поясните пожалуйста всем, как так у вас vTaskDelay(10000) блокирует xQueue? :)
Открываете RTOS и читаете. Вникаете и получаете, что если за время остановки в 10 секунд, придут новые пакеты, то xQueue заполняется т.к. не вызывается xQueueReceive в треде, который вы остановили на 10 сек. Вся обработка входящих пакетов останавливается. Вам уже указал, что данное xQueue (mbox) может обрабатываться другими тредами, при условии изменения конфигурации LwIP и дописывания специальных макросов. Но это может только частично помочь в вашей задаче, которую вы пока решаете через зад – получения всегда последнего пришедшего пакета UDP и длительная его обработка, с пропуском приходящих за время обработки.
Ещё раз – что будет, если в прерывание приема символов от UART вставить vTaskDelay(10000) ? Это совершенно аналогичная ситуация, того, что вы делетае. :p
Дальнейший разбор не имеет смысла - уже показано, что это для вас пока бесполезно. Изучите RTOS и программирование...
 

pvvx

Активный участник сообщества
Повторю: очередь работает исправно, в рамках очереди пакеты не теряются и последовательно обрабатываются, очередь исправно опустошается, только при переполнении очереди, она уже не пополняется.
И что же происходит? Больше ничего LwIP не принимает или ?
pvvx видимо привык костылить код, вот у него из-за любого чиха какие-то костыли и начинают падать и он считает это нормальным :D
У меня то не падает. Наверно спутали с собой - вы же про это и пишите, что что-то у вас падает. :)

Специальный тест, для выдумщика и обманщика Neov.

Работает Web на RTL и каждые 180 ms считываестся файл для графика…
В netbios_recv() вставлена любимая Neov vTaskDelay(10000);
Снимок1475.gif
Передаем пакет UDP в порт 137. Процесс встает на 10 сек…
Передаем несколько пакетов в порт 137, процесс обработки встает на n-пакетов умноженных на 10 сек:
Никаких глюков не наблюдается, кроме указанных: блокировки входящих пакетов и не исполнения калбеков. Т.е. созданные для оправдания выкрутасы Neov не проходят.

Из этого следует, что воспринимать выдумки и ложь от Neov, создаваемые с целью затрат чужого времени на проверки, больше не стоит. Видимо в Neov, при "портировании", закралась какая-то ошибка :)
 
Последнее редактирование:

Neov

Member
Открываете RTOS и читаете. Вникаете и получаете, что если за время остановки в 10 секунд, придут новые пакеты, то xQueue заполняется т.к. не вызывается xQueueReceive в треде, который вы остановили на 10 сек. Вся обработка входящих пакетов останавливается. Вам уже указал, что данное xQueue (mbox) может обрабатываться другими тредами, при условии изменения конфигурации LwIP и дописывания специальных макросов.
Если уж беретесь отвечать на сообщения, читайте его внимательно, медленно, вслух и по слогам. Повторить несколько раз до глубокого осмысления.

Но это может только частично помочь в вашей задаче, которую вы пока решаете через зад – получения всегда последнего пришедшего пакета UDP и длительная его обработка, с пропуском приходящих за время обработки.
Это не задача и я её не решаю. Была промоделирована отказоутойчивость стека tcp/ip

Ещё раз – что будет, если в прерывание приема символов от UART вставить vTaskDelay(10000) ? Это совершенно аналогичная ситуация, того, что вы делетае. :p
Совершенно не аналогичная ситуация. Все же задержки прерывания и задержки задачи ОС отличаются.

Дальнейший разбор не имеет смысла - уже показано, что это для вас пока бесполезно. Изучите RTOS и программирование...
Дальнейший разбор не имеет смысла, если проблемы с чтением.

Я уже приводил примитивный cb повешенный на udp. И факт есть факт: при переполнении mbox , lwip падает. Мне врать/клеветать смысла нет, по мне так работает - я рад:)
 

pvvx

Активный участник сообщества
Я уже приводил примитивный cb повешенный на udp. И факт есть факт: при переполнении mbox , lwip падает. Мне врать/клеветать смысла нет, по мне так работает - я рад:)
Ага - новая выдумка. Работает и не работает. :)
Код вам приведет и два раза. И странно - он работает, так как и описал, а вы уговариваете всех что LwIP падает, какие-то ошибки, читают вас не так и т.д., но демонстрации, т.е. фактов никаких не даете. Не кажется это странным и больным?
Могу вам напомнить - у WDT тоже по умолчанию в текущих сборках демо-проектов стоит 10 сек и если у вас там какие задачи не отдают тиков до IDLE за это время и сами не обеспокоились поддержкой сброса WDT или отключения WDT, то ваше любимое ожидание по времени тоже имеет 10 сек, что очень сходится... А так-же вам указана строчка, после вывода которой в LogUART (о каюк "heap") может произойти сбой системы при вашем тесте - причина: вы неверно задали параметры LwIP в своем проекте... Для этого опции LwIP и прочие важные для каждого взятого примера-проекта, в моей сборке SDK вынесены в каталог проекта пользователя (RTL00MP3\project\inc\lwipopts.h)
Но это уже поиск и гадание ваших ошибок, а не имеющихся в программе по обсуждаемой теме.
И основная причина ваших виляний и подтасовок – незнание как работает LwIP и RTOS. Дело наживное, но вы за это вините меня :p
 
Последнее редактирование:

pvvx

Активный участник сообщества
Если уж беретесь отвечать на сообщения, читайте его внимательно, медленно, вслух и по слогам. Повторить несколько раз до глубокого осмысления.
Вот и повторяйте, если беретесь что-то выдвигать и утверждать. Ответ вам дан 100% и на простом языке, понятным всем - переводов не требуется (это чтобы вы не упрекали меня в том, что непонятно написано :) ).
 

Neov

Member
вы уговариваете всех что LwIP падает, какие-то ошибки, читают вас не так и т.д., но демонстрации, т.е. фактов никаких не даете.
Во вложении, там же пистон скрипт для Udp рассылки.
1. Собираете (либо берите готовый ram_all)
2. Запускаете на модуле
3. Запускаете udp.py

вы за это вините меня :p
Это ещё одна ваша цитата, которая достойна чтобы занести в вашу мед карту. Вас никто не обвинял (разве что, вы криво читаете). Опыт с lwip действительно не гигантский, если укажете в чем ошибка, буду рад.
 

Вложения

pvvx

Активный участник сообщества
Код:
===== Enter SRAM-Boot 1 ====
CPU CLK: 83333333 Hz, SOC FUNC EN: 0x20111157
Img Sign: RTKWin, Go @ 0x10006065
===== Enter Image: 4pvvx ====
....
Station ip: 192.168.1.122
lwip_test: Current task name user_init

RTL8195A[Driver]: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1
udp received: test. Delay 10 sec...
Delay
udp received: test1. Delay 10 sec...
Delay
udp received: test2. Delay 10 sec...
Delay
udp received: test3. Delay 10 sec...
Delay
Передавал-принимал UDP пакеты прогой из выше видео, собирал проект своим сборщиком.
При старте по порту 7878 приходит [inline]Receive from 192.168.1.122 : 7777: helo[/inline]
Далее передавал на RTL порт 777 текст test1, test2, test3 c паузами и пачками...
 
Последнее редактирование:

pvvx

Активный участник сообщества
У Neov новая отмазка :)
100500 хватит?
Снимок1477.gif Снимок1478.gif
Это так и висит в модуле первый запуск после первой трансляции вашего main.c.
Можно ещё туда что заслать... Никаких бед.

PS: Обновления в git моей сборки SDK остановлены с момента выдумки Neov, для чистоты экспа.
Можно дальше обновить, а то накопилось много добавок, не связанных с болезнью Neov? :)
И напомню - в других проектах-примерах к RTL на git, используется SDK из RTL00MP3 и почти каждое обновление несет смену пользовательских хидеров. Это не имеет связи с болезнью Neov, но при использовании необходимо (желательно) синхронизировать основные конфиги в хидерах проектов использующих мою сборку SDK (файлы в project/inc/*.h).
 

pvvx

Активный участник сообщества
Neov - вы неправильно ломаете LwIP. Я вам написал, что надо достигнуть заполнения всего Heap буферами LwIP, задав ему неправильные настройки для вашего проекта. Тогда возможно что и накроется, т.к. в SDK не все процедуры проверяют и корректно обходят неудавшийся запрос памяти. Это находится в закрытых либах и пока не чинил, т.к. смысла в этом нет - при правльно построенных алго самого проекта такого не происходит, а так-же можно вписать свою обработку неудавшегося... .
Чините свой сборщик wav или к дохтуру на стационарные процедуры... :)
Снимок1479.gif
Так всё и пашет, после пачки UDP, набив указанный размер очереди в конфиге (n * 10 сек), прием возобновляется... Но пока очередь забита, ничего другого входящего LwIP не разбирает и калбаков к ним не вызывает.
 
Последнее редактирование:

sharikov

Active member
Neov - вы неправильно ломаете LwIP. Я вам написал, что надо достигнуть заполнения всего Heap буферами LwIP, задав ему неправильные настройки для вашего проекта. Тогда возможно что и накроется, т.к. в SDK
Я проверял. При динамических буферах если кончится heap wifi накроется и не восстановится даже после освобождения памяти - после этого только ресет. Ранее запущенные процессы при этом работают. При статических буферах в lwip корректно отрабатывает проверка на исчерпание памяти и краха не происходит.
 

Neov

Member
обнаружил потенциальный баг в своем коде, когда обрезал его до примера, баг похоже устранился :) Рад что все работает! (правда запускал в AP, в STA пока небыло возможности)
@pvvx добрее надо быть :)
 

pvvx

Активный участник сообщества
обнаружил потенциальный баг в своем коде, когда обрезал его до примера, баг похоже устранился :) Рад что все работает! (правда запускал в AP, в STA пока небыло возможности)
Вы нашли баг в этом (?):
Поясните пожалуйста всем, как так у вас vTaskDelay(10000) блокирует xQueue? :)
Обясняю :) xQueue - это не бездонное FIFO.
@pvvx добрее надо быть :)
Это вы про себя? Набалоболи кучю, обманули, ничего не уточняя и не приводя элементарных примеров, как всегда загадочными и непереводимыми по смыслу сообщениями, чтобы другие гадали, и тут-же валите на других, думая что никто читать и вникать в то что вы написали ранее не будет, действуя на незнании некой специфики другими. Такой стиль троллей уже десятки лет известен. Нехорошо.
В вашей теме вам уже многие указали - не стоит врать. Там прямо в шапке сплошной бред. :) А мне на рейтинги нас..ть. У нас тут другая политика и цели (одна из них: растолковать вопрос индивидууму до его решения) :)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Я проверял. При динамических буферах если кончится heap wifi накроется и не восстановится даже после освобождения памяти - после этого только ресет. Ранее запущенные процессы при этом работают. При статических буферах в lwip корректно отрабатывает проверка на исчерпание памяти и краха не происходит.
При открытии очередного порта-сокета проверяйте heap - это может спасти. Статических буферов на 512 КБ RTL физически не хватает для множества алгоритмов и итог значительно хуже. Для HTTPD это категорически не рекомендуется - не выполнится основная цель - работающий web.
 

Neov

Member
Набалоболи кучю
действуя на незнании некой специфики другими
Подозрения на панические атаки - так и запишите :)
В вашей теме вам уже многие указали - не стоит врать. Там прямо в шапке сплошной бред. :)
А другая тема не относящаяся к вопросу то при чем? Нарушение ассоциативности мышления - тоже запишите.
А мне на рейтинги нас..ть.
На культ личности pvvx вам явно не нас..ть. Мания величия - тоже следует записать.
 

pvvx

Активный участник сообщества
Подозрения на панические атаки - так и запишите :)
Где атака? Опять спутали своё с чужим.
А другая тема не относящаяся к вопросу то при чем? Нарушение ассоциативности мышления - тоже запишите.
Тут это повторилось. Поэтому и рекомендован уже "стационар". :)
На культ личности pvvx вам явно не нас..ть. Мания величия - тоже следует записать.
Ошибка - супер эгоизм, а не ваш мелочный. Различия найдете глубоко изучив оперируемые не верно вами понятия. :p Вас то волнует типа PR индекс. А мне оно не надо... :p Слишком сырые у вас взгляды и ориентированы только на публику, что не дает вам возможности писать правду - вы находитесь в собственном тюремном заключении... :p Итогом является невозможность создания чего-то нового - играете роль тупого тролля, с багажом ужасных комплексов... Короче -> тут уже только стационарное лечение... возможно в следующем поколении приведет к возврату к понятию "человек". А пока являетесь управляемым роботом-троллем низкого уровня - интереса и в этом не представляете...
Я возможно бы смог найти необходимую для вас литературу и опыты других, для вашего излечения, но не вижу в этом смысла (только стационар :)) и не работаю тут дохтуром по данной теме. :)
 
Последнее редактирование:

Neov

Member
Вас то волнует типа PR индекс.
Слишком сырые у вас взгляды и ориентированы только на публику
играете роль тупого тролля, с багажом ужасных комплексов...
Ещё запишите: параноидальное расстройство личности.
 

pvvx

Активный участник сообщества
Ещё запишите: параноидальное расстройство личности.
Кто записывает? В инет и форумах всё автоматом записывается... Бредите уже на яву? Бегом в стационар... :)
------
Кто подкинет короткий JavaScript вывода графика в реал тайм с примерно схожим отображением как у осциллографа?
Принцип примерно такой - RTL websocket отдает массив замеров с индексом (условной меткой времени начального замера в буфере) и на графике надо выводить точки индексируемые номерами индексов, временем каждой точки, а не временем приема. Массив отдается по запросу к websocket на RTL. Буферизация отдаваемых данных в RTL производится циклическим буфером замеров на минимум на 0.7 сек. Пропуск данных запрашиваемой стороной определяется по индексу, метке времени на первый замер в принятом массиве. Размер массива зависит от набранных в него новых замеров, от последнего переданного с учетом переполнения: если была задержка, индекс нового будет = прошлый + кол-во прошлых переданных замеров + пропущенные. Как-бы цели в подсчете средних значений за время с учетом пропусков (которых практически не происходит, т.к. запрос новых данных явно отработается за 0.7 сек в локалке) и отображения бегущего графика. Запросный режим сделан для ускорения передачи потока: следующий запрос избавляет от ожиданий любой алго TCP стека, т.к. несет с собой ACK, заодно дает RTL понять, что опрос оборван и прочее, что сильно сокращает размер кода, алго и можно получить максимальный трансфер, + не надо следить за соединением и нет задержек в обработке входящих пакетов у LwIP как в алгоритмах от начинающего тролля Neov :)
 
Последнее редактирование:
Сверху Снизу