RTL00 MP3 player

[pvvx]

Поясните пожалуйста всем, как так у вас vTaskDelay(10000) блокирует xQueue?

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

 

[pvvx]

Повторю: очередь работает исправно, в рамках очереди пакеты не теряются и последовательно обрабатываются, очередь исправно опустошается, только при переполнении очереди, она уже не пополняется.

И что же происходит? Больше ничего LwIP не принимает или ?

pvvx видимо привык костылить код, вот у него из-за любого чиха какие-то костыли и начинают падать и он считает это нормальным

У меня то не падает. Наверно спутали с собой - вы же про это и пишите, что что-то у вас падает.

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

Работает Web на RTL и каждые 180 ms считываестся файл для графика…
В netbios_recv() вставлена любимая Neov vTaskDelay(10000);

Передаем пакет UDP в порт 137. Процесс встает на 10 сек…
Передаем несколько пакетов в порт 137, процесс обработки встает на n-пакетов умноженных на 10 сек:

Никаких глюков не наблюдается, кроме указанных: блокировки входящих пакетов и не исполнения калбеков. Т.е. созданные для оправдания выкрутасы Neov не проходят.

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

 

[Neov]

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

Если уж беретесь отвечать на сообщения, читайте его внимательно, медленно, вслух и по слогам. Повторить несколько раз до глубокого осмысления.

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

Это не задача и я её не решаю. Была промоделирована отказоутойчивость стека tcp/ip

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

Совершенно не аналогичная ситуация. Все же задержки прерывания и задержки задачи ОС отличаются.

Дальнейший разбор не имеет смысла - уже показано, что это для вас пока бесполезно. Изучите 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. Дело наживное, но вы за это вините меня

 

[pvvx]

Если уж беретесь отвечать на сообщения, читайте его внимательно, медленно, вслух и по слогам. Повторить несколько раз до глубокого осмысления.

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

 

[Neov]

вы уговариваете всех что LwIP падает, какие-то ошибки, читают вас не так и т.д., но демонстрации, т.е. фактов никаких не даете.

Во вложении, там же пистон скрипт для Udp рассылки.
1. Собираете (либо берите готовый ram_all)
2. Запускаете на модуле
3. Запускаете udp.py

вы за это вините меня

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

 

[pvvx]

Во вложении, там же пистон скрипт для Udp рассылки.

Позже гляну...

Вас никто не обвинял (разве что, вы криво читаете).

Это указано вами в сообщении в 36538.

 

[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 паузами и пачками...

 

[Neov]

Далее передавал на RTL порт 777 текст test1, test2, test3 c паузами и пачками...

Именно, у меня остановился на test7, больше пакеты не лезли.

 

[Neov]

Это указано вами в сообщении в 36538.

Это сообщение rst, да и на обвинение это тоже мало похоже

 

[pvvx]

У Neov новая отмазка
100500 хватит?

Это так и висит в модуле первый запуск после первой трансляции вашего main.c.
Можно ещё туда что заслать... Никаких бед.

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

 

[pvvx]

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

Так всё и пашет, после пачки UDP, набив указанный размер очереди в конфиге (n * 10 сек), прием возобновляется... Но пока очередь забита, ничего другого входящего LwIP не разбирает и калбаков к ним не вызывает.

 

[sharikov]

Neov - вы неправильно ломаете LwIP. Я вам написал, что надо достигнуть заполнения всего Heap буферами LwIP, задав ему неправильные настройки для вашего проекта. Тогда возможно что и накроется, т.к. в SDK

Я проверял. При динамических буферах если кончится heap wifi накроется и не восстановится даже после освобождения памяти - после этого только ресет. Ранее запущенные процессы при этом работают. При статических буферах в lwip корректно отрабатывает проверка на исчерпание памяти и краха не происходит.

 

[Neov]

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

 

[pvvx]

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

Вы нашли баг в этом (?):

Поясните пожалуйста всем, как так у вас vTaskDelay(10000) блокирует xQueue?

Обясняю xQueue - это не бездонное FIFO.

@pvvx добрее надо быть

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

 

[pvvx]

Я проверял. При динамических буферах если кончится heap wifi накроется и не восстановится даже после освобождения памяти - после этого только ресет. Ранее запущенные процессы при этом работают. При статических буферах в lwip корректно отрабатывает проверка на исчерпание памяти и краха не происходит.

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

 

[Neov]

Набалоболи кучю

действуя на незнании некой специфики другими

Нехорошо

Подозрения на панические атаки - так и запишите

В вашей теме вам уже многие указали - не стоит врать. Там прямо в шапке сплошной бред.

А другая тема не относящаяся к вопросу то при чем? Нарушение ассоциативности мышления - тоже запишите.

А мне на рейтинги нас..ть.

На культ личности pvvx вам явно не нас..ть. Мания величия - тоже следует записать.

 

[pvvx]

Подозрения на панические атаки - так и запишите

Где атака? Опять спутали своё с чужим.

А другая тема не относящаяся к вопросу то при чем? Нарушение ассоциативности мышления - тоже запишите.

Тут это повторилось. Поэтому и рекомендован уже "стационар".

На культ личности pvvx вам явно не нас..ть. Мания величия - тоже следует записать.

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

 

[Neov]

Вас то волнует типа PR индекс.

Слишком сырые у вас взгляды и ориентированы только на публику

играете роль тупого тролля, с багажом ужасных комплексов...

Ещё запишите: параноидальное расстройство личности.

 

[pvvx]

Ещё запишите: параноидальное расстройство личности.

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