Andy кстати, где-то на уровне TCP часть данных теряется - на стороне TCP клиента в случайные моменты времени приходит меньше байт, чем должно придти, и это значение случайное: receive timeout 64644 receive timeout 70853 receive timeout 56064 receive timeout 65837 receive timeout 72437 receive timeout 63062 receive timeout 71116 receive timeout 64648 receive timeout 63855

При этом должно приходить всегда 72704 байт, а передача и прием через сокет исключительно по 1024 байта. Выходит - эти чипы не надежные и нельзя применять?

tcp - это поток - там нет понятия пакета

Так я и работаю как с потоком - считываю по 1024 байта, пока не наберу 72704

tcp - это поток - там нет понятия пакета

while total < length: chunk = client.recv(1024) if chunk == None or len(chunk) == 0: break byteBuffer = byteBuffer + chunk total = total + len(chunk) received_total = total

Только клиент на питоне, но разницы же нет - так везде делают

len(chunk) == 0 скорее всего лишнее

ок, уберу

хотя я не пишу на питоне - не знаю что там recv возвращает

это python

обычный системный вызов recv возвращает 0 когда сокет закрыт с той стороны

Andy Попробовал с IDF 4.3 - даже 10 минут не продержался на тесте с периодическими запросами и ответами, как обычно - перестает подключаться к точке доступа. Прикладываю код: https://paste.ofcode.org/cmY4wVQ9sBKGgK34UjYtky

Вот тут отправляйте в очередь, а в отдельной задаче отправляйте в UART. Аналогично и с приемом по UART

Хм, но здесь нет узкого места - там запрос это 10 байт

А вот ответ (прием по UART) - это 72704 байта

Andy похоже кто-то съедает heap и после этого отваливается wifi: Free Heap 42140 - после глюка, а после резета: Free Heap 96160

Скорее всего это и есть причина "засора" Где-то получаем ESP_ERR_NOT_MEMO и все рушится

ага, ок, тогда получается эта задачка может быть нерешаемой, если используется ОГРОМНЫЙ приемный буфер по uart

т.к. RAM нехватит

Хм, но здесь нет узкого места - там запрос это 10 байт

Если закоментировать, то продолжает падать? Если да, то я не прав

тогда я не смогу тест запустить вообще, если закомменотирую))

Там запрос по TCP -> UART, далее другое устройство (эмулятор) отвечает в UART -> TCP

Скорее всего это и есть причина "засора" Где-то получаем ESP_ERR_NOT_MEMO и все рушится

вот опасаюсь, что из-за мелкого приемного буфера на UART будут проблемы с его переполнением из-за каких-нибудь сетевых задержке и мне прям не обойтись без буфера на 73 кб

вот опасаюсь, что из-за мелкого приемного буфера на UART будут проблемы с его переполнением из-за каких-нибудь сетевых задержке и мне прям не обойтись без буфера на 73 кб

Вам прям нужен непрерывный буфер? Протокол обмена с "соседним" устройством UART должен соблюдать временные интервалы? Если, да, то только увеличение ОЗУ спасет. :)

Вам прям нужен непрерывный буфер? Протокол обмена с "соседним" устройством UART должен соблюдать временные интервалы? Если, да, то только увеличение ОЗУ спасет. :)

Устройство просто отвечает сразу 73 кб и всё, больше оно ничего не умеет. Может получится где-то сэкономить RAM...

Вам прям нужен непрерывный буфер? Протокол обмена с "соседним" устройством UART должен соблюдать временные интервалы? Если, да, то только увеличение ОЗУ спасет. :)

скорее, пока висим в send(sock,...) буфер юарта может переполниться

Устройство просто отвечает сразу 73 кб и всё, больше оно ничего не умеет. Может получится где-то сэкономить RAM...

Тогда точно нужна ОЗУ :( т.к. у вас 96 Кб heap всего после сброса. (Не знаю размера стэка для задач FreeRTOS)

Тогда точно нужна ОЗУ :( т.к. у вас 96 Кб heap всего после сброса. (Не знаю размера стэка для задач FreeRTOS)

Надо 2 буфера минимум

это плохо, т.к. его еще найти надо и разобраться...

кстати уже 500/500 передач по 73 кб, с uart rx buffer 8192 и полет нормальный

и если честно - сразу в глаза бросилось - static volatile int sock - пишет и читает из разных задач, судя по всему задачи могут на любом ядре esp выполняться - ((((

они на одном ядре, по умолчанию

и если честно - сразу в глаза бросилось - static volatile int sock - пишет и читает из разных задач, судя по всему задачи могут на любом ядре esp выполняться - ((((

Это нужно указывать при создании таска. У меня на одном ядре два таска на один сокет и норм

вот уже 1 сбой: 72696 байт принято вместо 72704, но может из-за uart, потому что буфер короткий...

А при передаче через send(sock,..) по 1024 байт - это с подтверждением после каждого чанка по 1024 байт происходит? Т.е. отправили 1024 - получили подтверждение, дальше уже после отправили еще и т.п.?

друзья, всех приветствую. перешел с ардуино иде на платформио+вскод, импортировал первый ардуино проект, при компиляции получаю ошибку

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

этот файл, на который оно ругается существует и я могу его открыть

подскажите, что я делаю не так?

можете подсказать, что это за маразм ? как-бы, явно проверяем на нан, и если не нан то печатаем каким ...... там оказывается нан после условия?

подскажите, что я делаю не так?

Надо прописать путь к нему в настройках проекта

Нужно компилятору указать, где искать файл. Можно через файлы сборки, можно через проект, он сам добавит.

друзья, всех приветствую. перешел с ардуино иде на платформио+вскод, импортировал первый ардуино проект, при компиляции получаю ошибку

я вот тоже перешел но пишу код в вс код с платформио а компилирую и шью через ардуино иде

Нужно компилятору указать, где искать файл. Можно через файлы сборки, можно через проект, он сам добавит.

а норма, что он не может найти только этот файл? все остальные библиотеки он почему то скомпилил без моей помощи

можете подсказать, что это за маразм ? как-бы, явно проверяем на нан, и если не нан то печатаем каким ...... там оказывается нан после условия?

Посмотреть, что за макрос NAN

а норма, что он не может найти только этот файл? все остальные библиотеки он почему то скомпилил без моей помощи

Если он лежит, там же где и другие используемые файлы, то странно. Хотя он может на первом файле останавливаться.

Посмотреть, что за макрос NAN

Посмотреть, что за макрос NAN

функция voltage может вернуть только либо флоат либо этот же нан

Всё таки это макрос

Нельзя никогда сравнивать с NAN

Нельзя никогда сравнивать с NAN

так в документации к модулю но да ладно, как тогда надо?

есть методы для проверки isnan

так в документации к модулю но да ладно, как тогда надо?

как понять что там выходит в консоль с чем сравнить?

if(isnan(voltadge)) как то так

if(isnan(voltadge)) как то так

благодарствую

Вот такую забавную вещь нашел - предлагают подрегулировать этот параметр. Попробовал пока 30 вместо 120, наблюдаю... Может кстати и не на уровне TCP теряются байтики, на UART тоже жалобы есть, от 460800 и выше.

кстати, а почему uart_event не используешь ?

кстати, а почему uart_event не используешь ?

Как это работает?

Вызывается callback, когда буфер заполнен?

https://github.com/espressif/esp-idf/blob/master/examples/peripherals/uart/uart_events/main/uart_events_example_main.c

ну примерно так, заодно и все ошибки uart можно определить

ну примерно так, заодно и все ошибки uart можно определить

Хм, а это зачем, чтобы меньше тасков создавать?

честный асинхронный прием в от одельном таске и дальше в очередь на отправку в сокет, и из очереди в tcpip, если конечно данные из уарта не нужно обрабатывать.

Всем привет! Кто нибудь работал с датчиками влажности почвы на 1 wire?

вообще есть ли такие

Всем привет! Кто нибудь работал с датчиками влажности почвы на 1 wire?

https://aliexpress.ru/item/32832538686.html?gatewayAdapt=glo2rus Емкостной должен быть норм.

Так я и работаю как с потоком - считываю по 1024 байта, пока не наберу 72704

Я что-то нигде не увидел проверки на EAGAIN

Я что-то нигде не увидел проверки на EAGAIN

Это разве не для nonblocking io? У меня вариант блокирующий

Это разве не для nonblocking io? У меня вариант блокирующий

теоретически, сигнал может прилететь и прервать поток

Кстати, пока 3023/3023 отправки без сбоев, уменьших rx fifo threshold до 30 вместо 120 по умолчанию

для нонблокинг это вообще обязательная проверка. но и для блокинг при посылке проверять бы

Andy похоже кто-то съедает heap и после этого отваливается wifi: Free Heap 42140 - после глюка, а после резета: Free Heap 96160

Подозрительно мало памяти сразу после сброса. Много других задач ещё крутятся?

Это разве не для nonblocking io? У меня вариант блокирующий

ну вот точно когда для блокирующегося сокета бывает еэгейн: It's possible that you have a nonzero receive timeout set on the socket (via setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,...)) as that would also cause recv to return EAGAIN

с посылками еэгейн бывает независимо от типа сокета, просто, например, все буфера тцп уже полные и твои данные пихнуть некуда

о, я немного вчитался в программу. один сокет из двух параллельных тасков, без блокировок и селектов. это повод ругать есп32 и его идф...

Не только для esp, у всех +- так

либо в 0% либо в 100% не убирается

3676/3676 шт по 73 кб - пока без зависаний и потерь байтиков, чудеса!, uart rx fifo 73 kb, rx fifo threshold 30 вместо 120

Парни, есть у кого установленный микропайтон на Есп32/8266? Попробуйте сделать From urequests Import md5 Не получается нативную либу импортнуть. причем вместо md5 легко импортятся sha256 и sha1

Так и не могу разобраться с авторизацией digest с шифрованием md5. Помогите плс? По моему понимаеию присутствует ошибка в либе

https://aliexpress.ru/item/32832538686.html?gatewayAdapt=glo2rus Емкостной должен быть норм.

просто мне нужно чтобы датчик работал на 15-20 метровом проводе