Зарегистрирован: Сб сен 06, 2008 12:56:13 Сообщений: 326
Рейтинг сообщения:0
"Интерфейс 1-Wire". http://radiokot.ru/articles/13/ Изложено доходчиво, но, тем не менее, вопросы некоторые, после прочтения остались.
1. Почему при передаче устройством "0" или "1" ввод значений в МК производится на 1/4 времени тайм-слота, а не в середине, как это сделано при вводе зачений в устройство, при передаче данных от МК?
2. При передаче устройством "0", оно должно удерживать шину в низком уровне до конца тайм-слота (после инициации МК)? В тексте об этом не сказано. По рисунку не понятно, почему такая большая зона неопределенности влево (заштрихованная часть). Такое впечатление, что 1-Wire устройство "знает", что нужно зарядить паразитную емкость и заранее освобожает шину, чтобы поспеть к концу тайм-слота. Какие, все-таки, временные параметры сигнала от устройства? Выше, по рисунку, при передаче "0" от МК, такой зоны нет.
По-моему, ответ на оба вопроса одинаков и заключается в том, что время, в течение которого линия вернется к высокому уровню после "отпускания" ее хоть кем (МК или устройством) весьма неопределено и зависит, в частности, от погонной емкости линии связи. Поэтому при передаче ведущим принимаются меры, чтобы ведомое устройство могло надежно отличить единицу от нуля, ну и наоборот - при приеме от ведомого делается то же самое, но другими средствами.
ведущий "тянет время" насколько это возможно при передаче, и старается как можно позже опрашивать линию при приеме - в этом случае вероятность правильного восприятия сигнала наиболее высока.
все определенные протоколом длительности в статье указаны, остальные не лимитируются. таков уж протокол...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Зарегистрирован: Сб сен 06, 2008 12:56:13 Сообщений: 326
Рейтинг сообщения:0
Попробую сформулировать вопросы по другому.
Цитата:
Если МК принимает данные, то опрос уровня в шине он должен сделать на промежутке от 13-й до 15-й микросекунде тайм-слота.
1. Почему???
Цитата:
...ведущий "тянет время" насколько это возможно при передаче, и старается как можно позже опрашивать линию при приеме - в этом случае вероятность правильного восприятия сигнала наиболее высока.
Следуя этому утверждению, да и с точки зрения "здравого смысла", для того, чтобы исключить влияние переходных процессов в начале и конце тайм-слота, МК должен ввести данные в середине слота.
2. При передаче данных устройством, оно должно освобождать шину в разные моменты при передаче "0" или "1". Далее при переходе шины в еденичное состояние, происходит заряд емкости линии. От постоянной времени заряда и будет меняться форма кривой (положе, круче) и следовательно ширина фронта сигнала, но без смещения начальной точки нулевого уровня. Вот это, на мой взгляд, можно и назвать зоной неопределенности. А по рисунку в статье, освобождение шины устройством начинается, особенно при передаче им "0", в совершенно непонятные моменты (левее конца тайм-слота)
Зарегистрирован: Сб сен 06, 2008 12:56:13 Сообщений: 326
Рейтинг сообщения:0
Разбираясь далее, выяснил следующее:
Широкая зона неопределенности при передаче устройством "0" (на рисунке в исходной статье) вызвана, видимо, отклонением внутреннего масштаба времени для устройств 1-Wire. На рисунке приведена минимальная величина - 15 мкс, в течение которго устройство удерживает шину в "нуле". Но она может быть увеличена, вследствие разброса, до 60 мкс? С точки зрения "паразитного" питания устройства 1-Wire, чем меньше, тем лучше, а для надежного приема сигналов - наоборот. Выходит, что самое "узкое" место в интерфейсе, это прием данных от устройства, а именно "нуля", который "портит погоду" и для "1". Получается, что это результат от предусмотренного питания устройств по шине и реализации части протокола в соответствии с этим. Наверное сложно попасть в эти 2-3 микросекунды .
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Огромное спасибо за доходчивое обьяснение интерфейса. Я сделал термометр с использованием Tiny2313 и Ds18b20 всё прекрасно работает. И теперь хочу поставить в линию два DS18B20. А для этого надо знать как вычислять CRC. Скажите пожалуйста правильно ли я понял- CRC=((((((байт1 xor '0x00') xor байт2)xor байт3)xor байт4)xor байт5)xor байт6)xor байт7)
Огромное спасибо за доходчивое обьяснение интерфейса. Я сделал термометр с использованием Tiny2313 и Ds18b20 всё прекрасно работает. И теперь хочу поставить в линию два DS18B20. А для этого надо знать как вычислять CRC. Скажите пожалуйста правильно ли я понял- CRC=((((((байт1 xor '0x00') xor байт2)xor байт3)xor байт4)xor байт5)xor байт6)xor байт7)
1. а как же без CRC вы сделали свой термометр?
2. вы не правильно поняли алгоритм подсчета CRC
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
1. а как же без CRC вы сделали свой термометр? 2. вы не правильно поняли алгоритм подсчета CRC
1. Reset-presence-skip rom-конвертировать температуру-жду одну секунду-reset-presence-skip_rom-read-читаю только первые два байта и через одну секунду все по новой.(В линии у меня ТОЛЬКО ОДИН DS18B20. Я честно говоря не понимаю "а как же без CRC вы сделали свой термометр?
")
2. Если у вас есть готовый кусок программы подсчёта CRC на ассемблере вышлете мне его пожалуйста. Или ссылочку с ответом на мой первый вопрос.
3. Как узнать адрес DS18B20? На корпусе нарисованны какие то циферки и буковки в три или четыре строчки не помню. Может быть часть этих циферок и есть адрес- имя термометра. Вобщем подскажите пожалуйста как узнать адрес?
1. Reset-presence-skip rom-конвертировать температуру-жду одну секунду-reset-presence-skip_rom-read-читаю только первые два байта и через одну секунду все по новой.(В линии у меня ТОЛЬКО ОДИН DS18B20. Я честно говоря не понимаю "а как же без CRC вы сделали свой термометр?")
да так и понимать - неправильно вы делаете. CRC должно вычисляться при любом чтении из датчика, причем читать положено не первые 2 байта, а все 9 байт. иначе, если была помеха, вы никогда не узнаете, что данные искажены - будет показывать -18 градусов у больного гриппом, и точка
roma писал(а):
2. Если у вас есть готовый кусок программы подсчёта CRC на ассемблере вышлете мне его пожалуйста. Или ссылочку с ответом на мой первый вопрос.
здесь на РадиоКоте я публиковал статью с исходниками на ассемблере - там есть и обмен, и рсчет CRC. посмотрите среди статей, я сам не помню, где это.
roma писал(а):
3. Как узнать адрес DS18B20? На корпусе нарисованны какие то циферки и буковки в три или четыре строчки не помню. Может быть часть этих циферок и есть адрес- имя термометра. Вобщем подскажите пожалуйста как узнать адрес?
адрес по корпусу не узнать, во всяком случае, никакой достоверной инфы об этом нет. его можно считать из каждого датчика поотдельности и запомнить, либо использовать возможность "поиска" адресов всех датчиков на шине. второй вариант для реализации на ассемблере достаточно сложен, т.к. имеет неслабый алгоритм, в ктором легко запутаться. наконец, вы можете при помощи простейщего адаптера к СОМ-порту считать в компьютер адреса датчиков и затем их использовать в своей программе, как константы.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Здравствуйте. Хочу подключить 18s20 к микроконтроллеру MSP430F149. Программа для МК будет написана в Си. Насколько я знаю, в Си время выполнения команд определить сложно, в то время как в ассемблере я могу точно знать время выполнения каждой конкретной команды. Поясню на примере:
Код:
int i = 5000; do { i--; } while(i>0)
За сколько машинных циклов выполнится структура do-while сказать сложно, в то время как в ассемблере я могу точно сказать сколько выполняется тот или иной кусок кода.
Вопрос: смогу ли я обеспечить заданные временные интервалы в Си или мне придется использовать ассемблер?
AVR, писал программку ИСКЛЮЧИТЕЛЬНО по вашей статье(на ассемблере), наконец-то у меня заработал датчик.. В этой теме http://radiokot.ru/forum/viewtopic.php? ... 95#p425195 я написал, почему у меня ОООчень долго не получалось, и некоторые личные наблюдения,.. Возможно не лишним было-бы внести некоторые дополнения в вашу статью, т.к. не исключено, что кто-та ещё попытается самостоятельно написать программу.. Возможно небольшая пометочка снизу позволит сэкономить кому-то уйму времени
AVR, писал программку ИСКЛЮЧИТЕЛЬНО по вашей статье(на ассемблере), наконец-то у меня заработал датчик.. В этой теме viewtopic.php?f=20&t=9863&p=425195#p425195 я написал, почему у меня ОООчень долго не получалось, и некоторые личные наблюдения,.. Возможно не лишним было-бы внести некоторые дополнения в вашу статью, т.к. не исключено, что кто-та ещё попытается самостоятельно написать программу.. Возможно небольшая пометочка снизу позволит сэкономить кому-то уйму времени
к сожалению, по вашей эмоциональной заметке по указанной ссылке видно, что это только ваши частные наблюдения, а интерфейс четко стандартизирован. я писал статью на основе сведений из стандарта, и потому не указывал "отсебятины" типа "датчик всегда удерживает 0 до 26-микросекунды" - это неверно вообще, хотя в частном случае может быть и так. то же самое и касательно всяких нюансов с опросами пинов и т.п.
не скажу, что моя статья - идеал во всех отношениях, т.к. по мере собственного развития и уровень знаний у меня меняется, а писал статью я довольно давно... более свежая версия с исправлением некоторых ошибочных утверждений имеется на моем сайте http://arv.radioliga.com/content/view/39/43/
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Извиняюсь за форму в которой изложил(эмоциональность).. ни в коем случае не хотел как упрёк, или что-то там такое.. сами понимаете, столько висеть над прогой, паяльником почём зря тыркать, и узнать, что вся-то проблема вот она! ... Ну естественно на тех эмоциях я и высказал своё мнение, "какие такие > 1 микросек", когда одну, и ни граммом более! . В самом деле извиняюсь.. на самом деле я на позитиве, а резковатая форма от кофе наверное, которым я заправлялся, т.к. делать надо, а глядеть на ту прогу и макетку уже аж тошно было!.
ARV- конечно-же вам спасибо, естественно понимаю что не в вину ему то, что он изложил в русской форме то, что написано о стандрарте интерфейса. ...и это, извиняюсь за невнимательность к очерёдности букофок
я не увидел никакой резкости в ваших постах - так, "щенячий восторг" вы меня неверно поняли. но из-за этого восторга вы упустили важные моменты. представьте себе, что будет, если кто-то, вняв вашему указанию "делать 1 микросекунду и не более" для старта тайм-слота, сделает это для своего девайса с 30 метровым экранированным кабелем? микросекундный импульс будет просто сожран емкостью линии и девайс его не увидит вообще! поэтому в стандарте и оговаривается "не менее 1 мкс" или, что то же самое, "1 мкс или более" - предел неявный...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
"не менее 1 мкс" или, что то же самое, "1 мкс или более" - предел неявный...
Звучит многозначительно... Всё-же вы попроситесь у администрации добавить пометку о том, что кое-чьи изыскания показали, что в условиях близких к идеальным(провод сантиметров 15) увеличение этого тайма до 2-х микросекунд, делает НЕВОЗМОЖНЫМ получить отклик от датчика..
Кстати, как вы оцените этот мой аргумент,.. мой датсчик с 8-ю ножками, следовательно предусмотрен для монтажа на платку, и соответственно находится рядом с микроконтролллером, и у его какая-то другая версия 1-виря(вопросом существования иных версия этого интерфейса я не владею..). ?
bool TReset(void) { char si; Port_OWP_0; //OWP <- 0 Delay_us(500); //delay 500 uS si = __save_interrupt(); __disable_interrupt(); //запрещение прерываний Port_OWP_Z; //OWP <- 1 Delay_us(14); //delay 14 uS if(Pin_OWP) //если OWP = 0, то ошибка { Delay_us(52); //delay 52 uS if(!Pin_OWP) //если OWP = 1, то ошибка { __restore_interrupt(si); //восстанавление прерываний Delay_us(250); //delay 250 uS if(Pin_OWP) //если OWP = 0, то ошибка { return(1); //если ошибок нет, термометр присутствует } } } __restore_interrupt(si); //восстанавление прерываний в случае ошибки return(0); }
//---------- Запись/чтение байта по однопроводной шине: ----------
char TByte(char dat) { char res; for(char i = 0; i < 8; i++) { res = res >> 1; if(TBit(dat & 1)) res |= 0x80; else res &= ~0x80; dat = dat >> 1; } return(res); }
//---------- Запись/чтение бита по однопроводной шине: ----------
bool TBit(bool b) { char si; si = __save_interrupt(); __disable_interrupt(); //запрещение прерываний Port_OWP_0; //OWP <- 0 Delay_us(2); //delay 2 uS if(b) Port_OWP_Z; //bit = 1, OWP <- 1 Delay_us(13); //delay 13 uS bool owp = Pin_OWP; //чтение порта Delay_us(45); //delay 45 uS Port_OWP_Z; //OWP <- 1 __restore_interrupt(si); //восстанавление прерываний Delay_us(2); //delay 2 uS return(owp); }
Уважаемый ARV, попал на Вашу статью http://radiokot.ru/articles/13/ из темы http://radiokot.ru/forum/viewtopic.php?f=20&t=45400 где о ней очень восторженно отзывались. Обратил внимание на фразу: "После того, как приняты все 8 (обратите внимание - именно 8!) байтов уникального адреса устройства, необходимо проверить содержимое ячейки CRC: ненулевое ее значение свидетельствует о наличии искажения принятых данных. Если же CRC=0 - это значит, что данные приняты без искажений. Если же МК вел передачу уникального адреса устройства, то содержимое CRC должно быть передано 8-ым байтом после предыдущих семи.", и далее только об этом. У неискушенного пользователя складывается впечатление, что CRC необходим только для чтения ROMа и логично делает вывод, а нафига это мне, если у меня только один датчик на отдельном выводе? Поэтому и бурные "доказательства" на форуме о том, что мне и без CRC хорошо, ведь я читаю 5 раз и выбираю среднее и т.п. Подумайте, может все-таки стоит добавить абзац про чтение данных и то, что девайс для каждого конкретного измерения сам вычисляет CRC и передает его девятым байтом? Ну и обсчитывать соответственно придется не 8, а 9 байтов. П.С. Удивительно, столько лет провисела без замечаний, похоже CRC никто не считает.
... что девайс для каждого конкретного измерения сам вычисляет CRC и передает его девятым байтом? Ну и обсчитывать соответственно придется не 8, а 9 байтов.
О как раз вопрос который мне бы хотелось прояснить. Т.е. скажем так. У меня в железе собран эмулятор ключа DS2413. Первое. Пока не посунул в эмулятор серийник с правильно подсчитаным CRC, программа ONEWAREVIEVER ( это фирменная Даласовская) его не увидела. Теперь видит очень даже устойчиво. Второе. Мой эмулятор выдает все время одно и то же значение состояния ключей. Реальное железо реагирует нормально. ( к слову в Протеусе все работает ). Так вот собственно вопрос? Скажем реакция программы на состояние ключей ( прием информации ) так же осуществляется с подсчетом CRC? Т.е. серийник мне понятно,посчитал СRC ? сравнил совпало или ноль дальше. А вот следующий обмен? Ведомый передает какие то команды, принимает ответы, в этом периоде работы надо подсчитывать CRC? Если да то чего?
вам надо изучить протокол работы DS2413 - там будет написано, когда и по каким командам что передается, с CRC или без... кстати, для прошивки "адресов" в эмуляторы и т.п. вычислений CRC по далласовскому алгоритму я сделал утилитку, надеюсь, вам пригодится: http://arv.radioliga.com/content/view/225/38/
P.S. замечание по поводу количества считанных байт - признаю, ошибка. честно говоря, т.к. для себя тему общения по 1-wire закрыл давным-давно, написав все необходимые низкоуровневые библиотеки, то статьи не перечитывал сто лет и даже думать про это перестал. текст в статье может изменить администрация, если сочтет необходимым.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: Volodya_Tver и гости: 36
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения