Зарегистрирован: Ср май 01, 2019 16:54:29 Сообщений: 15 Откуда: Иркутск, Россия
Рейтинг сообщения:0
То есть гальваническая изоляция для подобных интерфейсов не нужна и ничего там по порту не ударит?
Я в этом действительно плохо разбираюсь сейчас, однако пытаюсь разобраться. А вот ваш стиль общения, musor... ...Будто в деревенский туалет зашел.
В DS нету CRC, разве что только при поиске/чтении адреса, верно? На Modbus RTU, естественно, у меня есть проверка циклического кода. На счет остального контроля - это уже другая история, у меня пока лишь задача обезопасить устройство. На будущее - ясно этим надо будет озадачиться, если устройство уже готовится к выпуску)
Зарегистрирован: Ср май 01, 2019 16:54:29 Сообщений: 15 Откуда: Иркутск, Россия
Рейтинг сообщения:0
То есть помимо двух байтов данных из DS18B20 можно считать и третий байт CRC? UPD: Нет, явно надо считывать все 9 байт. Достаточно странно получается) Хотя почему бы и нет?
КАК ВСЕ ЗАПУШЕНОНО У СТУДНЕЙ НЕДОУЧЕК... ДАЖЕ ПРО CRC НЕ ЗНАЮТ& КАКОЙ ПРЕПОД В ипи ВАС ТАКИ ПЛОХО УЧИЛ
_________________ ZМудрость(Опыт и выдержка) приходит с годами. Все Ваши беды и проблемы, от недостатка знаний. Умный и у дурака научится, а дураку и .. Алберт Ейнштейн не поможет и ВВП не спасет.и МЧС опаздает
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Ну ДЫК.... Сначала надо хотя бы с элементной базой и ее даташитами разобраться.... CRC как защитный ключ достоверности данных именно с I Button/uLAN, к коим и DS18b20 относится, применяться начал в радиолюбительских конструкциях. Собственно сам принцип контрольного кода давно известен, но именно в uLAN стал обязательным при обработке для самоделок. Алгоритм весьма .... обычно реализацию и описание народ копирует. Сам пользуюсь расписанным готовым (сначала стащил в инете, затем расписал и ныне применяю уже адаптированный к соответствующему компилятору/системе команд). Читается весь массив 8 или 9 байт (CRC7/CRC8) затем проверяем на корректность и по результату проверки считаем данные или фальстартом или достоверными. В то же время сам DS18B20 допускает прием нескольких байт без контрольной CRC (замена уставки и/или режима к примеру).
Зарегистрирован: Ср май 01, 2019 16:54:29 Сообщений: 15 Откуда: Иркутск, Россия
Рейтинг сообщения:0
Было бы познавательно про код CRC (для меня), если бы это я уже сам не знал. Сам пользуюсь пока скопированным из интернета, но то было просто "попробовать". Далее буду уже сам писать данную функцию. Про то, что у DS есть CRC это я знал, но вот в голову не приходило считывать весь ROM, чтобы проверить CRC)
Алгоритм весьма .... обычно реализацию и описание народ копирует. Сам пользуюсь расписанным готовым (сначала стащил в инете, затем расписал и ныне применяю уже адаптированный к соответствующему компилятору/системе команд).
Что Вы имеете ввиду? Для CRC8 единственным целесообразным алгоритмом будет таблица и циклический XOR. Даже если есть аппаратная поддержка CRC, для байтного формата эту поддержку использовать бессмысленно. Расчет будет идти дольше, даже если тактирование модуля CRC выше системной частоты в 2 раза.
... Что Вы имеете ввиду? Для CRC8 единственным целесообразным алгоритмом будет таблица и циклический XOR. Даже если есть аппаратная поддержка CRC, для байтного формата эту поддержку использовать бессмысленно. Расчет будет идти дольше, даже если тактирование модуля CRC выше системной частоты в 2 раза.
А зачем тому вычислению суперскорость-то? Все равно опрос делается раз в пол-секунды минимум (а то и реже - до 1 секунды при 12-битном режиме), и после приема пакета - куда спешить то? В то же время табличка место занимает - к примеру в тех же аттини13, 2313 и ПИК629. А проверка CRC в солидных приложениях весьма необходимая штука (особо ежли шлейф длиннее 2 метров). Да и не только конкретно к DSке.
256 байт ФЛЕША. Вы полагаете, что найдется хоть один МК (кроме 10-х пиков первой инкарнации), где это будет критично? И еще нужно вычесть из этих 256 байт оверхед по инструкциям при циклической обработке против табличной....
В принципе любой МК с ПЗУ до килобайта/двух командных кодов (у ПИКа соответствие, а у АВРок команда = 2 байта - итогом кодов программы в два раза меньше у той же тиньки13й в результате всего 512 команд разместить можно при заявленной в байтах 1к флешине). Да и от системы команд зависит - или микропрограмма за одну команду или набор из нескольких "простейших" для аналогии. Дополнительно и реализация одного и того же алгоритма в зависимости от системы команд и архитектуры ядра будет несколько меняться. Это ежли задача обработки несколько больше, чем только обслуживание датчика с последующей обработкой данных (индикация или пересылка). А там еще и других табличек может появится - где реально скорость обработки требуется. Ну и "страховой запас" для первичного сырца - при работе под ассемблером оптимальный вариант сразу в большинстве случаев получить не удается. Это не так давно стали флэш удобоваримого объема ставить на последних поколениях МК. Так что сбрасывать со счета вычислительный вариант...
Другое дело привычка или реальная необходимость - я ж не говорю об абсолютном исключении табличного варианта из арсенала.
НО... чтой-то мы от основной темы отклонились...
Ставить оптроны на DSку с моего взгляду таки уж нерационально... Может вариант импульсных трансформаторов, учитывая скоростные характеристики? Никто с таким вариантом не встречался?
Оптроны требуются быстродействующие - надо по даташитам время наростания и спада сигнала отслеживать очень тщательно. Самре досадное - двунаправленность шины. С оптронами удобно однонаправленный вариант выполнять. А у микролана самое неудобное в данном смысле - участок отзыва датчика на запрос ведущего. Не вписался в интервалы - считается сбоем работоспособности. В то же время быстродействующие оптроны и по дороже и поискать надо. Ежли возможность их достать да поэкспериментировать есть - тогда другое дело.
Зарегистрирован: Ср май 01, 2019 16:54:29 Сообщений: 15 Откуда: Иркутск, Россия
Рейтинг сообщения:0
Как уже было написано - дешевые быстрые оптроны есть) Надо только заказать их... А на счет подтяжки входов с оптопар (где-то там наверху обеспокоился) - в МК же внутренние подтягивающие/стягивающие резисторы есть. Вечно из моей головы что-то важное вылетает)
странный... если тут мк, то у него можно распилить - вход на одру ногу, выход на дтугую, а в 1wire собрать уже на горячей стороне
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Давно уже в теме молчок... Тут удобнее малолапый МК с преобразованием микролановского протокола в чего-то типа I2C/SPI/rs232 (или еще чего - радиоканал к примеру), а уже между тем преобразователем и основным МК делаем "стандартный" гальванбарьер.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 31
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения