Интерфейс 1-Wire

[ValBag]

"Интерфейс 1-Wire". http://radiokot.ru/articles/13/
Изложено доходчиво, но, тем не менее, вопросы некоторые, после прочтения остались.
1. Почему при передаче устройством "0" или "1" ввод значений в МК производится на 1/4 времени тайм-слота, а не в середине, как это сделано при вводе зачений в устройство, при передаче данных от МК?
2. При передаче устройством "0", оно должно удерживать шину в низком уровне до конца тайм-слота (после инициации МК)? В тексте об этом не сказано. По рисунку не понятно, почему такая большая зона неопределенности влево (заштрихованная часть). Такое впечатление, что 1-Wire устройство "знает", что нужно зарядить паразитную емкость и заранее освобожает шину, чтобы поспеть к концу тайм-слота. Какие, все-таки, временные параметры сигнала от устройства? Выше, по рисунку, при передаче "0" от МК, такой зоны нет.

[ARV]

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

ведущий "тянет время" насколько это возможно при передаче, и старается как можно позже опрашивать линию при приеме - в этом случае вероятность правильного восприятия сигнала наиболее высока.

все определенные протоколом длительности в статье указаны, остальные не лимитируются. таков уж протокол...

[ValBag]

Попробую сформулировать вопросы по другому.

Если МК принимает данные, то опрос уровня в шине он должен сделать на промежутке от 13-й до 15-й микросекунде тайм-слота.

1. Почему???

...ведущий "тянет время" насколько это возможно при передаче, и старается как можно позже опрашивать линию при приеме - в этом случае вероятность правильного восприятия сигнала наиболее высока.

Следуя этому утверждению, да и с точки зрения "здравого смысла", для того, чтобы исключить влияние переходных процессов в начале и конце тайм-слота, МК должен ввести данные в середине слота.
2. При передаче данных устройством, оно должно освобождать шину в разные моменты при передаче "0" или "1". Далее при переходе шины в еденичное состояние, происходит заряд емкости линии. От постоянной времени заряда и будет меняться форма кривой (положе, круче) и следовательно ширина фронта сигнала, но без смещения начальной точки нулевого уровня. Вот это, на мой взгляд, можно и назвать зоной неопределенности. А по рисунку в статье, освобождение шины устройством начинается, особенно при передаче им "0", в совершенно непонятные моменты (левее конца тайм-слота)

[ValBag]

Разбираясь далее, выяснил следующее:
Широкая зона неопределенности при передаче устройством "0" (на рисунке в исходной статье) вызвана, видимо, отклонением внутреннего масштаба времени для устройств 1-Wire. На рисунке приведена минимальная величина - 15 мкс, в течение которго устройство удерживает шину в "нуле". Но она может быть увеличена, вследствие разброса, до 60 мкс? С точки зрения "паразитного" питания устройства 1-Wire, чем меньше, тем лучше, а для надежного приема сигналов - наоборот. Выходит, что самое "узкое" место в интерфейсе, это прием данных от устройства, а именно "нуля", который "портит погоду" и для "1". Получается, что это результат от предусмотренного питания устройств по шине и реализации части протокола в соответствии с этим. Наверное сложно попасть в эти 2-3 микросекунды .

[ARV]

практика показывает, что попасть куда надо не трудно.

[roma]

Огромное спасибо за доходчивое обьяснение интерфейса. Я сделал термометр с использованием Tiny2313 и Ds18b20 всё прекрасно работает. И теперь хочу поставить в линию два DS18B20. А для этого надо знать как вычислять CRC. Скажите пожалуйста правильно ли я понял- CRC=((((((байт1 xor '0x00') xor байт2)xor байт3)xor байт4)xor байт5)xor байт6)xor байт7)

[ARV]

Огромное спасибо за доходчивое обьяснение интерфейса. Я сделал термометр с использованием Tiny2313 и Ds18b20 всё прекрасно работает. И теперь хочу поставить в линию два DS18B20. А для этого надо знать как вычислять CRC. Скажите пожалуйста правильно ли я понял- CRC=((((((байт1 xor '0x00') xor байт2)xor байт3)xor байт4)xor байт5)xor байт6)xor байт7)

1. а как же без CRC вы сделали свой термометр?
2. вы не правильно поняли алгоритм подсчета CRC

[roma]

1. а как же без CRC вы сделали свой термометр?
2. вы не правильно поняли алгоритм подсчета CRC

1. Reset-presence-skip rom-конвертировать температуру-жду одну секунду-reset-presence-skip_rom-read-читаю только первые два байта и через одну секунду все по новой.(В линии у меня ТОЛЬКО ОДИН DS18B20. Я честно говоря не понимаю "а как же без CRC вы сделали свой термометр?
")
2. Если у вас есть готовый кусок программы подсчёта CRC на ассемблере вышлете мне его пожалуйста. Или ссылочку с ответом на мой первый вопрос.


3. Как узнать адрес DS18B20? На корпусе нарисованны какие то циферки и буковки в три или четыре строчки не помню. Может быть часть этих циферок и есть адрес- имя термометра. Вобщем подскажите пожалуйста как узнать адрес?

[ARV]

1. Reset-presence-skip rom-конвертировать температуру-жду одну секунду-reset-presence-skip_rom-read-читаю только первые два байта и через одну секунду все по новой.(В линии у меня ТОЛЬКО ОДИН DS18B20. Я честно говоря не понимаю "а как же без CRC вы сделали свой термометр?")

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

2. Если у вас есть готовый кусок программы подсчёта CRC на ассемблере вышлете мне его пожалуйста. Или ссылочку с ответом на мой первый вопрос.

здесь на РадиоКоте я публиковал статью с исходниками на ассемблере - там есть и обмен, и рсчет CRC. посмотрите среди статей, я сам не помню, где это.

3. Как узнать адрес DS18B20? На корпусе нарисованны какие то циферки и буковки в три или четыре строчки не помню. Может быть часть этих циферок и есть адрес- имя термометра. Вобщем подскажите пожалуйста как узнать адрес?

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

[ctpexhih]

Здравствуйте. Хочу подключить 18s20 к микроконтроллеру MSP430F149. Программа для МК будет написана в Си. Насколько я знаю, в Си время выполнения команд определить сложно, в то время как в ассемблере я могу точно знать время выполнения каждой конкретной команды. Поясню на примере:

Код: Выделить всё

int i = 5000;
do
{
    i--;
}
while(i>0)

За сколько машинных циклов выполнится структура do-while сказать сложно, в то время как в ассемблере я могу точно сказать сколько выполняется тот или иной кусок кода.

Вопрос: смогу ли я обеспечить заданные временные интервалы в Си или мне придется использовать ассемблер?

[VIY]

AVR, писал программку ИСКЛЮЧИТЕЛЬНО по вашей статье(на ассемблере), наконец-то у меня заработал датчик.. В этой теме http://radiokot.ru/forum/viewtopic.php? ... 95#p425195 я написал, почему у меня ОООчень долго не получалось, и некоторые личные наблюдения,..
Возможно не лишним было-бы внести некоторые дополнения в вашу статью, т.к. не исключено, что кто-та ещё попытается самостоятельно написать программу.. Возможно небольшая пометочка снизу позволит сэкономить кому-то уйму времени

[Antol.St]

Нуж етит твою мать! Он ARV если что...
Нужно уважать людей, тем более если вам помогают...

[ARV]

AVR, писал программку ИСКЛЮЧИТЕЛЬНО по вашей статье(на ассемблере), наконец-то у меня заработал датчик.. В этой теме viewtopic.php?f=20&t=9863&p=425195#p425195 я написал, почему у меня ОООчень долго не получалось, и некоторые личные наблюдения,..
Возможно не лишним было-бы внести некоторые дополнения в вашу статью, т.к. не исключено, что кто-та ещё попытается самостоятельно написать программу.. Возможно небольшая пометочка снизу позволит сэкономить кому-то уйму времени

к сожалению, по вашей эмоциональной заметке по указанной ссылке видно, что это только ваши частные наблюдения, а интерфейс четко стандартизирован. я писал статью на основе сведений из стандарта, и потому не указывал "отсебятины" типа "датчик всегда удерживает 0 до 26-микросекунды" - это неверно вообще, хотя в частном случае может быть и так. то же самое и касательно всяких нюансов с опросами пинов и т.п.

не скажу, что моя статья - идеал во всех отношениях, т.к. по мере собственного развития и уровень знаний у меня меняется, а писал статью я довольно давно... более свежая версия с исправлением некоторых ошибочных утверждений имеется на моем сайте http://arv.radioliga.com/content/view/39/43/

[VIY]

Извиняюсь за форму в которой изложил(эмоциональность).. ни в коем случае не хотел как упрёк, или что-то там такое.. сами понимаете, столько висеть над прогой, паяльником почём зря тыркать, и узнать, что вся-то проблема вот она! ... Ну естественно на тех эмоциях я и высказал своё мнение, "какие такие > 1 микросек", когда одну, и ни граммом более! .
В самом деле извиняюсь.. на самом деле я на позитиве, а резковатая форма от кофе наверное, которым я заправлялся, т.к. делать надо, а глядеть на ту прогу и макетку уже аж тошно было!.

ARV- конечно-же вам спасибо, естественно понимаю что не в вину ему то, что он изложил в русской форме то, что написано о стандрарте интерфейса. ...и это, извиняюсь за невнимательность к очерёдности букофок

[ARV]

я не увидел никакой резкости в ваших постах - так, "щенячий восторг" вы меня неверно поняли. но из-за этого восторга вы упустили важные моменты. представьте себе, что будет, если кто-то, вняв вашему указанию "делать 1 микросекунду и не более" для старта тайм-слота, сделает это для своего девайса с 30 метровым экранированным кабелем? микросекундный импульс будет просто сожран емкостью линии и девайс его не увидит вообще! поэтому в стандарте и оговаривается "не менее 1 мкс" или, что то же самое, "1 мкс или более" - предел неявный...

[VIY]

"не менее 1 мкс" или, что то же самое, "1 мкс или более" - предел неявный...

Звучит многозначительно... Всё-же вы попроситесь у администрации добавить пометку о том, что кое-чьи изыскания показали, что в условиях близких к идеальным(провод сантиметров 15) увеличение этого тайма до 2-х микросекунд, делает НЕВОЗМОЖНЫМ получить отклик от датчика..

Кстати, как вы оцените этот мой аргумент,.. мой датсчик с 8-ю ножками, следовательно предусмотрен для монтажа на платку, и соответственно находится рядом с микроконтролллером, и у его какая-то другая версия 1-виря(вопросом существования иных версия этого интерфейса я не владею..). ?

[Liv]

или мне придется использовать ассемблер?

На ассемблере сейчас никто не пишет. Почти.

Код: Выделить всё

#define Delay_us(x) __delay_cycles(x * FCLK_MHZ)

//---------- Генерация импульса сброса: ----------

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);
}

//---------- Вычисление контрольной суммы: ----------

void Do_Crc8(char b, char *crc)
{
  for(char i = 0; i < 8; b = b >> 1, i++)
    if((b ^ *crc) & 1) *crc = ((*crc ^ 0x18) >> 1) | 0x80;
     else *crc = (*crc >> 1) & ~0x80;
}

[IM1]

Уважаемый 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 никто не считает.

[nsl2004]

... что девайс для каждого конкретного измерения сам вычисляет CRC и передает его девятым байтом? Ну и обсчитывать соответственно придется не 8, а 9 байтов.

О как раз вопрос который мне бы хотелось прояснить. Т.е. скажем так. У меня в железе собран эмулятор ключа DS2413.
Первое. Пока не посунул в эмулятор серийник с правильно подсчитаным CRC, программа ONEWAREVIEVER ( это фирменная Даласовская) его не увидела. Теперь видит очень даже устойчиво.
Второе. Мой эмулятор выдает все время одно и то же значение состояния ключей. Реальное железо реагирует нормально. ( к слову в Протеусе все работает ). Так вот собственно вопрос? Скажем реакция программы на состояние ключей ( прием информации ) так же осуществляется с подсчетом CRC? Т.е. серийник мне понятно,посчитал СRC ? сравнил совпало или ноль дальше. А вот следующий обмен? Ведомый передает какие то команды, принимает ответы, в этом периоде работы надо подсчитывать CRC? Если да то чего?

[ARV]

вам надо изучить протокол работы DS2413 - там будет написано, когда и по каким командам что передается, с CRC или без... кстати, для прошивки "адресов" в эмуляторы и т.п. вычислений CRC по далласовскому алгоритму я сделал утилитку, надеюсь, вам пригодится: http://arv.radioliga.com/content/view/225/38/

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