Моргания лампочки и замыкание контактов — дело интересное и полезное для первых шагов. Но, как все мы помним со школы, чем нагляднее эксперимент, тем он интереснее. Я продолжу развивать проект из предыдущих серий, и сегодня мы прикрутим термодатчик 1-Wire для того, чтобы контролировать температуру в твоем многострадальном холодильнике. Того и гляди, скоро у тебя появится «умный» холодильник :).

В предыдущих сериях

Так как я продолжаю повествование с некоей точки, а не с самого начала, то пройдусь по тому, что уже имеется. В нашем арсенале Arduino mega2560 с поднятой ОСРВ scmRTOS. Прошивка позволяет моргать светодиодом L на плате в разных последовательностях в зависимости от «аварийного» или «нормального» состояния, а также «плеваться» в консоль грязными ругательствами (ведь ты именно такие выбрал?) в качестве уведомления об изменении состояния. «Нормальность» состояния определяется замкнутостью контактного датчика. Последовательность можно менять из консоли. Исходники проекта выложены на GitHub.

Вдохнем новизны

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

Так в чем проблема? А вот в чем: можно было взять обычный резистивный термодатчик и использовать встроенный АЦП микропроцессора. Но! Я взялся за этот проект с правилом: минимум паяльника и дополнительного нестандартного оборудования, все из коробки. При использовании же резистивного термодатчика необходимо городить делитель напряжения, а значит, требуется минимальное, но погружение в схемотехнику. Так что этот вариант отпал.

Остался второй вариант — цифровой термодатчик. Правда, с ним тоже беда. Цифровой термодатчик подключается по интерфейсу 1-Wire, а такого интерфейса на плате нет. Зато есть вариант минимальными усилиями сделать программную эмуляцию этого интерфейса. Дополнительный бонус этого решения — термодатчиков можно посадить целый рассадник на одну проводную линию, в отличие от резистивного термодатчика (естественно, рекомендуется ознакомиться с матчастью, так как есть ограничения на длину линии, общее сопротивление и прочее).

 

Немного о самом 1-Wire

1-Wire — это так называемый однопроводный интерфейс. Примечателен он тем, что для обмена данными с устройствами по этому интерфейсу требуется всего один сигнальный провод и один провод «земли». Что еще более примечательно, устройства спроектированы таким образом, что по этому же сигнальному проводу они и «кормятся» (то есть для питания устройства используется все тот же сигнальный провод), такой режим называется «паразитным питанием». Для реализации такого способа питания в устройствах ставят достаточно емкий конденсатор.

Для того чтобы начать сессию обмена данными, необходимо сформировать сигнал «сброс». Для этого мастер передает в линию данных 0 на время не менее 480 мкс. После чего мастер отпускает линию данных и начинает слушать линию. За счет резистора подтяжки линия данных установится в 1. Если на линии присутствует устройство (датчик), то он передаст мастеру подтверждение сброса, для этого он удерживает линию данных в 0 на время 60–240 мкс. Считав состояние линии, мастер узнает о присутствии на шине устройств, готовых к обмену.

1-Wire обладает еще одной особенностью: передача битов осуществляется не уровнями сигнала, а временными задержками. Таким образом, чтобы передать 1, необходимо установить в линии 0 и держать его 15 мкс, после чего отпустить линию, которая за счет подтягивающего резистора перейдет в уровень 1. Чтобы передать 0, необходимо установить в линии 0 на 15 мкс, а затем держать 0 на линии еще 60–120 мкс.

 

Честный 1-Wire

Предложенный вариант реализации интерфейса 1-Wire обладает одним недостатком. Точнее, двумя.

1. Он жрет ресурсы (как любая программная эмуляция).
2. Он неустойчив к помехам.

С первым недостатком можно еще как-то мириться, хотя по мере роста проекта ресурсов остается все меньше. Со вторым недостатком в боевом софте надо бороться семплированием сигнала. Что такое семплирование? Допустим, бит 1 передается 6 мкс. Для того чтобы точно быть уверенным, что это 1, а не какая-то наводка, необходимо несколько раз в течение этих 6 мкс измерить состояние входного сигнала. Чем больше измерений ты проведешь, тем точнее будет твой результат и уверенность в правильности принятия данных. Однако 6 мкс — это ооочень мало, тут возникает вопрос разумности и аппаратных возможностей. С разумностью, хочется верить, у тебя все в порядке, а вот с возможностями в нашем микропроцессоре неважненько. Первое, что приходит в голову, — натравить таймер с частотой 1 мкс и получить хотя бы пять семплов. Проблема только в том, что в данном железе на такую частоту настроить таймер не представляется возможным. Настроить-то можно, но толку от этого не будет, так как надо учитывать накладные расходы на «проваливание» в прерывание, сохранение регистров, выход из прерывания. Другой вариант — мотание в цикле, но опять вопрос во времени. Такт процессора на частоте 16 МГц длится 1/16 мкс, то есть у тебя есть всего 16 тактов. За это ничтожное время тебе надо прокрутить счетчик (цикл же), снять состояние сигнала, перейти к следующей итерации. С учетом оптимизации и прочих накладных расходов на СИ сделать это практически нереально. Выход один — использовать аппаратную микросхему интерфейса 1-Wire, подключаемую, например, по SPI-интерфейсу.

Железо

Итак, выбор пал на термодатчик компании Maxim, модель DS18S20 (что под рукой оказалось). Если ты полез гуглить, сразу предупреждаю: подавляющее количество примеров применения термодатчиков с Arduino построено на базе DS18B20. Он немного отличается, но в рамках нашего проекта разницы никакой.

Термодатчик имеет два режима работы: постоянное питание или паразитное питание. Я буду использовать режим паразитного питания. В этом режиме термодатчик кушает через подтягивающий резистор (4,7 кОм) линии 1-Wire, когда линия «свободна» или передается высокий уровень. Как раз это вторая деталь, которую необходимо найти, резистор 4,7 кОм.

Другие статьи в выпуске:

Хакер #196. Все о Docker

• Содержание выпуска
• Подписка на «Хакер»-60%

Теперь, когда с подключением ты более или менее разобрался, приступим ко второй части нашего остросюжетного боевика. Нужно писать софт. Я, как и большинство программистов, создание ленивое, поэтому я вопросил у Всезнающего Гугла, что уже придумано до нас и надо ли изобретать велосипед.

Самое вразумительное, что я нашел, — это библиотека OneWire, рекомендуемая ардуиновцами. Также нам пригодится творчество еще одного товарища из ардуиновского сообщества — библиотека, реализующая протокол обмена данными с термодатчиком.

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

Ось зла

Предварительные причесывания

Начал я с простого — заставил хотя бы собираться библиотеки. Обе библиотеки используют ардуиновские функции, поэтому пришлось внести некоторые изменения. Для начала добавим файл OneWire_Port.h в проект (он будет портом библиотеки OneWire для проекта) и приинклюдим его в файл OneWire.h, а затем начнем причесывание. А именно:

• OneWire построена таким образом, что ей при создании экземпляра объекта скармливается номер ноги, на которой у тебя будет линия 1-Wire. Это тащит за собой кусочек мрака из недр библиотек Ардуино, поэтому я пошел простым путем и зашил хардкодом в конструктор класса OneWire нужные мне ноги. Да, теряем универсальность, но я пока не вижу применения с двумя шинами 1-Wire (хотя... ну да не сейчас). Исходя из схемы платы, я выбрал ногу PA6, которая выходит на колодку DIGITAL пин 28.

    PORTA &= ~_BV(PA6);
    DDRA &= ~_BV(PA6);
  
    bitmask = _BV(PA6);
    baseReg = &PINA;

• OneWire использует задержки в микросекундах для реализации протокола 1-Wire, подсунем библиотечную функцию _delay_us() в файл OneWire_Port.h

    #define delayMicroseconds(usec) _delay_us(usec)

• OneWire любит отключать прерывания во время выполнения очень маленьких задержек (несколько микросекунд), и я ее понимаю. Но сразу же оглянемся и подумаем о том, что у нас все-таки будет ось. А значит, включение прерываний разумнее проредить немного, чтобы случайно не потерять контекст выполнения на неопределенное время. Библиотека использует ардуиновские функции работы с прерываниями, подсунем ей стандартные через файл OneWire_Port.h:

    #define noInterrupts()          __builtin_avr_cli()
    #define interrupts()            __builtin_avr_sei()

• В драйвере термодатчика используется задержка, измеряемая в миллисекундах. Тут разумнее использовать вызов функции ОС, особенно учитывая размер этих задержек. Для замены sleep на вызов функции ОС пришлось немного погородить макросов в OneWire_Port.h, комментарии в коде.

    // Количество «тиков» операционной системы (переключений контекстов) в секунду
    #define __CLOCKS_PER_SEC  1000
    //Период системного таймера операционной системы
    #define PERIOD_TIMER_MS  ( 1000UL /  __CLOCKS_PER_SEC )
    // Макрос перевода миллисекунд в количество тиков операционной системы
    #define MSEC_TO_TICK( X )   ( X / PERIOD_TIMER_MS )
    #define delay(msec)             OS::sleep( MSEC_TO_TICK(msec))

Внедрение агента в банду

Теперь либы собираются, настал черед вкрутить их в код проекта. Как удостовериться, что оно заработало? Элементарно: создаем экземпляр класса OneWire, затем DallasTemperature с параметром шины, на которую подключены термодатчики, и начинаем все это активно использовать.

В проекте уже есть простенький терминал, добавляй туда команду, по которой будет производиться опрос термодатчика и вывод значения в терминал. Для удобства я добавил еще одну команду — поиск термодатчиков, по этой команде опрашивается линия, ответившие термодатчики заносятся в «кеш» библиотеки, после чего для найденных термодатчиков можно получить адреса и вывести их в терминал. Отмечу отдельно алгоритм поиска устройств на линии, очень увлекательный процесс, описан подробно в документации к iButton в разделе Network Capabilities.

Выносим в отдельный поток

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

Немного подумав, я решил, что лучше сделать целый класс — движок работы с термодатчиками, унаследовав его от класса process<>, чтобы все собрать в одну кучку: сделать имплементацию функции-потока, дать этой функции доступ к членам класса, выставить наружу основные функции работы с термодатчиками.

Однако тут я уткнулся в жадность. Мне хотелось оставить возможность опроса термодатчиков из консоли и иметь сигнализацию. Сразу же возникает необходимость разделять общие ресурсы, так как теперь два потока будут дергать один термодатчик (а точнее, шину 1-Wire). Лезь в класс OneWire и добавляй ему приватного мембера OS::TMutex _mutex;.

Здесь начинается интересное. Мьютекс мы завели, но пользоваться им внутри класса неразумно, так как библиотека работы с термодатчиком написана очень сильно интегрировано и на лету дергает функции байтовой, а не пакетной приема-передачи по 1-Wire. Для локализации массовых вызовов я создал два метода: open и close для шины 1-Wire.

void OneWire::open()
{
    _mutex.lock();
}

void OneWire::close()
{
    _mutex.unlock();
}

Затем пришлось прошерстить всю библиотеку DallasTemperature и обернуть вызовы функций работы с шиной 1-Wire в оболочку _wire->open() -> _wire->close().

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

float val;
AnalogState new_state;

if (!TemperatureEngine::temperature_get(0, &val))
{
    if (state != lost && ++ lost_cntr > 10 )
    {
        state = lost;
        TAlarmMessage msg;
        msg.state = state;
        msg.src = TAlarmMessage::AI_ALARM;
        AlarmMessageBox.push(msg);
    }
    continue;
}
lost_cntr = 0;
if (val < low_value)
    new_state = low;
else if (val > high_value)
    new_state = high;
else
    new_state = normal;

if (new_state != state)
{
    TAlarmMessage msg;
    msg.state = new_state;
    msg.src = TAlarmMessage::AI_ALARM;
    AlarmMessageBox.push(msg);
}
state = new_state;

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

Тут-то я и наступил на грабли. Я забыл про функцию инициации процесса измерения DallasTemperature::requestTemperatures. В ней стоят задержки для того, чтобы подождать, пока термодатчик производит измерение. Но я поставил _wire->close() перед этими задержками. В итоге я получил странную картину: при запросе из терминала начинали скакать показания термодатчика. А случалось вот что: поток движка термодатчиков запускал измерение, одновременно приходил я со своим запросом по терминалу, и в итоге мы оба читали какие-то неинициализированные значения.

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

Остается лишь добавить в поток обработки аварийных сообщений кейсы нового источника аварий.

template<> OS_PROCESS void TAlarmTask::exec()
{
    for(;;)
    {
        TAlarmMessage msg;
        // Тут мы уснем до получения аварийного сообщения
        AlarmMessageBox.pop(msg);
        // Получили сообщение, теперь обработаем его
        if (TAlarmMessage::DI_ALARM == msg.src)
        {
            // Обработка аварий цифрового датчика
        }else if(TAlarmMessage::AI_ALARM == msg.src)
        {
            // Здесь вставляем код обработки аварий аналогового (термо)датчика
        }
    }
}

Испытания огнем

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

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

Заключение

Вот мы и сделали еще один сложный шаг к защите содержимого твоего холодильника не только от врагов, но и от разморозки. Теперь в твоем арсенале есть термодатчик, а так как используется линия 1-Wire, то ты уже самостоятельно можешь навесить и два, и три, и более термодатчиков. Надеюсь, что материал этой статьи раскрыл для тебя новые и интересные возможности, казалось бы, игрушечного Arduino и подогрел интерес к программированию встраиваемых систем. Помни, что только написание кода даст тебе знание и умение. Тренируйся, больше практики, старайся воплощать самые свои сумасшедшие идеи, и знание придет. Пиши, пиши, пиши! Железный привет, RESET :).