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

Я в этом действительно плохо разбираюсь сейчас, однако пытаюсь разобраться.
А вот ваш стиль общения, musor... ...Будто в деревенский туалет зашел.

В DS нету CRC, разве что только при поиске/чтении адреса, верно? На Modbus RTU, естественно, у меня есть проверка циклического кода. На счет остального контроля - это уже другая история, у меня пока лишь задача обезопасить устройство. На будущее - ясно этим надо будет озадачиться, если устройство уже готовится к выпуску)

Не совсем… при чтении температуры тоже необходимо вычислять CRC дабы быть уверенным что прочитанные значения приняты верно.

То есть помимо двух байтов данных из DS18B20 можно считать и третий байт CRC?
UPD: Нет, явно надо считывать все 9 байт. Достаточно странно получается) Хотя почему бы и нет?

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

КАК ВСЕ ЗАПУШЕНОНО У СТУДНЕЙ НЕДОУЧЕК... ДАЖЕ ПРО CRC НЕ ЗНАЮТ&
КАКОЙ ПРЕПОД В ипи ВАС ТАКИ ПЛОХО УЧИЛ

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Ну ДЫК....
Сначала надо хотя бы с элементной базой и ее даташитами разобраться....
CRC как защитный ключ достоверности данных именно с I Button/uLAN, к коим и DS18b20 относится, применяться начал в радиолюбительских конструкциях.
Собственно сам принцип контрольного кода давно известен, но именно в uLAN стал обязательным при обработке для самоделок.
Алгоритм весьма .... обычно реализацию и описание народ копирует. Сам пользуюсь расписанным готовым (сначала стащил в инете, затем расписал и ныне применяю уже адаптированный к соответствующему компилятору/системе команд).
Читается весь массив 8 или 9 байт (CRC7/CRC8) затем проверяем на корректность и по результату проверки считаем данные или фальстартом или достоверными.
В то же время сам DS18B20 допускает прием нескольких байт без контрольной CRC (замена уставки и/или режима к примеру).

Было бы познавательно про код CRC (для меня), если бы это я уже сам не знал. Сам пользуюсь пока скопированным из интернета, но то было просто "попробовать". Далее буду уже сам писать данную функцию. Про то, что у DS есть CRC это я знал, но вот в голову не приходило считывать весь ROM, чтобы проверить CRC)

Что Вы имеете ввиду? Для CRC8 единственным целесообразным алгоритмом будет таблица и циклический XOR. Даже если есть аппаратная поддержка CRC, для байтного формата эту поддержку использовать бессмысленно. Расчет будет идти дольше, даже если тактирование модуля CRC выше системной частоты в 2 раза.

Есть другие предложения?

А зачем тому вычислению суперскорость-то?
Все равно опрос делается раз в пол-секунды минимум (а то и реже - до 1 секунды при 12-битном режиме),
и после приема пакета - куда спешить то?
В то же время табличка место занимает - к примеру в тех же аттини13, 2313 и ПИК629.
А проверка CRC в солидных приложениях весьма необходимая штука (особо ежли шлейф длиннее 2 метров).
Да и не только конкретно к DSке.

256 байт ФЛЕША.
Вы полагаете, что найдется хоть один МК (кроме 10-х пиков первой инкарнации), где это будет критично? И еще нужно вычесть из этих 256 байт оверхед по инструкциям при циклической обработке против табличной....

В принципе любой МК с ПЗУ до килобайта/двух командных кодов (у ПИКа соответствие, а у АВРок команда = 2 байта - итогом кодов программы в два раза меньше у той же тиньки13й в результате всего 512 команд разместить можно при заявленной в байтах 1к флешине).
Да и от системы команд зависит - или микропрограмма за одну команду или набор из нескольких "простейших" для аналогии.
Дополнительно и реализация одного и того же алгоритма в зависимости от системы команд и архитектуры ядра будет несколько меняться.
Это ежли задача обработки несколько больше, чем только обслуживание датчика с последующей обработкой данных (индикация или пересылка).
А там еще и других табличек может появится - где реально скорость обработки требуется.
Ну и "страховой запас" для первичного сырца - при работе под ассемблером оптимальный вариант сразу в большинстве случаев получить не удается.
Это не так давно стали флэш удобоваримого объема ставить на последних поколениях МК.
Так что сбрасывать со счета вычислительный вариант...

Другое дело привычка или реальная необходимость - я ж не говорю об абсолютном исключении табличного варианта из арсенала.


НО... чтой-то мы от основной темы отклонились...

Ставить оптроны на DSку с моего взгляду таки уж нерационально...
Может вариант импульсных трансформаторов, учитывая скоростные характеристики?
Никто с таким вариантом не встречался?

А в чем эта нерациональность заключается?

Оптроны требуются быстродействующие - надо по даташитам время наростания и спада сигнала отслеживать очень тщательно.
Самре досадное - двунаправленность шины. С оптронами удобно однонаправленный вариант выполнять.
А у микролана самое неудобное в данном смысле - участок отзыва датчика на запрос ведущего.
Не вписался в интервалы - считается сбоем работоспособности.
В то же время быстродействующие оптроны и по дороже и поискать надо.
Ежли возможность их достать да поэкспериментировать есть - тогда другое дело.

6N137
дешево-быстро-сердито

Как уже было написано - дешевые быстрые оптроны есть) Надо только заказать их...
А на счет подтяжки входов с оптопар (где-то там наверху обеспокоился) - в МК же внутренние подтягивающие/стягивающие резисторы есть. Вечно из моей головы что-то важное вылетает)

Подтягивающие резисторы в МК обычно очень высокоомные - порядка 50...100 кОм. И экономить резисторы - это плохая идея.

Получилось сделать?

странный... если тут мк, то у него можно распилить - вход на одру ногу, выход на дтугую, а в 1wire собрать уже на горячей стороне

Давно уже в теме молчок...
Тут удобнее малолапый МК с преобразованием микролановского протокола в чего-то типа I2C/SPI/rs232 (или еще чего - радиоканал к примеру), а уже между тем преобразователем и основным МК делаем "стандартный" гальванбарьер.