Одно предварительное замечание

SPL
Приемопередатчик HC-12
Сначала речь пойдет об организации беспроводной связи между двумя девайсами. Тема, можно сказать, топовая для наших дней, но при ближайшем рассмотрении приемлемое решение оказывается найти довольно сложно. Естественно, в простых устройствах целесообразно применение самых дешевых и компактных решений. Но дешевизна далеко не синоним простоты — малая цена и доступность описанного мной год назад RF-комплекта из приемника и передатчика ISM-диапазона 433 МГц вполне компенсируются сложностью библиотечного кода. Еще более усложнять задачу, переписывая его на ассемблере, просто глупо. И, кстати, за это время я выяснил, что качество модулей в продаже почему-то резко упало: даже из проверенных источников получить RF-комплект, не желающий работать в паре — совсем не исключение. Для проверки заказал десяток комплектов по дешевке у вроде бы солидного продавца на Ali, посмотрим на качество, когда доберутся.
Для ассемблерного подхода здесь бы идеально подошел какой-нибудь из приемопередатчиков, работающих через стандартные порты обмена (обычно это UART, иногда SPI). К сожалению, почти все они довольно дороги — в книге я ориентировал читателей на MBee-868, но самый дешевый из них находится поиском за цену порядка 1200 рублей, а для радиообмена ведь нужна их пара (и не ищите их на Ali — говорят, это чисто отечественная разработка). За такой порядок цен можно уже построить целую метеостанцию даже по ценам «Чипа-Дипа».
Остальные решения, такие, как LoRa, в основном еще дороже (если не рассматривать сомнительные и плохо документированные предложения с Ali). Потому я остановился на HC-12 на 433 МГц — пару таких модулей можно купить в более-менее надежном интернет-магазине рублей за 800 (или раза в полтора-два дешевле прямо на Ali). Смоделировав прием и передачу на Arduino, я убедился, что отзывы на форумах не врут: из коробки, без всяких настроек, модули работают просто отлично.

Обмен по умолчанию идет на скорости 9600. В качестве антенны использовался просто отрезок изолированной проволоки диаметром 0,5 мм и длиной 17 см (к модулям прилагается и спиральная антеннка, но, опять же по отзывам, она работает хуже). На дальность не проверял, но в пределах квартиры, включая передачу на лоджию через капитальную кирпичную стену под косым углом, никаких проблем не возникло.
Приятная особенность всех применяемых решений — отсутствие аналоговых компонентов, что позволяет не очень заботиться о качестве питания (напомню, что существенным фактором при работе RF-приемника является необходимость отдельного от цифровой части аналогового стабилизатора).
Энергосбережение при передаче
Все хорошо, и меня устраивает — процедуры обмена простейшие и в полпинка переводятся на ассемблер. Есть только одно довольно большое «НО»: потребление. Модуль в умолчательном режиме на холостом ходу потребляет 15 мА, которые возрастают до 100 и более мА в момент передачи. Исследования с помощью осциллографа показали, что передача длится дольше, чем это должно быть при формально выставленной скорости 9600. При такой скорости байт передается примерно за миллисекунду, измерения же показали, что при передаче четырехбайтового числа потребление возрастает до 100 мА примерно на 15 мс. С этим может справиться обычный 100-миллиамперный стабилизатор (LM2931, LP2950 и пр.) с хорошим танталовым конденсатором на выходе, но для батарейного питания все это совершенно не годится.
Конечно, я сначала рассчитывал на штатные способы энергосбережения, из которых выбрал периодическое погружение в сон и пробуждение с помощью AT-команд. Но первое же испытание управления HC-12 с помощью AT-команд (попытка получения стандартного отклика «AT»-«OK») показала полный облом. Вход в режим управления (заземлением вывода S) занимает длительное время — официально не менее 40 мс, в реальности может и все 200, отклик приходит через раз и может ожидаться вообще неопределенно долго. Плюс штатный выход из режима управления — формально не менее 80 мс, и черт его знает, сработало там все или зависло.
Почитав стенания по этому поводу на различных форумах, я решил, что такой хоккей нам не нужен! Пусть разбираются въедливые перфекционисты, а мы поступим проще: раз в умолчательном режиме модуль нормально работает, просто будем отключать питание, а при необходимости передачи — включать. Экспериментально удалось установить, что после включения модулю достаточно 30-35 мс на успокоение, для гарантии будем выжидать 50 мс. Включать питание модуля будем маломощным MOSFET-ключом (транзистор BS-170), замыканием на общий провод. Не забудем выждать до выключения необходимое время для гарантированного окончания передачи. Эксперименты показали, что при снижении паузы до выключения модуля ниже 20-30 мс процесс обмена нарушается, потому будем с запасом выжидать также 50 мс. Это проще в осуществлении, чем подача AT-команд, страхует от странностей работы модуля и занимает не больше времени, чем управлением штатным способом в идеальном случае. Причем в перерывах модуль совсем ничего потреблять не будет и не надо экспериментировать с выбором из различных предлагаемых режимов.
Моделирование передачи-приема на Arduino
Скетч, моделирующий простую передачу двухбайтового числа (HC-12_proba_peredatchik) вы найдете в архиве по ссылке в конце статьи. Раз в 4 секунды передается число 273. Соответственно, в простейшем скетче для проверки приема (HC-12_proba_priemnik) при приеме этого числа светодиод по выводу 13 меняет состояние на противоположное. В текстовых скетчах намеренно использован не слишком удобный способ побайтной передачи двухбайтового числа и формированием его заново на приемном конце, примерно так (value — двухбайтовая переменная типа word или uint_16):

Возможности класса Serial позволяют и передачу и прием сделать более компактным способом, но в дальнейшем мы будем переводить это на ассемблер, где никаких классов Serial не имеется, потому сразу делаем программы передачи и приема совместимыми с ассемблерным вариантами.
И для приемника и для передатчика можно использовать любой Ardiuno на основе ATmega328 (Uno, Nano, Mini или их аналоги, в том числе и с 3-вольтовым питанием). Схемы подключения и передатчика и приемника в тестовом варианте тривиальны: подключить оба вывода питания GND и Vcc модуля к питанию Arduino GND и +5V, и перекрестно соединить выводы RxD и TxD. В скетчах для связи через модули HC-12 использован программный UART: вывод 8 (RxD) и 9 (TxD) Arduino в передатчике, 2 (RxD) и 3 (TxD) в приемнике (см. исходный текст скетчей). Можно, конечно, использовать и штатный UART, но тогда необходимо каждый раз перед подключением USB отключать модуль и при проверке запитывать контроллер от автономного адаптера. Забывчивость мне уже стоила одного необратимо сожженного Uno и одного контроллера, лишившегося загрузчика, потому рисковать не советую (что интересно, в случае Xbee-модулей, которые также подключаются к UART, никаких таких катастроф не наблюдалось — просто Arduino IDE при подключении Xbee переставала получать отклик от порта). В ассемблерном варианте, который мы будем обсуждать далее, подключенный к порту UART адаптер, разумеется, не имеет значения, так как программирование через него не ведется. И мы там будем всегда использовать штатный порт, а на приемной стороне выводить полученные данные на дисплей.
Теперь соберем схему для испытаний модуля HC-12 на отключение и включение с помощью транзисторного ключа, согласно описанному ранее:

В соответствующем скетче (HC-12_proba_power_peredatchik) контроллер каждые 4 секунды отсылает в эфир возрастающее число. В перерывах питание модуля отключается. Управление включением и отключением питания модуля через ключ, соединяющий с модуль с «землей», осуществляется через вывод D5 Arduino (совпадает с выводом 5 порта D). Именно на такой схеме проводились измерения потребления модуля и проверялись необходимые величины задержек на установление питания.
Теперь отвлечемся от потребления и смоделируем расширенную передачу данных с выводом на дисплей. Усложненный скетч передатчика HC-12_peredatchik_array также имеется в архиве по ссылке в конце статьи. Контроллер передает в эфир целый массив, начинающийся с идентификатора передатчика (в данном случае трех символов «DAT»), после следуют два байта числа и затем символ «;» качестве конца данных. Опять же оформить подобную передачу можно средствами высокоуровневого языка более красиво и компактно, но мы остановимся на побайтной передаче массива, так как именно такой способ будем использовать в ассемблерном варианте. Текст скетча HC-12_peredatchik_array невелик и я привожу его здесь полностью:

Может показаться, что накладные расходы такого способа слишком велики — четыре служебных байта на два байта передаваемого числа. Но во-первых, это тестовый макет (в реальности мы можем передавать сколько угодно чисел любой разрядности), во-вторых, таким способом мы можем повесить на один приемник любое количество датчиков, меняя их идентификатор (к примеру «DA1», «DA2» и так далее). А оконечный символ «;» служит здесь для проверки того факта, что массив передан и принят полностью (в Arduino без этого символа вполне можно обойтись, а в ассемблерном варианте он нам пригодится, чтобы не связываться со всякими таймаутами).
Для проверки можно просто принимать массив побайтно через программный порт, и потом отправлять принятое через обычный Serial на монитор порта для проверки. Для такого способа можно использовать слегка модифицированный скетч простейшего приемника (HC-12_proba_priemnik). Подробнее я останавливаться на этом не буду, так как мы тут сразу попробуем смоделировать отвязанный от USB приемник с дисплеем.
Приставим к Arduino обычный ЖК или OLED-дисплей 16х02, так как уже знаем (см. предыдущую статью), что потом перенести это в ассемблерный проект будет совсем несложно. Схема подключения дисплея и модуля HC-12 к Arduino показана на рисунке:

Соответствующий скетч носит название HC-12_priemnik_OLED16x02_Arduino, и также может быть найден в архиве по ссылке в конце статьи. Пятисекундная задержка в начале (в функции setup()) с тестовым выводом на дисплей необходима для проверки правильности подключения и инициализации дисплея. После этого программа начинает отслеживать прием массива через программный UART (штатный Serial при этом используется для отладки). Прием устроен довольно нестандартным способом:

После того, как мы убедились, что пришел первый байт передаваемого массива (Serialpr.available()>0), производится отслеживание по условию while (Serialpr.available()). Выход из этого цикла происходит автоматически по истечению таймаута на прием. По умолчанию в Arduino Serial.timeout равен 1 мс, что примерно равно времени передачи байта со скоростью 9600. Поэтому через пару-тройку принятых байт мы из цикла вылетаем, не закончив прием массива. Чтобы этого избежать, после приема очередного байта ставится небольшой delay, тогда выход из цикла будет только после приема последнего байта массива. Задержка необязательна, если раскомментировать отладочные строки посылки через обычный Serial – время их выполнения как раз обеспечит необходимую задержку. Повторю, что средствами Arduino можно обеспечить куда более компактный прием (применив всякие там readString и parseInt), но мы моделируем будущий ассемблерный вариант. Вы увидите, что там проблема приема целостного массива будет решаться другим способом, где как раз посылка разделителя «;» будет играть решающую роль.
Убедившись, что массив принят полностью (последний принятый байт содержит символ двоеточия «;»), а первые три байта полученного массива содержат необходимый идентификатор (строка «DAT»), мы, как и ранее, формируем двухбайтовое число из отдельных байт и посылаем результат на дисплей.
Передача и прием на ассемблере

Испытание ассемблерной версии передатчика проводилось по схеме, показанной на рисунке выше (сразу с возможностью отключения питания модуля HC-12). Контроллер ATtiny2313 может быть заменен в данном случае на почти любой другой AVR (о том, что именно надо менять в исходном коде при такой замене — см. упомянутую книгу). Кварц (в данном случае на 4 МГц) — обязательная для этого случая деталь, при работе от встроенного генератора UART на скорости 9600 будет сбоить. Потребление в сравнении с ардуиновскими 16 МГц падает примерно вдвое, а кварц шустрее 4 МГц нужен лишь в отдельных задачах, связанных с измерением времени.
Управление ключом питания модуля HC-12 производится через вывод 5 порта D (вывод 9 микросхемы). Стандартный для Arduino вывод сигнального светодиода D13 (это вывод 19 ATmega328) здесь заменен на вывод 6 порта D (выв. 11 ATtiny2313, крайний в корпусе). Заметьте, что на схеме указан стандартный светодиод, который при резисторе 620 Ом будет потреблять около 5 мА. Если хотите немного сэкономить дополнительно, поставьте суперяркий (1000 мкд и более) и к нему резистор порядка 20-33 кОм, в зависимости от яркости свечения выбранного типа.
Предварительно необходимо установить fuse-биты. Да-да, а что вы думали? Это в Arduino вам их менять не только нельзя, но и невозможно. А все контроллеры выпускаются с фабрики с установками на работу от встроенного генератора (причем с конкретной частотой 1 МГц, за редким исключением). Потому их нужно поменять, как минимум, на работу от внешнего кварца. Для облегчения программирования чипа 2313 привожу наглядную картинку настроек фьюзов для данного случая. Как там и написано, нажатая кнопка соответствует нулевому (programmed) значению фьюза:

Систему BOD мы здесь держим выключенной (все биты BODELEVEL в единичном состоянии), потому что это 20-30 мкА дополнительного потребления. При выключенной системе отслеживания питания контроллер при истощении батарейки может совершать непредсказуемые операции, но в общем случае это опасно только для содержимого EEPROM. В данной схеме долговременная память не употребляется и BOD можно выключить.
Соответствующая тестовая ассемблерная программа передатчика сразу с использованием энергосбережения (H-12_peredatchik.asm) приведена полностью далее:

В главном цикле программы, как видите, совершается единственное действие — уход в энергосберегающее состояние. Все действия здесь реализованы в обработчике прерывания сторожевого таймера (WDT), настроенного на выход из сна каждые 4 секунды (максимальное значение 8 секунд). После выхода из сна через МОП-ключ BS-170 подключается передачик, дается пауза 50 мс для того, чтобы модуль «пришел в себя», и затем производится передача. Измерения показали, что в паузах вся схема потребляет не более 150 мкА. Активный период длится около 0,1 с, в это время потребление в среднем составляет около 50 мА. Напомним, что в ассемблерной программе подключение программатора ни на что не влияет, потому при отладке передатчика его можно не отключать (но не забывайте, что программатор питается от схемы и при измерении потребления отключать его все-таки необходимо!). Напомним, что в качестве светодиода Led1 можно поставить суперяркий с токоограничивающим резистором R2 величиной 20-30 кОм. Текст программы и скомпилированный hex-файл вы найдете в том же архиве в конце статьи.
Следует учесть, что WDT в контроллере ATtiny2313 расширенного типа, аналогичного встроенному в Arduino-контроллеры ATmega328. Сторожевой таймер в старых контроллерах, вроде ATmega8/16, не поддерживает режим выхода из сна в прерывание, только полный перезапуск. Это критично для программ, хранящих промежуточные результаты в памяти или регистрах, но в данном случае приведет лишь к необходимости в минимальной коррекции процедур инициализации сторожевого таймера и переноса всей функциональности в главный цикл (подробности см. книгу). Кроме того, старый WDT не поддерживает длинные выдержки в состоянии сна (более 2 с). Это следует помнить и проверять тип встроенного WDT, если вы захотите перенести программу на другой контроллер (кстати, популярный у ардуинщиков ATtiny13 также имеет расширенный WDT, но в нем отсутствует полноценный аппаратный UART, потому для наших целей его придется приспосабливать дополнительно).
Расширенную программу передатчика с посылкой массива, аналогично тому, как мы это делали на Arduino, вы также можете найти в архиве (H-12_peredatchik_2313_WDT.asm). Она отличается от приведенной выше только содержимым обработчика прерывания WDT:

Программа каждые 4 секунды передает в эфир такой же массив, предваряемый идентификатором датчика, как и Arduino-скетч выше, потому, чтобы убедиться, что передатчик работает верно, проверить прием можно тем же скетчем приемника с дисплеем (HC-12_priemnik_OLED16x02_Arduino). Обратите внимание, что передаваемое число здесь 2-байтовое, но ограничено 3 десятичными знаками (0-999). Так в дальнейшем (при выводе на дисплей) удастся сократить процедуру BCD-преобразования — в задаче дистанционного термометра далее передаваемые величины температуры не будут выходить из этого диапазона.
Приемник на ассемблере
Для дальнейших действий нам потребуется приемник с дисплеем на основе ассемблера, потому давайте составим макет подобного устройства. За основу возьмем ATmega8, тогда схема может быть, например, такой:

Установка fuse-бит для Mega8 показана на рисунке (здесь питание от сетевого адаптера, экономия не требуется, потому систему BOD можно не отключать):

Программа, соответствующая этому рисунку (HC-12_priemnik_OLED16x02_proba.asm), получается довольно громоздкой, потому полностью здесь не приводится, и вы ее сможете посмотреть в архиве по адресу в конце статьи. Здесь мы остановимся на ключевых моментах. В начале программы, после всех необходимых установок, дисплей для проверки верности подключения и для образца заполняется тестовыми символами точно так же, как это делалось в программе OLED1602_proba.asm из предыдущей статьи. Затем программа переходит к замкнутому циклу, в котором принимает последовательно все элементы нашего массива, с проверкой трех символов идентификатора в начале и концевого символа «;» в конце:

Если эти служебные символы не совпадают с ожидаемыми, то происходит возврат в начало цикла ожидания. Если все совпало, то выполняем конвертацию полученного hex-числа в три отдельных десятичных цифры и выводим их дисплей в виде символов, для чего достаточно к каждой цифре прибавить число 0x30 = 48, соответствующее позиции нуля в таблице ASCII (во избежание недоумений: чтобы прибавить к регистру общего назначения константу, в AVR-ассемблере применяется команда вычитания отрицательного числа, команда сложения с константой имеется только для 16-битовых чисел).