Инициализация DS18B20

**ARV** · 9 июня, 2019

4 часа назад, Starichok сказал:

если без массива, то куда будут помещены прочитанные 9 байт? в чем тут экономия?

Фактически нужны 2 первых байта с температурой, их считываем в соответствующую переменную, а все остальные байты считываем во временную переменную с одновременным подсчётом CRC, и более нигде их не храним. В итоге массива нет, лишних переменных тоже нет.

Экономия смешная, я не спорю. Просто указал возможность и такого варианта.

2 часа назад, kostya_unix сказал:

В даташит_е есть такие строки

В даташите НЕТ таких строк, вы процитировали кривой, вводящий в заблуждение перевод даташита! На линии DQ во время преобразования будет лог.1, а вовсе не 0.

Зато любой тайм-слот чтения будет возвращать 0, пока преобразование не завершено. Чувствует разницу?

То есть вы можете обойтись без паузы в 750 мс или более, если, например, каждые 50 мс будете считывать БИТ из датчика, и, как только считаете 1, это и будет сигналом о конце преобразования.

Однако, по геморройности этот вариант намного хуже простого ожидания...

Реклама

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

**kostya_unix** · 9 июня, 2019

13 часа назад, ARV сказал:

Фактически нужны 2 первых байта с температурой, их считываем в соответствующую переменную, а все остальные байты считываем во временную переменную с одновременным подсчётом CRC, и более нигде их не храним. В итоге массива нет, лишних переменных тоже нет.

Экономия смешная, я не спорю. Просто указал возможность и такого варианта.

В даташите НЕТ таких строк, вы процитировали кривой, вводящий в заблуждение перевод даташита! На линии DQ во время преобразования будет лог.1, а вовсе не 0.

Зато любой тайм-слот чтения будет возвращать 0, пока преобразование не завершено. Чувствует разницу?

То есть вы можете обойтись без паузы в 750 мс или более, если, например, каждые 50 мс будете считывать БИТ из датчика, и, как только считаете 1, это и будет сигналом о конце преобразования.

Однако, по геморройности этот вариант намного хуже простого ожидания...

Да. Перевод вольный, согласен.

Реклама

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

**kostya_unix** · 9 июня, 2019

16 часов назад, Starichok сказал:

дело в том, что при отработке паузы с помощью _delay_ms(750) МК больше НИЧЕГО в это время делать не может. это пустая трата процессорного времени.

точнее, МК во время отработки паузы может обрабатывать прерывания.

можно делать такую проверку. а можно и не делать.

например, у меня полный приборный цикл равен 1 секунде. но я точно знаю (и ты это знаешь), что 1 секунду преобразование температуры гарантированно закончится.

поэтому я без проверки считываю новую температуру и запускаю новую конвертацию.

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

вариантов тут несколько.

1. тупо делать задержку с помощью delay.

2. тупо сидеть в цикле и по кругу проверять на завершение конвертации. этот вариант потребует те же самые 700-750 мс бесполезной потери времени.

3. делать, как я - 1 раз в секунду без проверки считывать новую температуру и запускать новую конвертацию.

может, чья-то фантазия придумает еще другие способы...

Понятно. Такие операции, наверное лучше всего выполнять через таймеры (освоим и это).

Уважаемый @Starichok подскажите пожалуйста алгоритм работы таймер/счетчиков, в частности обработка прерываний.

Пишется, что при срабатывании прерываний по какому нибудь событию, нормальное выполнение программы прерывается и выполняется обработка прерывания.

Собственно вопрос: - когда происходит обработка прерывания , основной цикл программы ожидает пока не завершится обработка прерывания ?

- или цикл основной программы продолжается параллельно с выполнением обработки прерывания ?

Собственно как то так. Прошу прощения, если изложил свой вопрос не грамотно.

Реклама

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

**ARV** · 10 июня, 2019

4 часа назад, kostya_unix сказал:

когда происходит обработка прерывания , основной цикл программы ожидает пока не завершится обработка прерывания ?

Ожидает.

Starichok · 10 июня, 2019

процессор не может выполнять две работы одновременно.

прерывание потому и называется прерыванием, что оно прерывает основной процесс. и процесс ждет, когда закончится прерывание.

работу таймеров нужно изучить по даташиту на конкретный МК. в рамках этой темы нет возможности проводить ликбез по таймерам.

а о "технологии" применения таймера я могу вкратце рассказать на примере, как я обычно делаю. но я не требую, чтобы все следовали моим привычкам.

обычно у меня один таймер работает по совпадению и отрабатывает промежуток времени в 2 миллисекунды. а 2 мс потому, что такой промежуток вполне подходит для обработки энкодера.

то есть, таймер заходит в свое прерывание каждые 2 мс.

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

затем у меня в программе есть два счетчика (размещены в двух регистрах).

первый счетчик считает число прерываний таймера. когда первый счетчик насчитает до 5 ( получается интервал 10 мс), инкрементируется второй счетчик, а первый сбрасывается в ноль.

второй счетчик считает до 100 - это получается 1 секунда.

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

когда второй счетчик досчитает до 100, он сбрасывается в ноль, и делается длинный программный цикл.

в этом длинном цикле я обрабатываю измерения - напряжение и ток, температуру. и вывожу измеренные величины на экран.

почему два счетчика? при 2 мс на 1 секунду приходится 500 прерываний, и одним регистром (одним байтом) до 500 не сосчитать.

но можно сделать прерывание таймера, например, по 4 мс. тогда для 1 секунды хватит 1 регистра (250 прерываний).

как я написал выше, конвертация температуры закончится гораздо раньше, чем пройдет 1 секунда. и мне даже не надо проверять окончание конвертации. я сразу читаю значение температуры и запускаю новую конвертацию.

есть у меня еще и средний программный цикл.

я делю 1 секунду на 3 части (когда второй счетчик равен 0 или 33 или 66).

в этом среднем цикле у меня обрабатываются кнопки и энкодер, примерно через 1/3 секунды. также делается вывод на экран текущего состояния в соответствии с действиями над кнопками и энкодером.

а внутри прерывания таймера делает инкремент первого счетчика (который считает у меня до 5) и проверяется энкодер.

для начала тебе пока хватит и этой информации по работе с таймером и по разной организации программных циклов.

**kostya_unix** · 11 июня, 2019

В 10.06.2019 в 15:06, ARV сказал:

Ожидает.

Спасибо.

Всех с наступающим дополнительным выходным!!!!

**kostya_unix** · 21 июня, 2019

Всем участникам, всем оказывающим посильную помощь в изучении мной датчика DS18B20 здравствуйте.

После вопроса уважаемого @ARV по подсчету контрольной суммы полученного значения 9 байтов scratchpad - ОЗУ прошло ровно две недели. Все это время я старался изучить (более или менее вдумчиво) этот вопрос, найти способ расчета контрольной суммы. Так как учится, изучать приходится самостоятельно ( в моем профессиональном окружении нет любителей микроконтроллеров ( и язык C так же осваиваю самостоятельно)), то время уходит много. Так же информации в интернете мнОго по этому вопросу, но понятной для меня, оказалось очень не много.

Но по истечению полутора недель изучения вопроса постепенно начал вникать в суть решения этого вопроса. В итоге решение оказалось не таким и сложным как казалось вначале (но это было чуть позже ). Дорога привела меня к стандартной библиотеки <util/crc16.h> в описании которой и лежит алгоритм расчета контрольных сумм. Ссылка на описание этой библиотеки http://avr-libc.narod.ru/group__util__crc.html#g37b2f691ebbd917e36e40b096f78d996

Уважаемые @ARV , @Starichok (и все кто может внести конструктивную критику) прошу Вас поправить меня и указать на ошибки.

Вот код подсчета CRC:

#include <util/crc16.h> 

uint8_t term_code[8] = {0,0,0,0,0,0,0,0};       // массив для полученного кода значения температуры(без CRC_кода)
uint8_t crcCode = 0;                                        // переменная для хранения полученного CRC_кода

uint8_t c = 0;                                                   // переменная для отображения ошибок несоответствия контрольных сумм

int checkcrc()                                                 // функция подсчета значения контрольной суммы
{
    uint8_t crc =0;
       for (uint8_t i=0; i<sizeof term_code / sizeof term_code[0]; i++)
    {
        crc = _crc_ibutton_update(crc, term_code[i]);
    }

        return crc;
}

Так же создал функцию, которая сравнивает полученное значение CRC и расчетное для отображения на LCD_дисплее ( для контроля ошибок) :

void error_crc()
{
    if (checkcrc() != crcCode)
    {
        c=c+1;  // c определена глобально
    }
    
}

Код функции _crc_ibuttin_update(): из стандартной библиотеки <util/crc16.h>

   uint8_t _crc_ibutton_update(uint8_t crc, uint8_t data)
    {
        uint8_t i;

        crc = crc ^ data;
        for (i = 0; i < 8; i++)
        {
            if (crc & 0x01)
                crc = (crc >> 1) ^ 0x8C;
            else
                crc >>= 1;
        }
        return crc;
    }

Способ считывания значения scratchpad ОЗУ стандартный. Описан на многих сайтах. Ссылка на один из них : http://narodstream.ru/avr-urok-20-podklyuchaem-datchik-temperatury-ds18b20-chast-1/

Еще раз всем спасибо.

**ARV** · 21 июня, 2019

Параметр sizeof должен быть в скобках. Считать CRC удобнее не для 8, а для всех 9 байтов, т.е. включая CRC, т.к. в этом случае при совпадении подсчитанной и переданной контрольных сумм результат будет равен нулю, а при несовпадении - не равен. Проверять проще.

В целом логично считать CRC прямо при приеме байтов из SCRATCHPAD-памяти датчика, тогда функция чтения данных из датчика сразу может вернуть признак корректности результата.

**kostya_unix** · 23 июня, 2019

В 21.06.2019 в 17:26, ARV сказал:

Параметр sizeof должен быть в скобках.

@ARV спасибо бОльшое за ценные советы.

Исправил.

В 21.06.2019 в 17:26, ARV сказал:

Считать CRC удобнее не для 8, а для всех 9 байтов, т.е. включая CRC, т.к. в этом случае при совпадении подсчитанной и переданной контрольных сумм результат будет равен нулю, а при несовпадении - не равен. Проверять проще.

Опять же спасибо большое.

Сейчас на работе проверил - все именно так. У меня у Вам небольшой вопрос (уточнение): возвращает в случке ошибки не ноль, а от чего зависит значение возвращаемого числа в случае ошибки ( не совпадения)? У меня выводится число 99 в десятичной системе ( вывожу на Ж.К. дисплей для контроля):

lcd_dat(((checkcrc()/100)%10)+48);
lcd_dat(((checkcrc()/10)%10)+48);
lcd_dat((checkcrc()%10)+48);

Starichok · 24 июня, 2019

вот, ты нашел алгоритм вычисления CRC.

ты должен был понять, что при вычислении обрабатывается КАЖДЫЙ бит всей последовательности плюс участвует КАЖДЫЙ байт последовательности.

а теперь поищи в инете, что такое CRC и что по возвращаемому числу можно определить в каком бите (или в нескольких разных битах) всей последовательности битов произошла ошибка.

**ARV** · 24 июня, 2019

4 часа назад, kostya_unix сказал:
У меня выводится число 99
lcd_dat(((checkcrc()/100)%10)+48);
lcd_dat(((checkcrc()/10)%10)+48);
lcd_dat((checkcrc()%10)+48);

Это же ужас какой-то! Вы трижды обращаетесь к функции подсчета CRC, хотя логично предполагать, что она должна вызываться один раз:

uint8_t crc = checkcrc();
lcd_dat(((crc/100)%10)+48);
lcd_dat(((crc/10)%10)+48);
lcd_dat((crc%10)+48);

**kostya_unix** · 25 июня, 2019

Уважаемый @ARV простите меня за этот код:

lcd_dat(((checkcrc()/100)%10)+48);
lcd_dat(((checkcrc()/10)%10)+48);
lcd_dat((checkcrc()%10)+48);

Хочется что-то сказать в свое оправдание.... Но на ум ничего не приходит.По всей видимости торопился, когда писал ответ на форум и скорей всего от незнания.

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

uint8_t crc_2; // объявлена глобально

int checkcrc()  // функция посчета значения контрольной суммы
		{
			uint8_t crc =0;
			
			for (uint8_t i=0; i<(sizeof term_code / sizeof term_code[0]); i++)
			//for (uint8_t i=0; i<8; i++)
			{
				crc = _crc_ibutton_update(crc, term_code[i]);
				
			}
			
			return crc_2=crc;
		}

Или есть другой способ отобразить, в данном случае, возвращаемые данные на LCD_дисплее?


lcd_dat('R');
lcd_dat('C');
lcd_dat('_');
lcd_dat('2');
lcd_dat('=');
lcd_dat(((crc_2/100)%10)+48);
lcd_dat(((crc_2/10)%10)+48);
lcd_dat((crc_2%10)+48);

Подскажите пожалуйста.

22 часа назад, Starichok сказал:

вот, ты нашел алгоритм вычисления CRC.

ты должен был понять, что при вычислении обрабатывается КАЖДЫЙ бит всей последовательности плюс участвует КАЖДЫЙ байт последовательности.

а теперь поищи в инете, что такое CRC и что по возвращаемому числу можно определить в каком бите (или в нескольких разных битах) всей последовательности битов произошла ошибка.

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

Если не получится самостоятельно разобраться, пойду в институт к своему преподавателю по математики, попрошу ее растолковать мне эту методику.

Она нам всегда говорила, что красивей математики может быть только музыка.

**ARV** · 25 июня, 2019

1 час назад, kostya_unix сказал:

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

Очего сразу глобальной? Любой. Глобальные переменные - это палка об двух концах, увлекаться ими без конкретной нужды не стоит.

1 час назад, kostya_unix сказал:

Или есть другой способ отобразить, в данном случае, возвращаемые данные на LCD_дисплее?

Конечно есть. Просто следуйте простому правилу: если что-то делается несколько раз с разными данными, это должно быть функцией.

У вас есть функция вывода символа на дисплей. Чем отличается вывод строки символов от вывода одного символа? Тем, что повторяется несколько раз. Чем отличается вывод строки "Вася" от строки "123"? Ничем. Следовательно, вывод строки должен быть функцией. Как вывести число? Можно так, как вы, а можно иначе: превратить число в его строковое (т.е. сивольное) представление и вывести эту строку.

А для превращения числа в строку применить библиотечную функцию itoa - её именно для того и придумали, чего ж добру пропадать?

И ваш код из предыдущего поста превратится в что-то такое:

/* забудем это, как страшный сон
lcd_dat('R');
lcd_dat('C');
lcd_dat('_');
lcd_dat('2');
lcd_dat('=');
lcd_dat(((crc_2/100)%10)+48);
lcd_dat(((crc_2/10)%10)+48);
lcd_dat((crc_2%10)+48);
*/

// сделаем функцию вывода строки на ЖКИ
void lcd_put_str(char *s){
   while(*s) lcd_dat(*s++);
}

// сделаем функцию вывода числа
void lcd_put_int(int i){
   char tmp[10];
   itoa(i, tmp, 10);
   lcd_put_str(tmp);
}

lcd_put_str("RC_2=");	// выведем информационный текст
lcd_put_int(crc_2);	// и выведем переменную

1 час назад, kostya_unix сказал:

return crc_2=crc;

Зачем?! Просто return crc; и тогда можно даже так

lcd_put_int(checkcrc());

1 час назад, kostya_unix сказал:

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

Совершенно бесполезная трата времени для прикладных целей! Если вы не решили посвятить себя теории программирования, то вам эти знания не будут полезны от слова совсем. Тем более что CRC8 не позволяет однозначно выделить искаженный бит, даже если он один, а если несколько - и подавно.

Starichok · 25 июня, 2019

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

думаю, и тебе такие тонкости не нужны.

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

а если бояться, что чтение из датчика идет с ошибками, тогда надо и бояться, что команды до датчика доходят с ошибками. а там не далеко и до паранойи...

**kostya_unix** · 25 июня, 2019

@ARV и @Starichok спасибо Вам бОльшое за участи в моем "гиблом" деле Я прям увереннее стал чувствовать себя, спасибо.

В ближайшее время обязательно ознакомлюсь с функцией itoa, со строковым представлением символьных данных.

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

Учится мне еще и учится.

**ARV** · 25 июня, 2019

Только что, Starichok сказал:

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

Очень зря.

Starichok · 25 июня, 2019

тем, кто считает, что я это делаю зря, напомню:

8 часов назад, Starichok сказал:

если бояться, что чтение из датчика идет с ошибками, тогда надо и бояться, что команды до датчика доходят с ошибками. а там не далеко и до паранойи..

на плохой линии связи ошибки могут быть в ОБЕ стороны.

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

а на моих 20 см просто не может быть плохой связи...

**ARV** · 26 июня, 2019

13 часа назад, Starichok сказал:

а на моих 20 см просто не может быть плохой связи...

Теоретически - да. А на практике место пайки датчика может окислиться и контачить через раз от всякого дуновения ветра. И вы будете в полной уверенности заходить в парную, думая, что там 90 градусов, а там всего 50. Или 150. Приятная неожиданность.

13 часа назад, Starichok сказал:

на плохой линии связи ошибки могут быть в ОБЕ стороны

Правильно, так и есть. Но на приеме датчик просто проигнорирует то, что не понял, и, соответственно, при последующем запросе ответит "не так", как ожидалось.

13 часа назад, Starichok сказал:

чем делать кучу попыток чтения, пока не совпадет контрольной число

Для большинства "термометров" и не надо делать попытки чтения, достаточно продолжать некоторое время делать обычные запросы, не обновляя выходные данные, а потом, если нормальные пакеты так и не поступят, перейти в состояние "ошибка".

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

Starichok · 26 июня, 2019

3 часа назад, ARV сказал:

Но на приеме датчик просто проигнорирует то, что не понял, и, соответственно, при последующем запросе ответит "не так", как ожидалось.

первая часть предложения правильная.

что значит, ответит не так?

датчик проигнорирует не правильно принятую команду и вообще ничего не ответит.

3 часа назад, ARV сказал:

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

а обычные запросы это разве не попытки чтения?

да, и у меня нет бани.

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

**ARV** · 26 июня, 2019

Только что, Starichok сказал:

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

Только вот как узнать об этом без подсчета CRC? На глазок? Вы уверены, что датчик вам всегда вернет значение, которое вы сразу опознаете, как недостоверное?

В общем, спорить более не буду - как уже говорил, каждый вправе выстрелить себе в ногу своим способом.

Starichok · 26 июня, 2019

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

если последовательность команд до датчика дошла правильно, то и ответ будет правильный.

и у меня встречный вопрос:

прежде чем считать CRC, как узнать, что последовательность команд до датчика дошла правильно?

какая-то у тебя односторонняя паранойя - только на принятую последовательность. а к отправленной ты почему-то равнодушен...

**ARV** · 26 июня, 2019

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

3 часа назад, Starichok сказал:

прежде чем считать CRC, как узнать, что последовательность команд до датчика дошла правильно?

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

Starichok · 26 июня, 2019

а ты, похоже, забыл, что производитель пишет в даташите, что можно прервать чтение в любой момент, не читая все 9 байтов?

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

а если можно не читать, так зачем мне тратить драгоценное процессорное время на чтение еще 7 байтов и на подсчет?

**ARV** · 26 июня, 2019

4 минуты назад, Starichok сказал:

драгоценное процессорное время

Какой курс драгоценностей к рублю? Или вы их на зиму засаливаете, сэкономленные такты и байты?

Starichok · 26 июня, 2019

ладно, оставим тему необходимости расчета CRC.

ты мне вот что расскажи.

вот формула расчета CRC = X⁸ + X⁵+ X⁴ + 1. также в даташите есть схема расчета.

я не понимаю, как связан этот алгоритм расчета с числом 0х8С, откуда взялось это число?

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

причем, анализируется каждый бит на равенство 1. а из схемы расчета я вижу, что "xor" должно делаться безусловно после 4, после 5 и после 8 бита, если я правильно понимаю схему.

и в схеме расчета я совершенно не вижу прибавления 1, которое есть в формуле.

Войти

Инициализация DS18B20

Рекомендуемые сообщения

Ссылка на комментарий

Поделиться на другие сайты

Топ авторов темы

Топ авторов темы

Популярные посты

ARV

kostya_unix

Starichok

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Присоединяйтесь к обсуждению

Последние посетители 0 пользователей онлайн

Сообщения