тут стеки, но я уже хер знает че сделать

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

Проходной датчик какой нибудь, но по логике нужно же греть заранее, видел на gps делали, есть софтина на тел gps to mqtt

Ну можно юзать таймеры фриртос. xTimerCreate хотя бы. Они то наверняка должны встать вместе с прошивкой

Qwen3-235B-A22B 10:18 PM 📌 Анализ кода stwd100.c и рекомендации по исправлению проблем 🔍 Проблемы в текущем коде Вы сообщаете, что: • Связь работает через CMUX . • Проблем с сертификатами нет . • TLS-соединение работает только при отключенном таймере STWD100 . • Это указывает на то, что таймер STWD100 мешает работе TLS / MQTT , хотя он не связан напрямую с сетевыми операциями. ❗ Основная проблема: частый вызов gpio_set_level() в контексте таймера Ваш таймер вызывает callback каждые HALF_PERIOD_MS миллисекунд (например, 375 мс), и в нем выполняется: c 9 1 › gpio_set_level(WDI_PIN, state); Так как это статический таймер , запущенный с периодом HALF_PERIOD_MS, он генерирует прерывания и вызывает функцию обратного вызова внутри ядра FreeRTOS. Проблема: Вызов gpio_set_level() в контексте таймера может быть небезопасным , особенно если этот вызов происходит в критических секциях или блокирует выполнение других задач. Кроме того: • Функция xTimerStart() вызывается из stwd100_init(), но неясно, где она используется. • Если период слишком маленький (например, менее 50 мс), это может нарушить работу сетевых задач ESP-IDF , которые чувствительны к частым переключениям контекста. • ✅ Решения и оптимизации 1. Используйте задачу вместо таймера Таймеры в FreeRTOS имеют ограничения — они работают в контексте системной задачи и могут вызывать проблемы с производительностью.

ну хули делать, китайцы говорят, что твоя тема с таймером говно

Хорошо,они молодцы. Однако я не говорил, что оно должно решить проблемы с ТЛС. Это был лишь вопрос к говну которое ты написал вместо таймера. Нравятся таски юзай ради бога, однако гарантировать что таска будет работать так же четко как таймер ровно нуль.

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

Да херня всё это твои приоритеты

Включи лог mbedtls verbose и смотри что ему не нравится

Может глупый вопрос задам, без tls вариантов нет попробовать?

Может глупый вопрос задам, без tls вариантов нет попробовать?

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

через CMUX (SIM800L)

Таки понятно что это узкое место

Таки понятно что это узкое место

код ебейшей таски, которая убивает TLS handshake: static void task(void *pv_parameter) { (void)pv_parameter; uint16_t state = 0; TickType_t delay = pdMS_TO_TICKS(HALF_PERIOD_MS); while (true) { gpio_set_level(WDI_PIN, ++state % 2); vTaskDelay(delay); } }

https://github.com/espressif/esp-idf/issues/11728 It seems the TCP SYN is no response. Could you confirm that the PPPoS module is access to Internet. Besides, you can ping your PPP IP to check the PPP connection is OK.

А ты таске стек то сколько выставил кстати?

2к, пробовал 8к, разницы никакой

код ебейшей таски, которая убивает TLS handshake: static void task(void *pv_parameter) { (void)pv_parameter; uint16_t state = 0; TickType_t delay = pdMS_TO_TICKS(HALF_PERIOD_MS); while (true) { gpio_set_level(WDI_PIN, ++state % 2); vTaskDelay(delay); } }

ну, хотя бы хип увеличил в процессе скачек, раньше рекорд был 135 после старта всего, щас 150

вот и меня удивляет, как банальная задача ломает всё...

вот и меня удивляет, как банальная задача ломает всё...

Странно что это такое там вы делаете, у нас 140кб памяти Занято 40кб И связь по ppp Несколько сокетов И async тасков куча, и каждый модуль логируется, и хз чем ещё хеп забивать то?

она что-то стопит во время дерганья пина и переключения контекста на время делэя

I (19:15:07.272) MQTT: Heap info: Heap summary for capabilities 0x00001000: At 0x3ffae6e0 len 6432 free 0 allocated 5308 min_free 0 largest_free_block 0 alloc_blocks 37 free_blocks 0 total_blocks 37 At 0x3ffb36d8 len 182568 free 55560 allocated 118932 min_free 5732 largest_free_block 49136 alloc_blocks 356 free_blocks 16 total_blocks 372 At 0x3ffe0440 len 129984 free 129096 allocated 0 min_free 129096 largest_free_block 126960 alloc_blocks 0 free_blocks 1 total_blocks 1 At 0x3ff80000 len 8192 free 7796 allocated 0 min_free 7796 largest_free_block 7664 alloc_blocks 0 free_blocks 1 total_blocks 1 Totals: free 192452 allocated 124240 min_free 142624 largest_free_block 126960 W (19:15:07.336) MQTT: Free heap: 192452

Тут есть одна проблема в фрагментации памяти. Увы, оно не показывает обьем самого длинного участка. И внезапно при соединении с тлс ему нужно длинный кусок чтоб уместить жирную цепочку сертификатов. Вот тут могут быть и роблемы

вот и меня удивляет, как банальная задача ломает всё...

код ебейшей таски, которая убивает TLS handshake: static void task(void *pv_parameter) { (void)pv_parameter; uint16_t state = 0; TickType_t delay = pdMS_TO_TICKS(HALF_PERIOD_MS); while (true) { gpio_set_level(WDI_PIN, ++state % 2); vTaskDelay(delay); } }

А сделай переменные статиками, тож самое?

все переменные или только конкретные?

А сделай переменные статиками, тож самое?

Да ну это уж совсем из разряда хз что делать

Не, оно должно не на стеке выделять

у меня утечек нет пару лет

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

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

чему кстати делей-то равен HALF_PERIOD_MS? если его жирнее сделать, все так же ломается?

Бывает такое что в коде успешно годами все работает, где убежал за указатель. А когда добавляются новые вводные… вот тут сюрприз

И ты отлаживаешь то, что не является причиной ошибки. Не один раз такое было

В итоге тот указатель начинает тереть совсем другой кусок памяти…

Фигачь все в глобальные переменные))

Я скока раз попадался раньше, когда забывал в строках выделить x+1 вместо x. По итогу оно при новых вводных заезжало этим nullz на другой кусок памяти, казалось бы все работало годами. А том херак…

Если вы поняли о чем я