У меня регулятор температуры в картошке работал нормально. Три DS18B20 и wemos d1 mini. После ремонта в подьезде показания термометров стали хаотично "прыгать" на -127°, как при обрыве цепи. Найти причину помех не сумел. Менял плату и датчики. Как защититься от этого?

Какая схема? - питание и данные. Все работало и все заменил Внешнее воздействие!

Точно! Была дезинфекция. Обьявление еще висит. Но как жук может выдергивать провод?

А я их припаял

Парни, нужен еще совет. В общем из того что вижу на столе, всё читается из кана (получаю сообщения Task Recieve processing message ID: 533 with data:), даже с скоростью 10мс, всё летит в входной буфер но дальше есп тормозит и ниче не выдаёт на выход при такой скорости входных данных, остальные процессы даже не запускаются, если совать только те пакеты которые ЕСП должно обработать, то процессы успевают стартануть но очередь на отправку в шину растёт с каждым сообщением Number of messages in TX queue: 297

Принимаю, обрабатываю и отправляю void twai_rx_task(void *arg) { twai_message_t twai_message; while (1) { // Receive message from TWAI if (twai_receive(&twai_message, pdMS_TO_TICKS(1)) == ESP_OK) { // Prepare the custom message format Message msg; msg.id = twai_message.identifier; // Use TWAI message ID for (int i = 0; i < 8; i++) { msg.data[i] = twai_message.data[i]; } //snprintf(msg.data, sizeof(msg.data), "Data: %s", twai_message.data); // Convert data to string UBaseType_t message_count = uxQueueMessagesWaiting(rx_queue); Serial.printf("Number of messages in rX queue: %d\n", message_count); Serial.printf("Task Recieve processing message ID: %d with data: %s\n", msg.id, msg.data); // Send received message to the processing queue switch (msg.id) { case REAR_PAM_ID: xQueueSend(rx_queue, &msg, portMAX_DELAY); break; case DIM: xQueueSend(rx_queue, &msg, portMAX_DELAY); break; default: ; } } } vTaskDelay(1); }

Ну у тебя один и тот же код с двух сторон?

нет, приходит сообщение например 114 я его обрабатываю и отправляю 113

я пишу в шину через canhacker ну или в авто

тут вопрос именно в том, что запись буксует, если просто читать всё отлично работает

тут вопрос именно в том, что запись буксует, если просто читать всё отлично работает

В idf есть заводской пример, рабочий. Наверняка опять в ардуине все беды)

Парни, нужен еще совет. В общем из того что вижу на столе, всё читается из кана (получаю сообщения Task Recieve processing message ID: 533 with data:), даже с скоростью 10мс, всё летит в входной буфер но дальше есп тормозит и ниче не выдаёт на выход при такой скорости входных данных, остальные процессы даже не запускаются, если совать только те пакеты которые ЕСП должно обработать, то процессы успевают стартануть но очередь на отправку в шину растёт с каждым сообщением Number of messages in TX queue: 297

Как это определяется?

в ардуине? Имеете ввиду ИДЕ? Сейчас собираю через platformio

В esp-idf в заводском исполнении

по логу в сериал

потому что задачи разные, у одной обработка одного сообщения у другой другого

И что? Не вижу целесообразности городить тут многопоточность которая абсолютно не нужна

в однопоточке тоже не работало

Заменить пару байт в пакете да, это такая "задача" для которой аж отдельный таск нужен. Не ну хозяин барин, но это перебор. Это все в один таск успешно запихивается

Да у него один хрен тут идф код, сути это не сильно меняет

Всех приветствую. Перед подключением к шине can автомобиля решил попробовать протестить схему на «столе». Использовал схему и код с сайта: https://microkontroller.ru/esp32-projects/can-shina-v-esp32-maksimalno-podrobno-vse-aspekty/?amp=1 Но у меня модуль немного другой (показан фото). Проблема: данные отправляются, но не принимаются. Оконечные терминаторные резисторы присутствуют в самом модуле и равны 120 Ом. Чем интересно может быть связана данная проблема, что данные не принимаются?

Был бы идф код, все бы уже давно работало

Я не умею в идф код

Кстати а может мне надо другой режим пользовать? Normal Mode (Обычный режим): В этом режиме контроллер TWAI может участвовать в действиях шины, таких как передача и получение сообщений/кадров ошибок. При передаче сообщения требуется подтверждение от другого узла. может оно не получает подтверждение какого то сообщения и падает?

Должно получать, потому что если ты передаешь сообщения кан хакером, значит он тоже в режиме normal. Кстати а что за устройство у тебя управляется канхакером?

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

Кан хакер у тебя чем управляет, ардуиной?

канхакер эмулирует сигналы записанные в авто

канхакер эмулирует сигналы записанные в авто

То есть у тебя сейчас 4 устройства подключены к шине? Это много, убери из цепочки 2 ардуины, они не нужны

Ну железо какое для кан хакера? Модель

нужны, они делают начало и конец линии по 120Ом

Ну повесь отдельно резисторы, или хотя бы не подавай питание на них

ну они сейчас да, не подключены, висят как концы линии

да я и так их в этом же канале могу контролировать