Форум РадиоКот

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

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

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

[uquote="IgnatiusF",url="/forum/viewtopic.php?p=3627249#p3627249"]В DS нету CRC, разве что только при поиске/чтении адреса, верно?[/uquote]
Не совсем… при чтении температуры тоже необходимо вычислять CRC дабы быть уверенным что прочитанные значения приняты верно.

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

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

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

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

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

[uquote="BOB51",url="/forum/viewtopic.php?p=3627359#p3627359"]Алгоритм весьма .... обычно реализацию и описание народ копирует. Сам пользуюсь расписанным готовым (сначала стащил в инете, затем расписал и ныне применяю уже адаптированный к соответствующему компилятору/системе команд).[/uquote]
Что Вы имеете ввиду? Для CRC8 единственным целесообразным алгоритмом будет таблица и циклический XOR. Даже если есть аппаратная поддержка CRC, для байтного формата эту поддержку использовать бессмысленно. Расчет будет идти дольше, даже если тактирование модуля CRC выше системной частоты в 2 раза.

[uquote="IgnatiusF",url="/forum/viewtopic.php?p=3627373#p3627373"]но вот в голову не приходило считывать весь ROM, чтобы проверить CRC)[/uquote]
Есть другие предложения?

[uquote="КРАМ",url="/forum/viewtopic.php?p=3627378#p3627378"]...
Что Вы имеете ввиду? Для CRC8 единственным целесообразным алгоритмом будет таблица и циклический XOR. Даже если есть аппаратная поддержка CRC, для байтного формата эту поддержку использовать бессмысленно. Расчет будет идти дольше, даже если тактирование модуля CRC выше системной частоты в 2 раза.[/uquote]
А зачем тому вычислению суперскорость-то?
Все равно опрос делается раз в пол-секунды минимум (а то и реже - до 1 секунды при 12-битном режиме),
и после приема пакета - куда спешить то?
В то же время табличка место занимает - к примеру в тех же аттини13, 2313 и ПИК629.
А проверка CRC в солидных приложениях весьма необходимая штука (особо ежли шлейф длиннее 2 метров).
Да и не только конкретно к DSке.

[uquote="BOB51",url="/forum/viewtopic.php?p=3627730#p3627730"]В то же время табличка место занимает[/uquote]
256 байт ФЛЕША.
Вы полагаете, что найдется хоть один МК (кроме 10-х пиков первой инкарнации), где это будет критично? И еще нужно вычесть из этих 256 байт оверхед по инструкциям при циклической обработке против табличной....

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

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


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

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

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

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

[uquote="BOB51",url="/forum/viewtopic.php?p=3628341#p3628341"]В то же время быстродействующие оптроны и по дороже и поискать надо.[/uquote]
6N137
дешево-быстро-сердито

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

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

[uquote="TVMaster2",url="/forum/viewtopic.php?p=3627052#p3627052"]опторазвязку сам скоро буду делать на HCNR201.[/uquote]
Получилось сделать?

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

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