Сетевой логгер и сервер на базе модуля WIZ820io

Автор: Сергей Безруков (aka Ser60)
Опубликовано 19.11.2013
Создано при помощи КотоРед.

В статье речь пойдет о разработке двух сетевых приложений на базе Ethernet модуля WIZ820io, производимого корейской фирмой WIZnet (вебсайт фирмы www.wiznet.co.kr). Модуль основан на чипе W5200, отличительной особенностью которого является аппаратная реализация целого ряда сетевых протоколов, таких как TCP, UDP, IP, ARP, и PPPoE. Это позволяет легко реализовать сетевые приложения, используя практически любой МК для управления. Отсутствие необходимости программной реализации стека сетевых протоколов (такая необходимость характерна для многих Ethernet модулей или МК, в которых аппаратно реализованы лишь MAC+PHY уровни) существенно снижает требования к управляющим МК и значительно упрощает их программы.

Помимо самого чипа W5200 с необходимой обвязкой модуль WIZ820io содержит сетевую розетку RJ-45 с двумя интегрированными светодиодами и штыревой разъем для установки на плату. Модуль доступен по цене около 22 USD, что не намного превышает общую стоимость деталей на нем, и существенно ускоряет разработку и прототипирование приложений.

Связь модуля с управляющим МК осуществляется через интерфейс SPI на тактовых частотах вплоть до 80 мгц. Интерфейс используется для настройки параметров модуля, чтения принятых данных из внутреннего буфера, загрузки данных в буфер для отправки, и посылки команд управления в модуль. Блок PHY модуля обеспечивает прием и передачу данных по сети со скоростью 10/100 Mbps. Модуль поддерживает одновременно до 8 сокетов, и оснащен независимыми буферами принимаемых и отсылаемых данных емкостью по 16 КБ каждый. Буферное пространство модуля можно весьма гибко распределить между сокетами, см. детали в ДШ на W5200.

Простоте применения модуля также способствует документ «TCP Application Note for W5200» доступный с вебсайта фирмы, а также пример использования модуля совместно с МК семейства ARM. Я расскажу о применении модуля с более простыми МК в режимах сервера и клиента. Вдохновляющим началом для меня послужила статья опубликованная в журнале Circuit Cellar [1], где модуль WIZ820io использовался совместно с МК серии MSP430. Я также решил использовать MSP430G2553, т.к. этот МК входит в популярный набор MSP-EXP430G2 LaunchPad и стал «народным» для радиолюбителей работающих с этим семейством.

В обоих рассматриваемых здесь приложениях в качестве передаваемых и принимаемых по сети данных задействованы значения, получаемые с датчиков атмосферного давления, температуры, и влажности воздуха. В качестве датчика давления используется BMP180, о котором я уже кратко рассказывал ранее [2]. Для измерения температуры и влажности воздуха я решил опробовать весьма новый датчик HTU21D, производимый фирмой Measurement Specialties.

Датчик, как нельзя более, похож на модель SHT21 фирмы Sensirion и имеет практически такие-же габариты и параметры по точности. Однако, нижняя граница рабочего напряжения датчика снижена до 1.5 В (вот это да!) и цикл измерения параметров занимает в 1.5 раза меньше времени, правда при в 1.5 раза большем токопотреблении (450 мка в активном режиме, но в сочетании со временем измерения энергетика получается примерно такой-же). Кроме того, датчик доступен по цене около 8.2 USD, что примерно в 3 раза меньше цены на SHT21. Датчики выпускаются как с защитным фильтром от пыли, так и без него. Не отвлекаясь от основной цели настоящей статьи, упомяну лишь, что после опробования многих датчиков температуры и влажности с интерфейсом I2C, этот датчик на настоящий момент находится для меня на первом месте по приоритету.

Но вернемся к нашим сетевым приложениям. Оба они собраны по одной и той-же электрической схеме и отличаются лишь программой МК. Схема питается от стабилизатора на UA78M330 (на схеме не показан) в стандартном включении и потребляет около 150 мА. Практически все токопотребление приходится на IC1. Микросхема стабилизатора напряжения снабжена небольшим теплоотводом.

Помимо модуля и микросхем в схеме присутствуют всего 3 конденсатора в цепях питания и 3 резистора. Из них R1 установлен в цепи сброса МК, а R2 и R3 – подтягивающие на шинах интерфейса I2C. Для связи МК с Ethernet чипом по SPI задействован аппаратный блок USCI_A0 микроконтроллера, а протокол I2C для общения с сенсорами реализован на основе аппаратного блока USCI_B0. МК тактируется на частоте 16 мгц от внутреннего генератора. Частота SCLK интерфейса SPI выбрана 4 мгц, а частота тактирования линии SCL интерфейса I2C около 100 кгц. Для стабильности и лучшей предсказуемости временных интервалов в программе МК следует тактировать его таймеры от встроенного кварцевого генератора LFXT1, нежели чем от VLO. Для этого схему следует дополнить часовым кварцевым кристаллом, подключаемым между выводами 18 и 19 МК. Я этого не сделал потому что из-за больших межэлектродных емкостей на монтажке кварцевый генератор с имеющимися у меня кристаллами запускался нестабильно. На печатной плате такая проблема не возникает.

Коммуникация с W5200 происходит в 2 этапа. На первом этапе производится засылка в чип адреса в буфере для операции чтения/записи (2 байта) и длины пакета чтения/записи в байтах (2 байта). При записи старший бит длины должен быть равен 1, а при чтении – 0. Это единственный признак, по которому чип определяет что ему делать. На втором этапе производится собственно чтение или запись. Важным моментом на этом этапе является читать/писать именно столько байтов, сколько было указано на первом этапе. Если это условие не соблюдено, то даже после установки пина nSS в единицу чип не прекращает предыдущую операцию и не забывает о некорректном обращении с ним, и при последующем сбросе nSS в 0 мстит, ведя себя «странно». При соответствии длин во время первого этапа принимаемый из чипа байт данных всегда должен быть равен 0, как показано на осциллограмме ниже для случая чтения данных из W5200:

Во время записи данных в W5200 принимаемый байт должен быть нулевым на протяжении всей операции записи:

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

Модуль WIZ820io в режиме клиента для логгера

В этом режиме схема производит периодическую пересылку данных полученных с датчиков на внешний сервер, где она сохраняется в текстовом файле sensors.dat. Период измерений и отсылки данных около 5 сек. Передача данных производится по методу запроса GET протокола HTTP посредством транспортного протокола TCP/IP. При этом в адресной строке передаются «сырые» данные с датчиков. Вычисление фактических значений давления, температуры, и влажности осуществлятеся на сервере прилагаемым скриптом sensors.php. Этот-же скрипт используется для дополнения логгируемых данных отметками времени (timestamp) когда эти данные получены. Эти отметки также отсылаются обратно клиенту для контроля связи. Время считывается из часов реального времени на сервере. Ниже приведен фрагмент файла sensors.dat:

Для упрощения программы я не использовал протокол DHCP для получения динамического IP адреса для W5200, а просто установил его постоянным 192.168.1.170 в моей домашней сети. С той-же целью я не использовал DNS для получения IP адреса сервера и установил его в программе таким, какой он есть в моей сети: 192.168.1.108. В качестве ПО сервера использовался Apache веб-сервер с модулем PHP5 работающий под управлением ОС openSUSE Linux. Сервер принимает HTTP запросы на стандартный порт 80, а порт для клиента W5200 в программе изменяется каждый раз при посылке нового запроса. Для работы модуля WIZ820io еще понадобится установить адрес шлюза (gateway) в Вашей сети и маску подсети. Наконец, Вам понадобится MAC адрес для W5200, например от какой-нибудь неиспользуемой сетевой карты. Для экспериментов в пределах локальной домашней сети можно временно присвоить W5200 произвольный 48-битный MAC адрес, например 0х112233445566 (маловероятно, что среди сетевых адаптеров Ваших устройств встретится такой MAC адрес). Эти установки производятся в конце исходника прилагаемого кода и засылаются в модуль WIZ820io при его инициализации. Засылке данных в модуль предшествует его аппаратный сброс путем выдачи с МК напряжения лог. 0 на вывод nRESET на 5 мкс с последующей подачей лог. 1 на этот вывод в течении 150 мс (см. ДШ).

Для отсылки данных на сервер в программе формируется заголовок (header) GET запроса следующего вида:

• GET /sb/sensors.php?temp=XXXX&humi=YYYY&temp2=TTTT&press=ZZZZ HTTP/1.1
• Host: 192.168.1.170
• Connection: close

где XXXX, YYYY, TTTT, и ZZZZ – это, соответственно, «сырые» (необработанные) значения температуры и влажности полученные от HTU21D, а также значения температуры и давления от BMP180. Для передачи по сети все эти значения программно переводятся в шестнадцатеричное представление с четырьмя шестнадцатиричными знаками. При отсылке заголовки копируются из памяти программ в RAM, дополняются фактическими данными от датчиков, и все это загружается в буфер передачи W5200. В конце каждой строки заголовков нужно обязательно посылать 2 байта со значениями 13 и 10, обозначающие конец строки, а после всех заголовков необходимо послать дополнительно 2 байта 13 и 10 (пустую строку), которая символизирует конец области заголовков для протокола HTTP. Вместо IP адреса моего сервера во второй строке заголовков следует поставить адрес Вашего сервера (или его символическое имя), т.к. иначе Apache сервер отвечает кодом 400 “Bad Request”. Также подлежит коррекции путь к скрипту sensors.php на сервере. Наконец, последняя строка заголовков говорит серверу о завершении соединения с клиентом (посылкой ему пакета с установленным флагом FIN) сразу после приема и передачи данных. По приему этого флага программа МК отвечает посылкой подтверждения серверу, согласно протоколу TCP, и закрывает сокет.

В приводимой программе используется только один сокет S0 с дефолтными установками объема буферов приема/передачи по 2 КБ каждый. После инициализации МК программа вызывает процедуру Init_W5200, которая инициализирует некоторые регистры чипа и регистры сокета S0. Инициализация производится только один раз при подаче питания на схему.

Внутри чипа W5200 сетевые протоколы реализованы в виде конечного автомата состояний сокетов. Переходы между состояниями показаны на следующей диаграмме, заимствованной из ДШ на W5200, где я оставил только состояния, имеющие отношение к нашему проекту:

Для программной реализации TCP клиента сокет, при условии успешной установки соединения с сервером и отсылки ему данных, последовательно циркулирует между состояниями CLOSED – INIT – ESTABLISHED – CLOSE_WAIT – CLOSED и далее по циклу. Я не буду вдаваться в подробности прилагаемой программы в файле client.s43, а лишь на качественном уровне опишу ее действия на случай если Вы захотите переписать приложение под другой МК. Программа состоит из бесконечного цикла, на каждой итерации которого считывается состояние сокета из регистра S0_SR и последовательно сравнивается с четырьмя упомянутыми выше состояниями.

В состоянии сокета CLOSED программа засылает новый номер порта для следующего соединения в регистр S0_PORT и открывает сокет путем засылки в W5200 команды OPEN. Если открытие произошло успешно, сокет сразу переходит в состояние INIT.

В состоянии INIT МК погружается в сон до следующего опроса датчиков. Период измерений (5 сек) и пробуждение МК обеспечиваются его таймером Timer_A0. После приема данных от датчиков программа производит запрос на соединение с сервером посредством засылки в W5200 команды CONNECT и выставляет флаг SYN_FLG в переменной flags. Установка флага нужна затем, чтобы предотвратить повторные запросы до приема ответа от сенсора. Строго говоря, посылкe серверу запроса на соединение предшествует запрос и получение MAC адреса севера по протоколу ARP. Однако, это происходит на внутреннем аппаратном уровне W5200 и прозрачно для пользователя. По установке соединения с сервером сокет переходит в состояние ESTABLISHED.

В состоянии сокета ESTABLISHED программа производит отсылку серверу GET запроса и принимает его ответ. Это реализуется загрузкой запроса в буфер передачи сокета с последующей засылкой в W5200 команды передачи SEND. Одноразовая посылка запроса серверу контролируется флагом DAT_FLG в переменной flags. Прием данных (точнее их копирование из буфера приема сокета в RAM МК) производится по появлению ненулевого значения длины принятого сообщения в регистре S0_RSR. После передачи данных клиенту сервер посылает ему пакет с установленным флагом FIN (как следствие посылки серверу заголовка “Connection: close”), по приему которого сокет автоматически переходит в состояние CLOSE_WAIT. Данные посылаемые сервером в данной тестовой программе не используются, но их чтение необходимо для освобождения буфера приема. Принятые данные можно увидеть в отладчике по адресу 0х220 в RAM МК. Число 1383236993 самом конце пакета – это отметка времени принятия сервером данных от клиента, получаемая на сервере функцией time().

В состоянии CLOSE_WAIT производится подтверждение серверу о разрыве соединения путем засылки в W5200 команды DISCON, что переводит сокет в состояние CLOSED. Установка флага DIS_FLG в переменной flags предотвращает повторные посылки подтверждения. Отмечу, что в случае неполучения клиентом подтверждения о приеме пакетов сервером в течении определенного таймаута W5200 автоматичеки производит повторную передачу пакета. Максимальное число повторных передач (в данной программе 8) и величина таймаута (400 мс) устанавливается в соответствующих регистрах W5200 при инициализации.

Для облегчения температурного режима WIZ820io и ощутимого снижения потребляемого схемой тока в промежутках между запросами желательно выключать MAC+PHY уровни W5200 путем подачи напряжения лог. 1 на пин PWDN. Перед следующем использованием модуля напряжение на этом пине следует сбросить в 0. Важно учесть, что после выключения модулю требуется довольно длительное время для выхода на рабочий режим (порядка 1 сек).

Модуль WIZ820io в режиме HTTP сервера

В этом режиме схема ожидает запросы от клиентов на HTTP порт 80 о данных температуры, влажности, и давления. В качестве клиента можно изпользовать, например, веб-браузер. По получении запроса производится измерение указанных величин и отсылка их клиенту. Вот как выглядит тестовое окно браузера при индикации полученных от сервера данных:

Для засылки GET запроса серверу в прилагаемом HTML файле get_data.html используется технология AJAX. Запрос посылается по нажатии кнопки “Get Data”. При этом вызывается JavaScript функция doGetRequest(), которая создает объект xmlHttp, объявляет его обработчик событий handleStateChange(), устанавливает соединение с сервером и, собственно, посылает запрос. По получении браузером ответа от сервера, который содержит 4 шестнадцатиричных числа («сырые» значения температуры и влажности от HTU21D и значения температуры и давления от BMP180) обработчик производит вычисление фактических значений этих величин по формулам из ДШ и их индикацию в окне браузера. Работа сервера проверена с браузерами Firefox ver. 25.0 и Internet Explorer ver. 10. Функционирование его удобно проконтролировать с помошью свободно доступной системы Wireshark (эту систему можно также использовать и для контроля работы W5200 в режиме клиента). Ниже показано как в ней выглядит последовательность фреймов в результате нажатия на кнопку “Get Data” в окне браузера: 

Для интерпретации показанных выше данных отмечу, что в моей домашней сети браузер открыт на Windows-7 лаптопе (IP адрес 192.168.1.123), имеющем беспроводное соединение с WiFi раутером, к которому WIZ820io (IP адрес такой-же как и ранее: 192.168.1.170) подключен через кабель. Как следует из данных Wireshark, работа системы происходит в полном соответствии с классикой. Сначала лаптоп получает MAC адрес W5200 по протоколу ARP, см. фреймы 1-2  (чтобы не провоцировать народ на заимствование моего MAC адреса я его стер в окне Wireshark, а также в прилагаемых програмах МК). Затем браузер инициирует соединение с W5200 и после фазы рукопожатия (фреймы 3-5) производится посылка GET запроса серверу (фрейм 6). Сервер отвечает посылкой данных сенсоров (фрейм 7), после чего производится разрыв соединения (фреймы 8-11).

Wireshark также позволяет просмотреть детали каждого фрейма. При открытии фрейма 7 можно посмотреть какие HTTP заголовки (headers) МК посылает через W5200 браузеру, а также какие данные. В данном случае данные - это 4 шестнадцатиричных числа 60F8, 636C, 62BE, 9D68, которые JavaScript программа на браузере переводит в фактические значения величин, показанных выше. Заголовок “Access-Control-Allow-Origin: *” формируется программой МК и необходим браузерам для функционирования технологии AJAX между разными хостами (hosts) и доменами (domain).

Прилагаемая программа МК для режима сервера в файле server.s43 во многом похожа на программу для режима клиента. Однако, сокет сервера циркулирует между состояниями CLOSED – INIT – LISTEN – ESTABLISHED – CLOSED. В состоянии CLOSED, аналогично программе клиента, производится открытие сокета командой OPEN, в результате чего он переходит в состояние INIT.

В состоянии INIT вместо команды CONNECT, как это сделано в программе клиента, в W5200 засылается команда LISTEN, что настраивает сокет на ожидание запроса от клиентов. Другим отличием является использование прерываний от W5200. Именно, при инициализации чипа в его регистре IRM2 разрешаются прерывания от сокета S0, а в регистре S0_IMR разрешаются прерывания по получению сокетом запроса на соединение от клиента. При этом МК (но не W5200) помещается в режим сна LPM3, из которого он выводится падающим уровнем напряжения на пине nINT модуля WIZ820io по установке соединения. После пробуждения МК производит чтение данных из сенсоров, а сокет тем временем переходит в состояние ESTABLISHED.

В состоянии ESTABLISHED соединение с клиентом уже установлено и сокет ожидает получение данных запроса клиента. По получении данных производится их копирование из буфера W5200 в RAM МК. Отметка времени (timestamp) в запросе предотвращает кэширование в браузере. Сами данные присланные клиентом в запросе данной программой не используется, но их чтение необходимо для освобождения места в буфера ввода W5200 для приема других запросов. После прочтения запроса программа формирует ответ клиенту (4 упомянутых выше шестнадцатиричных числа с разделительными пробелами между ними) в RAM и по окончании копирования ответа в буфер вывода W5200, в чип посылается команда SEND и после отсылки пакета DISCONNECT. В результате клиент получает данные от сенсоров с последующим запросом на разрыв соединения (фреймы 7-8 в окне Wireshark). После разрыва соединения с клиентом сокет возвращается в режим CLOSED, программа стирает флаги прерывания в регистре S0_IR и весь цикл повторяется.

В заключении отмечу, что в прилагаемом скрипте sensors.php и файле get_data.html для вычисления атмосферного давления изпользуются калибровочные коэффициенты моего экземпляра датчика BMP180, которые наверняка будут отличными от Вашего. Коэффциенты можно получить из датчика по интерфейсу I2C, см. детали в его ДШ.

Литература 

1. Tom Cantrell: Weatherize Your Embedded App, Circuit Cellar 4 (2013), 36 – 43.
2. Сергей Безруков:  Метеостанция... без микроконтроллера

Файлы:
Software + Firmware

Все вопросы в Форум.