Всё по DS18(B/S)20.

[OKF]

Работать не будет. Как вы 0 из МК получите на дате?

[BOB51]

Для "слишком длинных" шлейфов обычно такой переходник используется (при соответствующей доработке программы управления обменом):
https://img.radiokot.ru/files/20529/1us0r4a0ua.GIF
Но в реале даже трехметровый шлейф на основе "телефонного кабеля"
https://img.radiokot.ru/files/20529/26egzlfrya.jpg
вполне устойчиво работает даже с обычными выводами адуринко-нано (прямое подключение к выводам МК) без всяких дополнительных защит.
Но то ДЛЯ ОДНОГО ДАТЧИКА НА ОДНОМ ВЫВОДЕ МК.
В случае двух датчиков на одном выводе - смотрим апноты построения сетей микроLAN или цепляем каждый датчик на свой вывод.
Второе... Желательно не использовать в качестве линий связи с "удаленными устройствами" выводы МК, отвечающие за работу внутрисхемного программирования (прошивки МК по протоколам ISP).
Ну и скорее всего, ежли учитывать что все довольно долго работало, имело место повреждение содержимого ПЗУ (или скрытая ошибка в программе устройства).

[Di123]

OKF, ну как и раньше будет падать в ноль стабилитрон ему не мешает

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

а если как вариант построить полностью на изоляторе
питание через BS0505
данные обоих датчиков через ADUM1250

[BOB51]

Речь не о физическом (абсолютном) разрушении ячеек, а о разрушении находящейся в них информации.
Кстати... Это уже второй подобный вопрос на форуме...
Что тому причина - пока не ясно - может редковстречающаяся ошибка в коде программы, может "пограничное" (предаварийное) состояние ячеек ПЗУ, а может и "внешнее воздействие" (от импульсных помех до перегрева и разнообразного облучения, статического заряда или разряда).
Анализировать надо все - от схемы и реального монтажа платки до размещения и "внешних соседей".
Скорее всего таки имеет место ситуация, вызываюшая "случайную сработку" бутлоадера - ежли применялось чего-то из ардуинок.

[fomkin1912]

Интересное поведение 3-х датчиков Ds18b20, подключенных по 1wire, провод ПВС 3х0,75, 6м, подключены в конце провода "звездой", отвод одного датчика 80 см, двух других - по 40. При первоначальном подключении все 3 показывают верную температуру, но постепенно показания двух датчиков на коротких отводах мигрируют друг к дружке и в итоге примерно сравниваются. Условно, первоначально было 20 и 40 (правильно), но в конце станет например 28 и 29 (ошибочные показания).
Подключил шиной - все заработало почти как надо.
Адреса жестко записаны в EEPROM, т.е. перепутаться при опросе они не могут. За счет чего такой эффект? (чисто любопытно).

[veso74]

Покажите код. Хотя би фрагмент. В противном случае угадывания причину будет "магическое гадание".
"Постепенно" - сколько ето? Какое разрешение? 12 бит? Используете CRC и проводите анализ?
Time-диаграммы с лог. анализатора есть (корректность протокола 1-wire)? ...

[fomkin1912]

Разрешение 12 бит, CRC не проверяется. Было 2 опыта. В первом температура среды была 20 и 40 градусов, и постепенно сближалась, т.е. показания сближались на "законных" основаниях. Но когда 2 температуры сравнялись, расходиться они уже отказались. Во втором опыте сближение было возможно скачками при вкл-выкл, но так или иначе показания опять сравнялись и такими остались, навсегда. На все про все мин 10-20-30.
OneWire.cpp

Спойлер

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

#include "OneWire.h"

// Универсальный сброс для выбранного пина
uint8_t reset(uint8_t pin) {
	uint8_t response;
	cli();
	ONE_WIRE_DDR |= (1 << pin);
	ONE_WIRE_PORT &= ~(1 << pin);
	_delay_us(480);
	ONE_WIRE_DDR &= ~(1 << pin);
	_delay_us(70);
	response = (ONE_WIRE_PIN & (1 << pin));
	_delay_us(410);
	sei();
	return (response ? 1 : 0);
}

void writeBit(uint8_t bit, uint8_t pin) {
	cli();
	ONE_WIRE_DDR |= (1 << pin);
	ONE_WIRE_PORT &= ~(1 << pin);
	if (bit) {
		_delay_us(10);
		ONE_WIRE_DDR &= ~(1 << pin);
		_delay_us(55);
		} else {
		_delay_us(65);
		ONE_WIRE_DDR &= ~(1 << pin);
		_delay_us(5);
	}
	sei();
}

uint8_t readBit(uint8_t pin) {
	uint8_t bit = 0;
	cli();
	ONE_WIRE_DDR |= (1 << pin);
	ONE_WIRE_PORT &= ~(1 << pin);
	_delay_us(3);
	ONE_WIRE_DDR &= ~(1 << pin);
	_delay_us(10);
	if (ONE_WIRE_PIN & (1 << pin)) bit = 1;
	_delay_us(45);
	sei();
	return bit;
}

void writeByte(uint8_t data, uint8_t pin) {
	for (uint8_t i = 0; i < 8; i++) writeBit(data & (1 << i), pin);
}

uint8_t readByte(uint8_t pin) {
	uint8_t data = 0;
	for (uint8_t i = 0; i < 8; i++) if (readBit(pin)) data |= (1 << i);
	return data;
}

void setDevice(uint64_t rom, uint8_t pin) {
	reset(pin);
	writeByte(CMD_MATCHROM, pin);
	for (uint8_t i = 0; i < 8; i++) writeByte((uint8_t)(rom >> (i * 8)), pin);
}

mail.cpp

Спойлер

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

#include "config.h"
#include "OneWire.h"
#include "LCD1602.h"
#include "BtnHandler.h"
#include "i2c.h"

volatile uint32_t system_ms = 0;
uint32_t main_delay_ms = 30000;
float target_temp = 35.0;
float last_temp_s4 = 0.0;
uint64_t roms_to_use[SENSOR_COUNT];

ISR(TIMER0_OVF_vect) {
	TCNT0 = 131;
	system_ms++;
}

// Функция только для ЧТЕНИЯ из памяти (без команды старта преобразования)
double readScratchpad(uint64_t rom, uint8_t pin) {
	uint8_t low, high;
	if (reset(pin)) return -99.9;
	setDevice(rom, pin);
	writeByte(CMD_RSCRATCHPAD, pin);
	low = readByte(pin);
	high = readByte(pin);
	int16_t raw = (high << 8) | low;
	return (double)raw * 0.0625;
}

int main(void) {
	I2C_Init();
	LCD_Init();

	// Кнопки
	BTN_DDR_REG  &= ~((1 << BTN_PLUS) | (1 << BTN_MINUS));
	BTN_PORT_REG |=  ((1 << BTN_PLUS) | (1 << BTN_MINUS));

	// Таймер 0
	TCCR0 |= (1 << CS01) | (1 << CS00);
	TIMSK |= (1 << TOIE0);
	sei();

	// Загрузка ROM адресов (с исправленным приведением типов)
	for (uint8_t i = 0; i < SENSOR_COUNT; i++) {
		roms_to_use[i] = 0;
		for (uint8_t j = 0; j < 8; j++) {
			uint64_t b = eeprom_read_byte((uint8_t*)(i * 8 + j));
			roms_to_use[i] |= (b << (8 * j));
		}
	}

	uint32_t last_sensor_update = 0;
	char displayBuffer[20]; // Увеличен для безопасности
	char tempStr[8];

	while(1) {
		if (system_ms - last_sensor_update >= main_delay_ms || last_sensor_update == 0) {
			
			// --- ЭТАП 1: ЗАПУСК ПРЕОБРАЗОВАНИЯ (ОДНОВРЕМЕННО) ---
			// Команда для всех датчиков на DQ1
			if (!reset(DQ1)) {
				writeByte(0xCC, DQ1); // Skip ROM
				writeByte(CMD_CONVERTTEMP, DQ1);
			}
			// Команда для датчика на DQ2
			if (!reset(DQ2)) {
				writeByte(0xCC, DQ2); // Skip ROM
				writeByte(CMD_CONVERTTEMP, DQ2);
			}

			// Ждем один раз для всех датчиков
			_delay_ms(750);

			// --- ЭТАП 2: ЧТЕНИЕ РЕЗУЛЬТАТОВ ---
			// 1. Опрос 3-х датчиков на DQ1
			displayBuffer[0] = '\0';
			for (uint8_t i = 0; i < SENSOR_COUNT; i++) {
				double temp = readScratchpad(roms_to_use[i], DQ1);
				dtostrf(temp, 4, 1, tempStr);
				strcat(displayBuffer, tempStr);
				if (i < SENSOR_COUNT - 1) strcat(displayBuffer, " ");
			}
			LCD_String_xy(0, 0, "                "); // Очистка строки
			LCD_String_xy(0, 0, displayBuffer);

			// 2. Опрос 4-го датчика на DQ2 (Skip ROM, т.к. он один)
			if (!reset(DQ2)) {
				writeByte(0xCC, DQ2);
				writeByte(CMD_RSCRATCHPAD, DQ2);
				uint8_t l = readByte(DQ2);
				uint8_t h = readByte(DQ2);
				last_temp_s4 = (float)((h << 8) | l) * 0.0625f;
			}

			update_lcd_info();
			last_sensor_update = system_ms;
		}
		
		check_button();
	}
}

[BOB51]

Схема также пригодилась бы... может там отводы "на скрутке" и/или "пассивное питание" ("паразите повер").
ПВС не для микроLAN
На длине более 1.5-2 метров требуется или "телефонная лапша"
https://img.radiokot.ru/files/20529/26egzlfrya.jpg
https://img.radiokot.ru/files/20529/i1yvpkie4.jpg
или спецбуфер для кормежки линии
https://img.radiokot.ru/files/20529/1us0r4a0ua.GIF
А еще лучше смотрим соответствующие даташиты/аппноты.
Без контроля CRC не о чем вообще разговор вести (тем более под СИ - протокол обмена у микроLAN уж очень шустрый и требует разумного применения даже ежли готовый адуриний OneWire использовать).
Для теста самих датчиков и линии связи можно попробовать погонять программу для каждого из датчиков в отдельности без "добавок" из запроса/проверки адреса датчика. Да с контролем CRC.

(mail.cpp - ... ежли еще снова случай упаси боже гибрида ардуино и СИ в АВР студии... )
Посмотрел Вашу OneWire.cpp...
Это еще хорошо, что она хоть что-то смогла показать....

[fomkin1912]

Пришлось обратиться к ИИ.

Спойлер

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

Ваш случай — это «учебное пособие» по тому, почему топология «звезда» противопоказана для протокола 1-Wire, особенно на длинных линиях.

Вот наиболее вероятные причины, почему данные «залипают» или усредняются:

1. Отражения сигнала и «звон» (Звезда)
Шина 1-Wire — это не просто постоянный ток, это высокочастотные импульсы. Когда вы подключаете датчики звездой через 6 метров кабеля ПВС (который имеет довольно высокую емкость), каждый конец ответвления работает как зеркало для сигнала.

Импульс доходит до развилки, отражается от концов 40-сантиметровых отрезков и возвращается обратно, накладываясь на основной сигнал.

Возникает «звон» (осцилляции), из-за чего устройство считывает неверные биты.

2. Почему показания «мигрируют» и «слипаются»?
Это самый интригующий момент. Поскольку вы не проверяете CRC (контрольную сумму), контроллер принимает любой мусор, который пришел по линии, за валидные данные.

Эффект «Доминантного нуля»: В 1-Wire логический «0» — это активная подтяжка линии к земле, а «1» — это отпускание линии (пассивный подтяг резистором). Если из-за емкости кабеля или отражений один датчик «затянул» фазу передачи нуля чуть дольше, это может исказить данные соседнего датчика.

Синхронизация ошибок: Когда датчики находятся рядом и на коротких отводах, тайминги отражений для них почти идентичны. Ошибка чтения (битые биты в определенных позициях) становится систематической. Вы видите не реальную температуру, а результат наложения отраженного сигнала на данные.

Взаимное влияние: Если один датчик начинает передачу, а в это время эхо от предыдущего запроса еще не затухло, значения битов в младших разрядах могут начать подменяться нулями или единицами соседнего устройства.

3. Почему они «не расходятся» обратно?
Скорее всего, происходит сбой логики самого датчика или его внутреннего АЦП из-за проблем с питанием в момент конвертации.

При 12-битном разрешении датчик потребляет ток дольше и интенсивнее.

Если на линии 6 метров ПВС возникают просадки напряжения (особенно если питание паразитное), датчик может просто выдать в линию «последнее удачное» значение или застрять в неопределенном состоянии, пока его жестко не перезагрузят по питанию.

Почему помогла «шина»?
Когда вы перешли на шину, вы убрали «разветвитель», который работал как генератор помех. Отражения стали однородными и предсказуемыми, а емкость линии распределилась линейно.

Что можно было сделать (ради эксперимента):

Включить проверку CRC. Вы бы увидели, что в 90% случаев при «звезде» данные приходят битыми, и ваш код просто игнорировал бы их вместо того, чтобы записывать ошибочные 28°C.

Уменьшить номинал подтягивающего резистора (например, с 4.7 кОм до 1.5–2 кОм). Это помогает быстрее «заряжать» емкость кабеля и подавлять «звон».

Использовать витую пару вместо ПВС. У ПВС высокая межжильная емкость, что для 1-Wire губительно.

Хотите, я помогу составить правильный алгоритм проверки CRC для вашего кода, чтобы исключить такие «фантомные» показания в будущем?

[veso74]

Эти обобщения ИИ уже проведены при анализе и стандартизации 1-wire протокола и приняты во внимание. Он позволяет использовать гораздо более длинные провода. Подключите логический анализатор к 1-wire (китайский стоит напр. 5€). Увидите напр. 99% работы и ошибки (если таковые имеются). Расчеты для проверки будет без догадок и неясных процессов.

пример ниже к CH32V:

[BOB51]

Все прекрасно и давно расписано в документации по микроLAN сетям.
И тип кабеля (от витой пары до...) и топология сетей.
Да и в старые времена весьма часто формирование слота чтения/записи поручали UART вместо "программного лаподрыга" (использовался аппаратный модуль МК) - картинка пересылки байта весьма похожа на слот пересылки бита.
Как вариант - дополнительный МК с лаподрыгом на датчики и любой менее требовательный протокол обмена с основным МК.
Т.е. "периферийный адаптер-преобразователь", что может быть значительно удобнее иных ухищрений.

Это раньше при 0,000001 секунды на команду жестковато было - на сегодня МК пошустрее стали, может и СИ без ассемблерных вставок работать успевать будет.

veso74
Если свой мозг на ИИ надеется вряд ли чего иного у fomkin1912, получиться...
На всяк случай еще раз выложу архивное (и в этой теме наверняка уже ранее лежало):

aрр148ru_p.pdf

(450.65 КБ) 57 скачиваний

IB2_AN132ru.pdf

(235.78 КБ) 62 скачивания

DS18B20_for maxim_19_11_2016.pdf

(484.15 КБ) 53 скачивания

[Gudd-Head]

[uquote="fomkin1912",url="/forum/viewtopic.php?p=4778327#p4778327"]CRC не проверяется.[/uquote]
Дальше можно не читать.

[BOB51]

Добавлю апнотки на тему использования UART МК для работы с микроLAN :

AN214.pdf

(148.89 КБ) 51 скачивание

от максим/даллас

AVR318-Dallas-1-Wire.pdf

(128.74 КБ) 55 скачиваний

от атмела
Можеть кому пригодится...