Ненавязчивая автоматизация ректификационной установки

Мне не приходилось работать с DS-ками на таких расстоянии. В Сети встречалась информация на эту тему. Тут, как говорят, - гугл в помощь ;) Могу сказать что-нибудь полезное только из общефизических соображений.

1. Если используется фазовый симисторный регулятор, а сеть хорошая, мощная или мощность ТЭНа просто не превышает пары-тройки кВт, то лучше использовать регулятор с пропуском импульсов (ака Брезенхем). В отличие от фазового, он не дает импульсных помех. Ни в сеть, ни в пространство. А 6-метровые провода много что могут наловить...
2. Естественно, - нормальное питание DS-ок, а не паразитное.
3. Поставить емкости на питание каждой DS-ки (прямо на самих DS-ках).
4. Использовать 5-вольтовую логику вместо 3.3-вольтовой.
5. Коллега makh в свое время советовал использовать две витые пары для подключения DS-ок (одна - земля-сигнал, вторая - земля-питание). Сам не пробовал, но из общефизических соображений понятно, что будет лучше, чем что-то не свить, или, не дай Бог, все три вить ;)
6. Подтягивающие резисторы в сочетании с емкостью витых пар определяют фронты импульсов (от низкого к высокому). Поэтому емкость витых пар нужно стараться сделать поменьше. Для 6 метров и характерных для 1-Wire времен, вопрос где конкретно ставить резисторы, ИМХО, не актуален.

Ну вот это пока все, что пришло в голову ;)

PavelSaratov, ПМСМ, кроме программных вопросов есть и "железные". Любая линия связи(кабель) имеет своё волновое сопротивление. Витая пара имеет ок 110 Ом. (РК= 50-75). Если нет согласования- сигналы имеют хер знает какую форму. На одной из тобой приведённых ссылок 4.7 кОм у каждого датчика параллельно, а их 3.
ПС, возможно не так ставил вопрос. У Ардуино при длинных проводах, пишут, проблемы с датчиками. Разными.

Волновое сопротивление имеет смысл на отрезках не 6 метров, мы и на 800 метров без EOL резисторов запускали профибас дп тока в путь. У ардуины возможно и есть такие проблемы - она воодще сама по себе проблема. Я к тому что не в резисторе дело. У него симистор все глушит (как я понял)- для сего примитивного протокола  - наведенное напружение (это предположение). Ну поставить экранированный витая пара КВВГэ где экран посадит прямо на штырь в земле ради эксперимента. Но не думаю что дело вообще в этом месте где ищет вопрошающий.
PS чукча писатель... не читатель.. это я про себя. Все пытаюсь промышленное применить. ДА точно в наводке импульсной дело. OldBean написал. Там же напруги с милиписькин нос Там и чихнувший электрик все пожечь может. Одно точно мне понятно - не в волновом сопротивлении дело.
ЗЗЫ Был пьян. Возвращаюсь с работ.

Всем доброго здравия и с наступающим Новым Годом!
Извиняйте, отсутствовал, был сильно загружен.
Хочу подискутировать с Сергеем (OldBean)

здесь нужно обязательно подчеркнуть, что те решения, которые публикует и предлагает для повторения уважаемый коллега BogAD, целиком лежат на его ответственности.OldBean, 26 Дек. 17, 07:24

Не привыкать Перед бюргерами из Германии частенько отстаиваем свои точки зрения.
Сергей, начнем по порядку.
С вариантом LITE я полностью согласился. Узрел, так сказать "изюминку".

Не думаю, что это сине льно хорошая идея. Дело в том, что контактор здесь стоит не только для автоматического отключения высокого, но и для автоматического запуска установки. Или я что-то не так понял?OldBean, 26 Дек. 17, 07:24

Я не понял, что значит "Автоматический запуск установки"? Если все нормально, то контактор не нужен, справится триак. Нужен только аварийный стоп! А это в случае смерти триака ТЭНа.
Я тут не так далеко, по теме, затеял обсуждения, что надо иметь защиту от пробоя триака. Намудрил даже контроль напряжения на нагрузке, в частности на ТЭНах.
На форуме, тут,  жарко обсуждалось.
Сергей, ты же определился, провел работу "Моделируем смерть триака в контроллере ТЭНа". Указал, что температура ТСА (по совету [сообщение #13096551])лучший способ узреть аварию. Не буду тыкать пальцем по форуму, то с 32  по 35 страничку вроде вся соль есть.
Тут я уже отметился [сообщение #13099884]

(Лень корректировать - вспом.цепи - это UPS (блок питания) на 5 В.)
Включаем автомат + диф.автомат (УЗО) и работаем.
Допустим, заимели неисправимую Малинкой аварийную ситуацию (пробился на коротко триак) - заставляем вырубиться диф.автат (УЗО). Ну убедили же меня тут на форуме, что надо избегать "избыточности" и я отказался от контактора в пользу диф.автомата. Или зря?
А по "унификации"... Ту так, если плату под триак в разных корпусах сразу делать, почему бы и нет.
Первый вариант у меня такой и был.
Но вот под диф.автомат (УЗО) я все же отдельную платку QFD запланировал и сделал.
Вот только думаю что поторопился. Ну не нужно под нее планировать ATtiny! Избыточно это.
Схемку надо делать на инвертирование шинки INT'а для открытия оптопары (при 0 на  INT) для замыкания диагонали диф.автомата (УЗО) и этого достаточно. Думать надо...

BogAD, симистор ВТ131 с кучкой резисторов ни к чему. моська через резистор 5,6к успешно вырубает дифавтомат.

симистор ВТ131 с кучкой резисторов ни к чему. моська через резистор 5,6к успешно вырубает дифавтомат.m16, 28 Дек. 17, 23:34

Да, я не спорю. Sevpro уже советовал.
Сподвигла идея, что если резюки закоротить, сгодится за силовой. Но, буду отказываться в сторону голой МОСьки.

да, и моську нужно ставить с сross zero  типа MOC3081, MOC3082, MOC3083.

да, и моську нужно ставить с сross zero  типа MOC3081, MOC3082, MOC3083.m16, 28 Дек. 17, 23:48

Не обязательно... Смысла нет. Открыть можно при любом значении синусоиды. А на 0 диф.автомат не сработает.
Да и простые МОСЬки дешевле.
Короче, дело вкуса.

это не вкус а правило. правило грамотного проектирования .

это не вкус а правило. правило грамотного проектирования .m16, 28 Дек. 17, 23:57

А смысл? Допустим, открываем МОСьку только на 0. Диф.автомат не  сработает, т.к. нет достаточного тока утечки по диагонали. Ждем (держим открытой МОСьку) пока синус не даст требуемый ток утечки. И... рубим силовые контакты диф.автомата. От чего ушли, к тому и пришли...

Перед бюргерами из Германии частенько отстаиваем свои точки зрения.BogAD, 28 Дек. 17, 23:19

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

Если все нормально, то контактор не нужен, справится триак.BogAD, 28 Дек. 17, 23:19

Контактор, в отличии от триака, физически отрубает оба сетевых провода. Т.е. при помощи контактора у малинки есть возможность полностью обестОчить (на какое-то время) и обратно затОчить ;) силовую часть системы.

Перекосить и вырубить дифавтомат при помощи малинки - нехитрое дело. Но как его обратно врубить (без дяденьки-оператора)? Может быть как-нибудь просто и можно. Но я, увы, не понимаю как. Если понимаете - расскажите...

---

---

PS
Кстати, есть хорошая новость - вот уже вторые сутки малинка с тинькой (ATtiny85 на макете) непрерывно общается по I2C. Обмен байтовый. Малинка посылает тиньке байт (все 8 бит). Тинька его получает, кое что (старший и младший биты ;) показывает на светодиодиках, и отсылает его обратно малинке. Малинка сравнивает полученное с отправленным, делает выводы, инкрементирует байт и все повторяет в бесконечном цикле. В тиньке протокол I2C реализован на основе ёйного модуля USI и свободной библиотеки usiTwiSlave. Самое забавное, что "проблема старшего бита" при таком решении полностью "рассосалась". Около 6 млн полнобайтовых обменов - 0 ошибок! Правда это - при пониженной скорости (9600 бод). На более высоких пока не пробовал. Да, в общем, не сильно-то и нужно.

"Сухой остаток": ATtiny85, в качестве мозгов силового модуля в варианте LITE, остается... ;)

Новый год стучится в дверь!
Радость и веселье!
А нас сдружила автоматика -
Чудное изделие!
Ребята, всех поздравляю с Новым годом. Всем желаю здоровья, счастья и творческих успехов.

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

С новым годом!

С Новым Годом! Мира всем! Всего наилучшего!
 

 

 

17.X.2. Вариант LITE. Реализация I2C для связи малинки (master) с МК ATtiny85 (slave)

Итак, в самом конце ушедшего года было проведено долговременное тестирование надежности обмена по протоколу I2C между малинкой и микроконтроллером ATtiny85. Тестирование проводилось на пониженной скорости 9600 бит/сек. Непрерывная и безошибочная работа теста в течении более 3-х суток окончательно сняло вопросы надежности протокола (так и его конкретных реализаций) для наших задач. Особенность реализации I2C на тиньках заключается в том, что в младших линиях МК AVR нет готового модуля TWI, совместимого по протоколу с I2C. Тем не менее, есть универсальный модуль-заготовка USI, облегчающий программно-аппаратную реализацию различных "последовательных" протоколов. В том числе и I2C. Поскольку малинка в нашей системе всегда работает в качестве единственного мастера, нам достаточно организовать работу USI всех используемых в системе тинек только в качестве ведомых устройств (I2C Slave). Для этого у Atmel есть соответствующая апнота AVR312 и библиотека usiTwiSlave. В сети есть несколько более "продвинутых" форков этой библиотеки. Я остановился на варианте, который часто используется в библиотеке TinyWireS для ардуинок. Для реализации I2C Slave на тиньках нам нужно взять из архива этой библиотеки всего два файла: usiTwiSlave.c и usiTwiSlave.h. Реализация I2C на базе USI и библиотеки usiTwiSlave, увы, убога, но, думаю, для наших задач вполне хватит. Будем "скрашивать убогость" протоколами прикладного уровня ;) Кстати, тест до сих пор "крутится" на работе (сегодня - это уже "с того года" ;). Как-нибудь в каникулы заеду цветочки полить - посмотрю что и как. Интересно...

Все файлы, необходимые для реализации и тестирования I2C Slave на тиньках я собрал в кучу и положил в архив в приложении к данному топику. Пример использования - в обучающих "прописях" для новичков ниже.

---

---

В этом разделе топика приведены некоторые детали проведенного тестирования, ориентированные на новичков, желающих попрактиковаться в программировании обмена между маликой и тинькой. Как уже мы договорились раньше, в качестве рабочей станции для программирования мы будем использовать малинку, снабженную HDMI монитором, клавиатурой и мышкой. Если программное обеспечение для программирования микроконтроллеров AVR на малинке еще не было установлено, его можно установить всего одной командой из консоли: Итак, "прописи" по шагам.
1. Собираем тестовый макет. Схема макета для теста и общий вид представлен на рисунке ниже.

Подключаем макет к шине I2C крейта (или просто к соответствующим пинам малинки SCL1, SDA1 и Ground). Подсоединяем к макету USBasp-программатор (удобно сделать специальный ISP6-разъем, который можно втыкать в макетку). Включаем малинку и подключаем USBasp-программатор к свободному USB-разъему малинки.

Ну тут вроде бы ничего сложного нет. Но ежели что непонятно - можно обсудить подробнее - спрашивайте.
2. Подготовка тиньки к работе. Если микроконтроллер, который мы установили на макет, совсем новый, то нам нужно перепрошить часть его фьюзов (fuse). Дело в том, что тактовая частота на заводе установлена на 1 МГц (внутренний калиброванный генератор на 8 МГц и делитель тактовой частоты на 8). А нам бы хотелось тактировать МК от высокочастотного внутреннего ФАПЧ-генератора, который выдает 16 МГц. Эти дела, как раз и устанавливаются фьюзами.

Фьюзы - это программируемая энергонезависимая память. Своеобразный внутренний аналог "перемычек", при помощи которых можно устанавливать базовые параметры МК. В ATtiny85 под фьюзы отведены 3 байта: традиционные старший (high - H) и младший (low - L) байты и один расширенный байт (extended - E). Смысл каждого бита этих байтов можно посмотреть в datasheer на чип. Мы здесь рассмотрит только отдельные биты младшего байта, которые отвечают за тактирование микроконтроллера.

2.1. Но сначала просто проверим работоспособность нового МК. Запускаем нашу IDE geany, которую мы настроили здесь. В редактор скопируем следующий текст:

Скрытый текст

// Заводские установки тактовой частоты - 1 МГц. Определение F_CPU говорит
// компилятору об этом. Иначе функции задержки (в частности, _delay_ms)
// будут работать неправильно
#define F_CPU 1000000UL  
                         
#include <avr/io.h>
#include <util/delay.h>

int main(void) {
  DDRB |= 0b00001000;    // Пин 3 порта B - на вывод
  while(1) {             // Бесконечный цикл
    PORTB |= 0b00001000; // На пин PB3 - высокий уровень
    _delay_ms(500);      // Задержка 0.5 сек
    PORTB &= 0b11110111; // На пин PB3 - низкий уровень
    _delay_ms(500);      // Опять задержка 0.5 сек
  }
  return 0;
}

Эта простейшая программа мигает с частотой 1 Гц одним светодиодиком, который подключен к пину PB3. Сохраняем файл в рабочей директории. Пусть его название будет (для определенности) main.c. После этого нажимаем F8. Если сборка прошла успешно, нажимаем F9. Эта команда запускает утилиту avrdude для прошивки МК. После небольшой паузы мы увидим размеренное мигание светодиодика.

2.2. Теперь посмотрим содержание фьюзов, установленных на заводе. Для этого воспользуемся этой же утилитой avrdude. В нижней части окна geany щелкаем по закладке "Терминал" (естественно, можно просто запустить отдельный терминал). В окне терминала нужно написать команду:Здесь параметр -c означает тип программатора, а -p - марку микроконтроллера. Если интересуют подробности, можно воспользоваться подсказкой avrdude (набрать: avrdude --help). Примечание: копировать команду в терминал можно правой клавишей мышки или клавиатурой - sift+insert. По этой команде avrdude прочитает память чипа и выведет на консоль информацию о нем. Там должна быть такая строчка:В скобочках как раз и выведено содержимое всех трех байтов фьюзов в шестнадцатеричном формате. Нас интересует младший байт. В нем записано шестнадцатеричное число 62, которое в двоичном представлении выглядит так: 0110 0010. Нулевое значение самого старшего (самого левого) бита означает то, что включен делитель тактовой частоты на 8. А биты младшего полубайта (0010) в совокупности означают то, что для тактирования используется внутренний калиброванный RC-генератор с частотой 8 МГц.

2.3. Что же теперь нам нужно сделать? Нам нужно 1) выключить делитель на 8, т.е. самый старший бит установить в единичку, и 2) в младший полубайт записать число 0001. Это как раз означает, что тактирование чипа будет производиться с частотой 16 МГц от высокочастотного ФАПЧ-генератора (см.datasheet). Остальные биты не будем трогать.

Итак, в младший байт фьюзов мы должны записать двоичное число 1110 0001. В щестнадцатеричном виде это 0xE1 (для avrdude такие параметры нужно указывать в шестнадцатеричном формате). Примечание: префикс 0x перед числовым значением во многих языках программирования как раз и означает именно шестнадцатеричный формат числа. Ну теперь осталось только попросить avrdude это значение записать в чип. Для в той же консоли этого пишем:Здесь -U означает, что далее следует описание команды работы с памятью чипа: lfuse - работаем с младшим байтом фбюзов, w - пишем туда, 0xE1 - это как раз то, что мы пишем и m - означает то, что информацию (то самое значение 0xE1, которое дуда должна записать) нужно брать именно непосредственно из команды, а не из, например, файла.

Перед тем, как нажать Enter, трижды проверяем, что мы тут понаписали (фьюзы - штука весьма критичная к ошибкам!). Жмем... Мы увидим, что наш светодиодик замигал быстро-быстро. Все правильно! Тактовая частота сменилась на 16 МГц. А теперь мы скажем компилятору об этом факте в тексте программы. Т.е. откорректируем определение F_CPU:Сохраняем файл, жмем F8, затем F9. Все. Светодиодик опять мигает с частотой 1 Гц. На этом подготовка ATtiny85 к работе считаем законченной. Переходим к связи малинки с тинькой по I2C.
3. Исходники firmware состоят из трех файлов с кодом: main.c, usiTwiSlave.c, usiTwiSlave.h и Makefile. Все эти файлы должны лежать в одной папке рабочей станции, при помощи которой будет программироваться тинька. У нас этой рабочей станцией, как мы договорились раньше, является сама малинка, снабженная HDMI монитором, клавиатурой и мышкой.
3.1. main.c - это главный файл приложения с основным бесконечным циклом и простым байтовым протоколом обмена с малинкой. В цикле анализируется буфер, куда складываются байты, принятые от малинки. Если байт принят, он считывается, два его младших бита отображаются на светодиодиках (это полезно для отладки, да и просто чтобы не скучно было ;) и этот же байт отправляется обратно малинке. Код построчно прокомментирован. Думаю, должно быть все понятно.

Скрытый текст

#define F_CPU 16000000UL
                         
#include <avr/io.h>
#include <avr/interrupt.h>
#include "usiTwiSlave.h"

int main(void) {
  uint8_t w = 0, slaveAddr = 0x04; // Адрес тиньки на шине I2C

  sei(); // Разрешаем глобальные прерывания (нужны для б-ки usiTwiSlave)
  usiTwiSlaveInit(slaveAddr); // Инициализация I2C/TWI обмена
  DDRB |= _BV(PB3) | _BV(PB4); // Пины PB3 и PB4 - на вывод (для индикации)
  while(1) { // Бесконечный цикл
    if(usiTwiDataInReceiveBuffer()) { // Если приняты данные в буфере...
      w = usiTwiReceiveByte(); // Читаем в w принятый байт
      // Покажем старший и младший бит на светодиодиках
      PORTB = (PORTB & 0b11100111) | ((w & 0x80) >> 3) | ((w & 0x01) << 3);
      usiTwiTransmitByte(w); // Отправляем этот же байт обратно малинке
      asm volatile("NOP" ::); // Просто очень маленькая задержка
    }
  }
  return 0;
}

3.2. Файлы usiTwiSlave.c, usiTwiSlave.h. Как уже отмечалось выше, это - код библиотеки, которая реализует протокол I2C на тинькином модуле USI и заголовочный файл. Писано на Си. Форков (в том числе и точно с такими же именами файлов) в Сети хватает, поэтому, для однозначности, я эти файлы прикладываю в этом же архиве.
3.3. Makefile. Это очень полезная штука для компиляции и сборки многофайловых проектов. С помощью Makefile можно не только компилировать и собирать программы, но и выполнять другие полезные действия, которые может выполнить ОС. Например, прошить тиньку или просто убрать кучу вспомогательных файлов, потерявших актуальность. Работать с уже настроенным Makefile легко. Для компиляции нужно просто набрать в командной строке Чтобы прошить тиньку:Чтобы почистить рабочую директорию от генерируемых файлов:Понятно, что все файлы (и мы сами) должны быть в одной (текущей) директории ;)
4. В этот же архив я положил проверочный тест на питоне (файл test_05.py). Он выполняется на малинке. Каждая строчка питоновского кода тоже прокомментирована. Так что разобраться будет несложно. Общий смысл скрипта - бесконечное общение с тинькой. Отправляем байт тиньке, получаем байт обратно и сравниваем. Они должны совпадать. Ежели нет - обрабатываем ошибку и выводим соответствующее сообщение на консоль. Содержание отправляемого байта изменяется от 0 до 255. В каждом такте цикла. Текст кода:

Скрытый текст

# _*_ coding: utf8 _*_
import time
import smbus
bus = smbus.SMBus(1)

ctr = 0      # Счетчик блоков (по 256 обменов)
i = 0        # Отправляемый тиньке байт
ie = 0       # Счетчик ошибочных обменов
while True:  # Бесконечный цикл
  bus.write_byte(0x04, i) # Отправляем байт тиньке
  time.sleep(0.01)        # Небольшая задержка
  w = bus.read_byte(0x04) # Принимаем байт обратно (от тиньки)
  if(i <> w): # Если случилась ошибка обмена
    ie += 1  # Модифицирем счетчик ошибок и выдаем сообщение об ошибке
    print '%d - error: %d (i) <> %d (w); \ttdel = %d' % (ie, i, w, i - w)
  time.sleep(0.01) # Опять небольшая задержка
  i += 1     # Модифицируем байт (его отправим тиньке на следующем такте цикла)
  if i > 255:  # Превысили границу байта - значит еще один блок теста пройден
    i = 0; ctr += 1; # Сбросим байт на 0 и модифицирем счетчик блоков
    print str(ctr) + '\t' + str(ie) # Доложим об этом

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

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

---

Предыдущий топик  Вернуться к оглавлению  Следующий топик

OldBean, есть ATTINY85-20PU DIP-8, а есть ATTINY85-20SU СОП-8. Какие заказывать? Или все равно?

есть ATTINY85-20PU DIP-8, а есть ATTINY85-20SU СОП-8. Какие заказывать? Или все равно?ZagAl, 01 Янв. 18, 17:35

Если сами будете разводить, то, в общем-то, все равно. Если же будете использовать готовые разводки (не важно, вариант BogAD или мой), то они сделаны под корпус DIP-8.

Корпуса разные.

Есть принятые обозначения индексов микроконтроллеров AVR семейства ATmega и ATtiny:

После обозначения базовой версии и серии микроконтроллера, через дефис идет индекс, указывающий вариант исполнения микроконтроллера.
Индекс состоит из 1-2 цифр, которые означают максимальную частоту, на которой микроконтроллер может стабильно работать при нормальном для него напряжении питания, и из 1-3 букв, которые обозначают вариант корпуса, температурный диапазон работы, и особенности изготовления.
Первая буква (или две буквы) после частоты обозначает тип корпуса:
P — корпус DIP (PDIP)
A — корпус TQFP
M — корпус MLF
TS — корпус SOT-23 (ATtiny4/5/9/10)
J — корпус PLCC
A — корпус UDFN/USON
C — корпус CBGA
CK — корпус LGA
S — корпус EIAJ SOIC
SS — узкий корпус JEDEC SOIC
T — корпус TSOP
X — корпус TSSOP


Следующая буква означает температурный диапазон и особенности изготовления:
C — коммерческий температурный диапазон (0 °C — 70 °C)
A — температурный диапазон −20 °C — +85 °C, с использованием бессвинцового припоя
I — индустриальный температурный диапазон (-40 °C — +85 °C)
U — индустриальный температурный диапазон (-40 °C — +85 °C), с использованием бессвинцового припоя
H — индустриальный температурный диапазон (-40 °C — +85 °C), с использованием NiPdAu
N — расширенный температурный диапазон (-40 °C — +105 °C), с использованием бессвинцового припоя
F — расширенный температурный диапазон (-40 °C — +125 °C)
Z — автомобильный температурный диапазон (-40 °C — +125 °C)
D — расширенный автомобильный температурный диапазон (-40 °C — +150 °C)
Еще в самом конце может быть буква R, которая означает, что микроконтроллеры упакованы в ленты для автоматизированных систем сборки

Т.е.
PU - корпус DIP (PDIP) под отверстия, индустриальный температурный диапазон (-40 °C — +85 °C), с использованием бессвинцового припоя
SU - корпус EIAJ SOIC поверхностный монтаж, индустриальный температурный диапазон (-40 °C — +85 °C), с использованием бессвинцового припоя

Какие заказыватьZagAl, 01 Янв. 18, 17:35

В принципе без разницы, просто если работать по готовым платам, понадобится ещё переходник SOP8-DIP8, там же, где и Тиньки, стоят около 2$/десяток.
Кстати, довольно удобно, если на основную плату воткнуть панельку для возможности быстрой смены контроллера.

Вероятно не совсем в тему, но спрошу. На достаточно длинном кабеле(ок 6 м.) как лучше обвешивать DS18B20? Где ставится 4.7 кОм, или он делится? Про сбои встречал [сообщение #13176612] , а про согласование линии нет(R= 110 Ом). С симисторным регулятором стал ловить помеху: Т= -127.00*С. На ДС-ку повесил небольшую керамику. Дроссели/трансформатор на входе регулятора пока не ставил, в процессе моделирования. У ТС тоже не встречал.Рюрик1955, 28 Дек. 17, 05:13

Просто может кому полезно будет. Комплекс мер для улучшения 1-wire обмена
http://catethysis.ru/1-wire-tipsntricks/