settings.json

Тут есть подводный камень: * Собрали пакет с crc, * Отправили * Приемник принял, проверил crc, все годно, подготовил ответ с crc, отправил ответ. (Начал обработку принятого пакета) * ответ пришёл с ошибкой, его выбрасываем? * Ждём таймаут 100мс. * Ответа нет. Повторно высылаем пакет. * Приемник получает дубль пакета. Два одинаковых пакета подряд вместо одного.

Оба файла пустые

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

Что это такое? Я комментировал вполне конкретное предложение по реализации протокола

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

Что это такое? Я комментировал вполне конкретное предложение по реализации протокола

А можно ссылочку на начало описания этого протокола? :) А то я уже посередине обсуждения заметил о чем речь идет, но лишь кусочками. Насколько я понял задача несколько мк (больше 2х) соединить по уарту, верно?

А можно ссылочку на начало описания этого протокола? :) А то я уже посередине обсуждения заметил о чем речь идет, но лишь кусочками. Насколько я понял задача несколько мк (больше 2х) соединить по уарту, верно?

Уже спрашивал, никто не ответил. Какой протокол использовать для межконтроллерного взаимодействия внутри платы по UART

Это нехорошее решение. Это режим ASC.

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

Топовые корпуса для дачи 😂

Так вот в трнаспорте по уарту я получаю хидер пакета (там адреса, длина, crc) и потом считаю таймаут для получения нужного количества байт на текущей скорости. Например если таймаут 100 мс и скорость 9600, то можно получить до 768 байт (в идеальном случае) пейлоада. Сразу можно сделать проверку на поле длины, если там больше 768, например, то это мусор. Если там меньше и за нужное время байты не пришли - мусор. Но если фартануло и длина совпала - проверка crc

Если будут ошибки, думаю можно ещё уменьшить

Возможно я неправильно подключаю OE, я его подтягиваю через 10к к 3.3В. Для теста LCD-экран I2C работает нормально, а DS18b20 почему-то не хочет

Всем доброго дня. Прошу помощи. По дому разведены датчики DS18b20, линия около 20метров, 7 датчиков. 3.3вольта не хватает для их работы. На 5 вольт с ардуино уно работает отлично. Но к ESP32 никак не получается присоединить. Как это сделать посоветуйте?

modbus рассматривали для своей задачи? он адресный

Я просто тоже думаю над организацией связи между МК. В итоге пришел к RPC. Сделал первую версию, которая уже больше года работает. Но там P2P система. Потом обнаружил, что NXP уже придумали это до меня 😄. Посмотрел реализацию, мне не очень понравилось, потому что к этому времени уже захотелось не только одно устройство на шине иметь, либо иметь возможность отправлять сообщения от слейва мастеру, вроде нотификаций. Еще пришло понимание, что иметь один транспорт для RPC это маловато, ведь где-то уарт, где-то сокет, а где вообще esp-now какой-нибудь... В итоге сейчас тестирую самописный RPC. Но кодгенератор пока не планирую ему делать, команды и обработчики будут через интерфейсы (C++) работать, поэтому там можно копипастить и модефицировать 😄

Я просто тоже думаю над организацией связи между МК. В итоге пришел к RPC. Сделал первую версию, которая уже больше года работает. Но там P2P система. Потом обнаружил, что NXP уже придумали это до меня 😄. Посмотрел реализацию, мне не очень понравилось, потому что к этому времени уже захотелось не только одно устройство на шине иметь, либо иметь возможность отправлять сообщения от слейва мастеру, вроде нотификаций. Еще пришло понимание, что иметь один транспорт для RPC это маловато, ведь где-то уарт, где-то сокет, а где вообще esp-now какой-нибудь... В итоге сейчас тестирую самописный RPC. Но кодгенератор пока не планирую ему делать, команды и обработчики будут через интерфейсы (C++) работать, поэтому там можно копипастить и модефицировать 😄

Ну у меня до этого было что то вроде RPC Энум модуля + Энум процедуры + аргумент 4 байта. Но в таком случае - ты подстраиваешь все под такой обмен и это не всегда удобно. Надо иметь возможность свободно передавать случайные данные, а там уже как хочешь трактовать.

В итоге транспорт просто передает посылку (с нефиксированной длиной) куда надо и считает crc, а дальше сам протокол уже внутри посылки, ну а за ним пейлоад

У меня ds на 3.3v работает, линия метров 30, 11 датчиков, но сопротивление около 3к

Ну как то так и получается в итоге. Вопрос был самый первый - есть что такое готовое.

Я из готового только от NXP нашел, ну и всякие модбасы. В итоге начал свой делать... У модбаса есть серьезный плюс, что его очень просто завернуть в EtherCAT, с самопальным RPC так не прокатит. Поэтому прямо супер универсальную штуку не получится сделать

Я из готового только от NXP нашел, ну и всякие модбасы. В итоге начал свой делать... У модбаса есть серьезный плюс, что его очень просто завернуть в EtherCAT, с самопальным RPC так не прокатит. Поэтому прямо супер универсальную штуку не получится сделать

он же вообще на плисках

UTF-8 в винде не включилось часом?

Вообщем не понимаю что с VSCode случилось

C/C++ IntelliSense