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

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

<?php class SimpleImage { var $image; var $image_type; function load($filename) { $image_info = getimagesize($filename); $this->image_type = $image_info[2]; if( $this->image_type == IMAGETYPE_JPEG ) { $this->image = imagecreatefromjpeg($filename); } elseif( $this->image_type == IMAGETYPE_GIF ) { $this->image = imagecreatefromgif($filename); } elseif( $this->image_type == IMAGETYPE_PNG ) { $this->image = imagecreatefrompng($filename); } } function save($filename, $image_type=IMAGETYPE_JPEG, $compression=75, $permissions=null) { if( $image_type == IMAGETYPE_JPEG ) { imagejpeg($this->image,$filename,$compression); } elseif( $image_type == IMAGETYPE_GIF ) { imagegif($this->image,$filename); } elseif( $image_type == IMAGETYPE_PNG ) { imagepng($this->image,$filename); } if( $permissions != null) { chmod($filename,$permissions); } } function output($image_type=IMAGETYPE_JPEG) { if( $image_type == IMAGETYPE_JPEG ) { imagejpeg($this->image); } elseif( $image_type == IMAGETYPE_GIF ) { imagegif($this->image); } elseif( $image_type == IMAGETYPE_PNG ) { imagepng($this->image); } } function getWidth() { return imagesx($this->image); } function getHeight() { return imagesy($this->image); } function resizeToHeight($height) { $ratio = $height / $this->getHeight(); $width = $this->getWidth() * $ratio; $this->resize($width,$height); } function resizeToWidth($width) { $ratio = $width / $this->getWidth(); $height = $this->getheight() * $ratio; $this->resize($width,$height); } function scale($scale) { $width = $this->getWidth() * $scale/100; $height = $this->getheight() * $scale/100; $this->resize($width,$height); } function resize($width,$height) { $new_image = imagecreatetruecolor($width, $height); imagecopyresampled($new_image, $this->image, 0, 0, 0, 0, $width, $height, $this->getWidth(), $this->getHeight()); $this->image = $new_image; } } ?>

Скачать клаcc SimpleImage

Теперь после того как мы поместили данный файл класса SimpleImage к себе на сервер посмотрим как его можно использовать.

Следующий участок кода загрузит изображение image.jpg, изменить его ширину до 400 пикселей и высоту до 200 пикселей, а затем сохранит как image1.jpg.

<?php include('classSimpleImage.php'); $image = new SimpleImage(); $image->load('image.jpg'); $image->resize(400, 200); $image->save('image1.jpg'); ?>

Если необходимо изменить размеры изображения, основываясь только на ширине и при этом сохранить его пропорции, то сценарий сам выберет необходимую высоту. Для этого необходимо использовать метод resizeToWidth.

<?php include('classSimpleImage.php'); $image = new SimpleImage(); $image->load('image.jpg'); $image->resizeToWidth(250); $image->save('image1.jpg'); ?>

Возможно вы пожелаете изменить размер в процентном соотношении от его оригинала. Для этого существует метод scale, в качестве параметра которому передаются проценты.

<?php include('classSimpleImage.php'); $image = new SimpleImage(); $image->load('image.jpg'); $image->scale(50); $image->save('image1.jpg'); ?>

У данного класса есть еще один очень полезный метод output, который позволяет выводить изображения прямо в браузер, без предварительного сохранения. Данный метод может быть очень полезен при создании миниатюр.

<?php header('Content-Type: image/jpeg'); include('classSimpleImage.php'); $image = new SimpleImage(); $image->load('image.jpg'); $image->resizeToWidth(150); $image->output(); ?>

Автор данного класса Simon Jarvis, на своем сайте предлагает следующий пример для изменения размера изображения загруженного через форму.

<?php if (isset($_POST['submit']) ) { include('classSimpleImage.php'); $image = new SimpleImage(); $image->load($_FILES['uploaded_image']['tmp_name']); $image->resizeToWidth(150); $image->output(); } else { $form = '<form action="upload.php" method="post" enctype="multipart/form-data"> <input type="file" name="uploaded_image" /> <input type="submit" name="submit" value="Upload" /> </form>'; echo $form; }

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

Этим опусом я начну и постараюсь довести до читателя полную структуру программы изменяющую гироскутер в любое иное изделие для нужд потребителя и вашей инженерной мысли.
Прежде всего хочу выразить благодарность за разработку а главное за выкладывание полной рабочей версии программы ссылка
если вы знаете английский напишите ему мое спасибо буду очень вам признателен
ссылка

Что может программа:
1. Управление от RC передатчика ppm-sum в этом случае работают два колеса не зависимо друг от друга (вперед, назад, вправо и в лево).


приемник подключается на прямую к контроллеру гироскутера.

2. Управление от джойстика необходим джойстик от видеоигры плейстейшен. (вперед,назад, вправо и в лево).

3. Управление переменным сопротивлением, вперед, назад и переключение скоростей информация предоставлена Viktor_7
ссылка

Подходит для самокатов и машинок можно ставить ограничение по скорости максимальная скорость 25 км час.

4. То что использую Я это управление arduino по протоколу uart.

5. Танковое управление от двух джойстиков организуется только при помощи двух контроллеров.

Выбирайте на ваше усмотрение.
Дальше больше

Сам контроллер гироскутера

Так как программа написана на языке С++ ее надо скомпилировать для так сказать волшебного превращения в прошивку для контроллера гироскутера.

рассмотрим настройку программы под свои проекты.
это файл в программе где вы делаете свои установки config.h

#pragma once
#include «stm32f1xx_hal.h»

// ############################### Менять данные запрещено 100% выход из строя контроллера ну или его не работа

#define PWM_FREQ 16000 // PWM частота 16 кГц
#define DEAD_TIME 32 // PWM deadtime

#define DELAY_IN_MAIN_LOOP 5 // in ms. default 5. it is independent of all the timing critical stuff. do not touch if you do not know what you are doing.

#define TIMEOUT 5 // number of wrong / missing input commands before emergency off

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

// ############################### GENERAL ###############################

// How to calibrate: connect GND and RX of a 3.3v uart-usb adapter to the right sensor board cable (be careful not to use the red wire of the cable. 15v will destroye verything.). if you are using nunchuck, disable it temporarily. enable DEBUG_SERIAL_USART3 and DEBUG_SERIAL_ASCII use asearial terminal.

// Battery voltage calibration: connect power source. see <How to calibrate>. write value nr 5 to BAT_CALIB_ADC. make and flash firmware. then you can verify voltage on value 6 (devide it by 100.0 to get calibrated voltage).
#define BAT_CALIB_REAL_VOLTAGE 43.0 // установить напряжение измеренное тестером на вашем аккумуляторе (в данный момент используется 43 вольта)

#define BAT_CALIB_ADC 1704 // BAT_CALIB_ADC -это калибровочный коэффициент для расчёта напряжения, т.е. число 1704 — это количество
отсчётов, при подаче на вход делителя напряжения НАПРЯЖЕНИЯ = 43.0

#define BAT_NUMBER_OF_CELLS 10 // количество ячеек в аккумуляторе: 10s
#define BAT_LOW_LVL1_ENABLE 0 // вкл/выкл звука при низком напряжении, 1 or 0
#define BAT_LOW_LVL1 3.6 // пищит на этом уровне напряжения. [В/эл.]
#define BAT_LOW_LVL2_ENABLE 1 // to beep or not to beep, 1 or 0
#define BAT_LOW_LVL2 3.5 // your battery is almost empty. Charge now! [V/cell]
#define BAT_LOW_DEAD 3.37 // undervoltage poweroff. (while not driving) [V/cell]

#define DC_CUR_LIMIT 15 // DC current limit in amps per motor. so 15 means it will draw 30A out of your battery. it does not disable motors, it is a soft current limit.

// Board overheat detection: the sensor is inside the STM/GD chip. it is very inaccurate without calibration (up to 45В°C). so only enable this funcion after calibration! let your board cool down. see <How to calibrate>. get the real temp of the chip by thermo cam or another temp-sensor taped on top of the chip and write it to TEMP_CAL_LOW_DEG_C. write debug value 8 to TEMP_CAL_LOW_ADC. drive around to warm up the board. it should be at least 20В°C warmer. repeat it for the HIGH-values. enable warning and/or poweroff and make and flash firmware.
#define TEMP_CAL_LOW_ADC 1655 // temperature 1: ADC value
#define TEMP_CAL_LOW_DEG_C 35.8 // temperature 1: measured temperature [В°C]
#define TEMP_CAL_HIGH_ADC 1588 // temperature 2: ADC value
#define TEMP_CAL_HIGH_DEG_C 48.9 // temperature 2: measured temperature [В°C]
#define TEMP_WARNING_ENABLE 0 // to beep or not to beep, 1 or 0, DO NOT ACTIVITE WITHOUT CALIBRATION!
#define TEMP_WARNING 60 // annoying fast beeps [В°C]
#define TEMP_POWEROFF_ENABLE 0 // to poweroff or not to poweroff, 1 or 0, DO NOT ACTIVITE WITHOUT CALIBRATION!
#define TEMP_POWEROFF 65 // overheat poweroff. (while not driving) [В°C]

#define INACTIVITY_TIMEOUT 8 // установка времени отключения если вы не используете включено устройство

// ############################### LCD DEBUG ###############################

Здесь вы включаете или выключаете работу дисплея ( дисплей 128х64 i2c ssd1306 или 1602 i2c
выводит напряжение и обороты каждого колеса.

//#define DEBUG_I2C_LCD // standard 16×2 or larger text-lcd via i2c-converter on right sensor board cable

// ############################### UART протокол ###############################

#define DEBUG_SERIAL_USART3 // PB10,PB11 disable if I2C (nunchuck or lcd) is used!
#define DEBUG_BAUD 115200 // UART
//#define DEBUG_SERIAL_SERVOTERM
#define DEBUG_SERIAL_ASCII // «1:345 2:1337 3:0 4:0 5:0 6:0 7:0 8:0\r\n» сам протокол

// ############################### INPUT ###############################

// ###### CONTROL VIA UART (serial) ######
//#define CONTROL_SERIAL_USART2 // left sensor board cable, disable if ADC or PPM is used!

скорость передачи общения между контроллером и Ардуино
#define CONTROL_BAUD 19200 // control via usart from eg an Arduino or raspberry

эту строчку надо вписать в ваш скетч для управления ардуино.
// for Arduino, use void loop(void){ Serial.write((uint8_t *) &steer, sizeof(steer)); Serial.write((uint8_t *) &speed, sizeof(speed));delay(20); }

// ###### использование PPM-SUMM######
// left sensor board cable. Channel 1: steering, Channel 2: speed.
//#define CONTROL_PPM // use PPM-Sum as input. disable DEBUG_SERIAL_USART2!
//#define PPM_NUM_CHANNELS 6 // количество каналов

// ###### CONTROL VIA TWO POTENTIOMETERS ######
// ADC-calibration to cover the full poti-range: connect potis to left sensor board cable (0 to 3.3V) (do NOT use the red 15V wire in the cable!). see <How to calibrate>. turn the potis to minimum position, write value 1 to ADC1_MIN and value 2 to ADC2_MIN. turn to maximum position and repeat it for ADC?_MAX. make, flash and test it.
#define CONTROL_ADC // use ADC as input. disable DEBUG_SERIAL_USART2!
#define ADC1_MIN 0 // min ADC1-value while poti at minimum-position (0 — 4095)
#define ADC1_MAX 4095 // max ADC1-value while poti at maximum-position (0 — 4095)
#define ADC2_MIN 0 // min ADC2-value while poti at minimum-position (0 — 4095)
#define ADC2_MAX 4095 // max ADC2-value while poti at maximum-position (0 — 4095)

// ###### CONTROL VIA NINTENDO NUNCHUCK ######
// left sensor board cable. keep cable short, use shielded cable, use ferrits, stabalize voltage in nunchuck, use the right one of the 2 types of nunchucks, add i2c pullups. use original nunchuck. most clones does not work very well.
//#define CONTROL_NUNCHUCK // use nunchuck as input. disable DEBUG_SERIAL_USART3!

// ############################### DRIVING BEHAVIOR ###############################

// inputs:
// — cmd1 and cmd2: analog normalized input values. -1000 to 1000
// — button1 and button2: digital input values. 0 or 1
// — adc_buffer.l_tx2 and adc_buffer.l_rx2: unfiltered ADC values (you do not need them). 0 to 4095
// outputs:
// — speedR and speedL: normal driving -1000 to 1000
// — weakr and weakl: field weakening for extra boost at high speed (speedR > 700 and speedL > 700). 0 to ~400

#define FILTER 0.1 // lower value == softer filter. do not use values <0.01, you will get float precision issues.
#define SPEED_COEFFICIENT 0.5 // higher value == stronger. 0.0 to ~2.0?
#define STEER_COEFFICIENT 0.5 // higher value == stronger. if you do not want any steering, set it to 0.0; 0.0 to 1.0
#define INVERT_R_DIRECTION
#define INVERT_L_DIRECTION
#define BEEPS_BACKWARD 1 // 0 or 1

//Turbo boost at high speeds while button1 is pressed:
//#define ADDITIONAL_CODE \
if (button1 && speedR > 700) { /* field weakening at high speeds */ \
weakl = cmd1 — 700; /* weak should never exceed 400 or 450 MAX!! */ \
weakr = cmd1 — 700; } \
else { \
weakl = 0; \
weakr = 0; }

// ###### МАЛЕНЬКАЯ МАШИНКА ######
// for better bobbycar code see: ссылка
// #define FILTER 0.1
// #define SPEED_COEFFICIENT -1
// #define STEER_COEFFICIENT 0

// #define ADDITIONAL_CODE \
if (button1 && speedR < 300) { /* drive backwards */ \
speedR = speedR * -0.2f; \
speedL = speedL * -0.2f; } \
else { \
direction = 1; } \
if (button1 && speedR > 700) { /* field weakening at high speeds */ \
weakl = speedR — 600; /* weak should never exceed 400 or 450 MAX!! */ \
weakr = speedR — 600; } \
else { \
weakl = 0; \
weakr = 0; }

// ###### КРЕСЛО ######
// #define FILTER 0.05
// #define SPEED_COEFFICIENT 0.5
// #define STEER_COEFFICIENT -0.2

// #define ADDITIONAL_CODE if (button1 && scale > 0. { /* field weakening at high speeds */ \
weakl = speedL — 600; /* weak should never exceed 400 or 450 MAX!! */ \
weakr = speedR — 600; } \
else {\
weakl = 0;\
weakr = 0;

// ############################### VALIDATE SETTINGS ###############################

#if defined CONTROL_SERIAL_USART2 && defined CONTROL_ADC
#error CONTROL_ADC and CONTROL_SERIAL_USART2 not allowed. it is on the same cable.
#endif

#if defined CONTROL_SERIAL_USART2 && defined CONTROL_PPM
#error CONTROL_PPM and CONTROL_SERIAL_USART2 not allowed. it is on the same cable.
#endif

#if defined DEBUG_SERIAL_USART3 && defined CONTROL_NUNCHUCK
#error CONTROL_NUNCHUCK and DEBUG_SERIAL_USART3 not allowed. it is on the same cable.
#endif

#if defined DEBUG_SERIAL_USART3 && defined DEBUG_I2C_LCD
#error DEBUG_I2C_LCD and DEBUG_SERIAL_USART3 not allowed. it is on the same cable.
#endif

#if defined CONTROL_PPM && defined CONTROL_ADC && defined CONTROL_NUNCHUCK || defined CONTROL_PPM && defined CONTROL_ADC || defined CONTROL_ADC && defined CONTROL_NUNCHUCK || defined CONTROL_PPM && defined CONTROL_NUNCHUCK
#error only 1 input method allowed. use CONTROL_PPM or CONTROL_ADC or CONTROL_NUNCHUCK.
#endif

есть еще один файл установки main но он для продвинутых пользователей его я разберу позже.

забегу немного в перед эта прошивка ссылка работает с RPiZeroW платформа для робота.

Пишите, спрашивайте что знаю то отвечу.

1ow004c.jpeg (290.12 кБ, 2000×1230 — просмотрено 21565 раз.)

Разбираемся с датчиками CO и метана MQ-4 и MQ-7

В бытность появления у меня набора Arduino, в поисках объекта для автоматизации, я как-то сам собой задумался над тем, что неплохо бы получать информацию о том, не является ли опасным уровень CO (угарный газ) в зимнее время в котельной загородного дома. В холодные зимние деньки и особенно ночи, газовое оборудование работает в интенсивном режиме и жжет природный газ для поддержания теплоты в доме. А вдруг у меня плохая вентиляция? Или в трубе застрял валенок? И каждый раз входя в котельную и находясь там некоторое время, я подвергаю свою драгоценную жизнь опасности. Да и от утечек природного газа тоже никто не застрахован. Тут вообще можно полдома взорвать, просто включив свет. Их хорошо бы тоже контролировать и как-то отслеживать.

Поэтому было решено собрать систему по мониторингу уровня CO и метана в воздухе котельной на основе Arduino или совместимой платы. Помимо простой сигнализации, хотелось бы собирать еще и статистику, например, о том, как связаны концентрации опасных газов с работой газового оборудования. В принципе, задача реализуется на современном уровне культуры и техники, причем за очень небольшие деньги. В качестве источника расхода природного газа я использовал импульсы со встроенного в газовый счетчик датчика, а для анализа воздуха применил два чрезвычайно популярных в среде разработчиков Arduino датчика MQ-4 и MQ-7. MQ4 «нюхает» воздух на предмет содержания метана, а MQ7 проводит измерения в отношении CO.

Но для того чтобы пойти дальше, оказалось, что нужно конкретно углубиться в детали. Поскольку мало кто из пользователей Arduino и аналогов понимает, что это за датчики такие MQ-4 и MQ-7, и как ими вообще пользоваться. Ну так, приступим потихоньку к увлекательному повествованию.

Что такое ppm

Чтобы как следует оперировать со значениями, которые я буду приводить ниже, нужно для себя уяснить единицы измерений. У нас, на территории бывшего Советского Союза, показатели принято измерять в процентах (%) или же непосредственно в массе к объему (мг/м3). А вот в некоторых зарубежных странах применяет такой показатель как ppm.

Сокращение ppm расшифровывается как parts per million или в вольном переводе «частей на миллион» (хорошо, что тут не используют фунты на галлоны и империалы к саженям). В принципе, от процента показатель не сильно отличается, вернее, отличается только размерность. 1 ppm = 0,0001%, соответственно 3% = 30.000 ppm.

Перевод из процентов или ppm в мг/м3 уже сложнее, тут нужно учитывать молярную массу газа, давление и температуру. В целом формула для пересчета выглядит следующим образом P x VM=R x T, где P – давление, VM – молярный объем, R – универсальная газовая постоянная, T – абсолютная температура в Кельвинах (не Цельсиях и не Фаренгейтах). Но дабы не мучить читателя школьным курсом химии, сразу приведу несколько значений. А самые опытные бурители интернетов могут найти на просторах великой паутины онлайн-калькуляторы для самостоятельного расчета.

CO: 3% = 30.000 ppm = 34695.52 мг/м3
CO2: 3% = 30.000 ppm = 54513.22 мг/м3

Данные приведены для нормального атмосферного давления и комнатной температуры. Обратите внимание, что CO2 при сравнимом процентном соотношении почти вдвое тяжелее CO. Напомню, что молекула CO2 содержит на один атом больше, отсюда и разница. И именно благодаря этой разнице CO2 скапливается в низинах, а CO у потолка.

Различие СО и CO2

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

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

Основным источником выделения СО, как ни странно, является сгорание углеродного топлива при недостаточном количестве кислорода. Углерод «не догорает» и вместо углекислого газа CO2, в атмосферу выбрасывается угарный газ CO. В бытовом понимании отличным источником СО, при неправильной эксплуатации, могут выступать дровяные печи, газовые конфорки, газовые котлы и прочая отопительная техника, работающая на углеродном топливе. Не стоит забывать и про автомобили, в выхлопе бензинового двигателя СО может быть до 3%, а по гигиеническим нормам его должно быть не более 20 мг/м³ (около 0,0017%).

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

Оборотная сторона датчиков MQ-4 и MQ-7 от RobotDyn (цифровые и аналоговые).

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

Но не стоит думать, что CO2 газ нежнее и безопаснее газа CO. Высокие концентрации CO2 приводят к не менее тяжелым последствиям, вплоть до летального исхода. А поднять концентрацию можно легко и непринужденно всего лишь закрыв форточку в спальне на ночь. Более того, в отличие от CO, угольный ангидрид тяжелее воздуха и опасно скапливается в низинах, подвалах, подполах и прочих неожиданных местах. Документально зафиксированы случаи гибели людей, случайно попадающих в лощины полные углекислого газа, натекшего из соседнего вулкана. Двигатель автобуса глохнет, воздуха начинает не хватать и все. CO2 газ тоже без цвета, запаха и вкуса, посему его наличие определить органолептически почти и невозможно, кроме как контролировать наступление явно выраженного удушья.

И тот и другой газы состоят всего из двух видов элементов. Из кислорода (О) и углерода (С), вопрос только в количестве атомов кислорода. Знающий читатель может догадаться, что один газ в другой может превращаться с легкостью необыкновенной. Да, может, но не совсем с легкостью и не совсем обыкновенной. Нужно прилагать усилия. Так, например, в каталитических нейтрализаторах современных бензиновых автомобилей происходит процесс дожигания (превращения) CO в CO2. Процесс проходит при высокой температуре и в присутствии катализаторов (например, платины). Возможен и обратный процесс, но опять же непростой.

Кстати, в интернет есть сайт CO2.Earth отображающий динамику и текущую концентрацию углекислого газа в атмосфере Земли. Да, концентрация не такая уж и низкая. Ведь при скоплении углекислого газа в районе 2-4% человек теряет работоспособность, чувствует сонливость и слабость. А при концентрациях около 10% начинает ощущаться удушье.

Мы немного отклонились от темы, но вывод тут такой: не стоит путать два различных газа, равно как и последствия от них, но контролировать их присутствие в атмосфере помещений однозначно стоит.

Конструкция электрохимических датчиков

Самый распространенный вид датчиков MQ. И распространен он широко исключительно благодаря своей дешевизне. Я провел небольшое исследование, дабы попробовать разобраться в вопросе электрохимических датчиков немного больше, чем большинство любителей самостоятельно собрать какое-нибудь устройство.

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

Вот и состоит электрохимический датчик из некой подложки с чувствительным материалом, нагревателя подложки и собственно выводных контактов. Сверху на датчик натянута металлическая сетка, все же подложка ощутимо греется, да и всяческие газы горючие могут быть вокруг датчика, тот же CO. Для этого сетка и требуется. Безопасность превыше всего. Кстати, натягивать сетку на опасные элементы при применении во взрывоопасных средах придумал некий Гумфри Дэви еще для шахтеров в начале IXX века.

Схема электрохимического датчика

В сети можно насчитать пару десятков производителей плат с электрохимическими датчиками серии MQ. Но производитель у всех датчиков (не плат) один – китайская компания HANWEI. Компания выпускает весомый ассортимент различных устройств для детектирования газов и всего с ними связанного. Но сенсоров серии MQ среди номенклатуры нет, возможно, что продукция слишком уж мелкая, чтобы вывешивать ее на сайт.

Будучи по натуре любопытным персонажем, я покопался в спецификациях HANWEI и свел все доступные датчики серии MQ, материал подложки и тип детектирования в единую таблицу.

За исключением 300-й серии датчиков MQ все они используют один и тот же материал для подложки. Именно для той самой подложки которая и определяет концентрацию газа в атмосфере, именно для той подложки, которая меняет свое сопротивление. Во всех датчиках она используется одна и та же. У 300-й серии информация о чувствительном материале скромно опущена.

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

Прошу заметить, что все датчики имеют определенный и весьма небольшой срок жизни, который составляет порядка 5 лет. Причем 5 лет — это не только непосредственно работа, но и хранение. А если ваш датчик хранится без соответствующей упаковки, то срок его годности еще меньше. Дело в том, что чувствительный химический элемент, без нагрева, будет насыщаться углеродом, который постепенно его весь и разрушит. Именно по этой причине новые датчики рекомендуется «прокаливать» держа в рабочем состоянии на протяжении суток, а еще лучше двух. Тот углерод, что успел въесться в оксид олова (IV) «выгорит» и датчик сможет определять показания с более высокой точностью.

Если приглядеться к списку измеряемых газов или назначению датчиков, то видно, что все они, так или иначе, завязаны на углерод (метан, природный газ, пропан, угарный газ, сжиженный газ, алкоголь и даже датчики качества воздуха измеряют наличие углерода в соединениях в воздухе). И только датчик озона (MQ-131) стоит особняком, хотя и использует тот же самый чувствительный элемент с SnO2. Дело в том, что все датчики серии MQ рассчитаны на работу в атмосфере со стабильным уровнем кислорода. Спецификация говорит нам, что содержание кислорода должно быть 21%, что есть некая усредненная норма. А если кислорода меньше или больше, то показания будут плавать, вплоть до полной неспособности датчика выдавать вразумительные результаты при содержании кислорода на уровне 2% и ниже. Еще бы, в этом случае углерод совсем никак выгорать на подложке не будет, окислителя-то недостаточно. Видимо, на этом эффекте и рассчитано измерение озона электрохимическим датчиком.

Зависимость точности показаний датчика от влажности и температуры

Но точность показаний датчиков серии MQ зависит не только от кислорода. Показания хорошо меняются в зависимости от влажности воздуха и от его температуры. Расчетные показатели даны для влажности в 65% и температуры 20 градусов Цельсия. А при влажности выше 95% датчик перестанет адекватно выдавать показания. Жалко, что вот только не указана в спецификации какая влажность используется: относительная или абсолютная. Интуиция подсказывает, что все же относительная.

Помимо показателей окружающей среды на точность показаний датчиков MQ не хуже остальных параметров влияет еще и срок службы самих датчиков. Со временем их показания плывут. «Засоряется» продуктами измерения чувствительный слой, изменяются характеристики нагревателя и изменяется сопротивление при эталонных показателях. В какую сторону оно изменяется непонятно, но производитель рекомендует, во-первых, проводить калибровку датчика после покупки и первичного «отжига», а затем проводить регулярные перекалибровки на протяжении всего срока службы датчика. А единственный нормальный способ калибровки — сравнение результатов показания датчика с уже откалиброванным прибором. Понятное дело, что такого прибора нет ни у конечного потребителя-частника (а профи будут использовать несколько другие датчики, подороже), ни у многих производителей плат. Некоторые производители об этом заявляют честно прямо на своем сайте:

Заявление о невозможности нормальной калибровки датчиков

«И как же мне узнать, какова концентрация того или иного газа при помощи сенсора MQ?» — вопросит нетерпеливый читатель? Поскольку в большинстве случаев потребитель использует измеритель напряжения, впрочем с сопротивлением все аналогично, но меньше на один шаг, то у потребителя существует потребность в том, как вольты или кванты ЦАПа Arduino перевести в заветные ppm или хотя б проценты. Проделать сию операцию можно исключительно при помощи невнятных графиков из спецификации на датчик.

График: сопротивление в зависимости от концентрации газов.

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

График зависимости сопротивления датчика MQ-7 от концентрации исследуемых газов.

На этом хочется подвести промежуточный итог. Итак, к плюсам датчиков серии MQ можно отнести их крайне и категорически демократичную цену. А вот минусов намного больше:

• Фактически идентичные датчики использующие один и тот же чувствительный элемент и различающиеся используемым номиналом подстроечных резисторов.
• Зависимость результатов измерения от множества факторов: температуры, влажности, концентрации кислорода.
• Отсутствие заявляемой селективности по измеряемым газам, реагирует на все с углеродом (а, вполне возможно, и на другие элементы вступающие в реакцию с подложкой).
• Высокое энергопотребление (нагреватель).
• Необходимость в первичном «отжиге» датчика.
• Нестабильность показаний по времени.
• Необходимость первичной и повторяющейся калибровки.
• Практическая невозможность получения осмысленных значений в виде ppm или %.

Ну что же, пойдем дальше.

Цифровой или аналоговый?

Рынок знает свое дело и если на какой-то продукт есть спрос, то этот спрос будет удовлетворен. Рано или поздно, но будет обязательно. А с использованием шустрых китайских товарищей спрос удовлетворяется скорее рано, чем поздно. Так и появилось великое множество производителей с Китаю, производящие готовые платы с электрохимическими датчиками серии MQ. Давайте рассмотрим по возрастающей, какие могут быть вообще варианты поставки.

Чистый датчик

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

Датчик MQ-4

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

Аналоговый датчик

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

Аналоговый датчик

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

Цифровой датчик

Казалось бы, если датчик цифровой, то он должен выдавать информацию в цифровом виде. Однако, все цифровые датчики с сенсорами MQ, что мне попадались, не имели такой возможности. «Цифровой» в их названии означает только то, что датчик имеет цифровой выход, который переключается в режим HIGH при превышении некоего порога концентрации измеряемого газа. А основной съем значений пользователь осуществляет тем же самым аналоговым способом, как и с обыкновенным аналоговым датчиком.

Датчик с цифровым и аналоговым интерфейсом

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

Цифровой датчик с цифровой шиной

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

Цифровой датчик с цифровым интерфейсом

Судя по коду примера, предлагаемого производителем датчиков, сам датчик посылает данные в сыром виде и уже программно они переводятся в значения ppm. В целом от аналогового варианта датчик отличается только наличием цифровой шины.

Питание

Выше я уже упоминал, что для работы нагревателя датчиков MQ требуется подводить к нему качественное питание и в достаточно объеме. По спецификации датчики потребляют около 150 мА. В реальности потребление может плавать в весьма широком пределе. В принципе, 150 мА не такой уж и большой ток до тех пор, пока устройство (или несколько) с таким потреблением не пытаются скрестить с чем-то вроде Arduino. Подключив даже один такой датчик к питанию на плате, уже рискуешь получит неработоспособное устройство, которому не будет хватать напряжения для нормальной работы. При работе сами сенсоры нагреваются, не существенно, но градусов до сорока вполне могут раскочегариться. Если сравнить эту температуру с 60-70 градусами на стабилизаторе, питающем эти датчики, то температуру сенсоров можно считать сносной.

Для обеспечения нормальной работоспособности нагревателя и как следствие самого датчика необходимо подавать питание отдельно для этих датчиков. Например, использовать независимый источник питания на 1 или 2 А и 5V для питания датчиков (не все датчики потребляют 5V). Либо использовать специальную плату, преобразующую напряжение 9-12V в требуемое для питания датчиков.

Дишманский пульт мониторинга CO из платы Arduino, датчика MQ7 и планшета.

В любом случае с источником тока, обладающим нужной мощностью, придется повозиться. Хотя возможен вариант, когда датчик подключается напрямую к плате (например, Arduino). Но в этом случае ничего большего к ней подключать не рекомендуется.

Вариант калибровки датчика и преобразования показаний в ppm

Блуждая по сети в поисках решения по калибровке и получения достоверных результатов с датчика, я наткнулся на весьма любопытный пост от некоего Davide Gironi, который столкнулся с точно такой же проблемой, как и я. Davide попытался разобраться, каким образом можно получить с его датчика MQ-135 (Air Quality) показания в виде ppm.

Согласно исследованиям, проведенным блоггером для калибровки, достаточно иметь представление о концентрации какого-то газа в атмосфере и опираясь на эти данные попробовать подобрать резистор для попадания в нужный сектор по графику. Davide использовал датчик MQ-135 который предназначен для определения качества воздуха, среди контролируемых газов которого есть и CO2. И именно углекислый газ больше всего интересовал блоггера. Используя информацию с сайта co2now.org, он смог вычислить требуемый номинал резистора. Согласитесь, что метод весьма далек от идеала, но все равно лучше, чем ничего.

Затем, после калибровки он набросал небольшой код, позволяющий получить искомые ppm исходя из полученных в результате калибровки данных. Я не буду приводить здесь код, желающие могут ознакомиться с ним самостоятельно, но сводится он примерно к этому:

float ppm = ((10000.0 / 4096.0) * raw_adc) + 200;

Приведенный выше код, между прочим, из примера для датчика MQ-4 с цифровым интерфейсом I2C. Заметьте, что это лучше, чем ничего. Ведь многие просто не в состоянии дойти и до такого преобразования и ограничиваются лишь просто некими пороговыми значениями. Например, при значении 750 (единица измерений отсутствует, это квант), нужно врубать красный светодиод, в диапазоне 350-750 достаточно желтого, а когда ниже 350 пускай горит зеленый светодиод.

Альтернативы?

Если датчики MQ так уж плохи, то есть ли какая альтернатива для использования в домашних проектах? На самом деле есть. Даже много. Методов измерения концентрации газов не один и не два. Только вот датчики, обладающие высокой точностью, стоят приличных денег. И порой от такой стоимости наступает амфибиотропная асфиксия. Разница в стоимости может достигать тысячи и десятки тысяч раз. Тут невольно призадумаешься.

Один из вариантов миниатюрного датчика CO2 с инфракрасным методом измерения. Датчик MH-Z19.

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

Если же требуется детектирование других газов, но с применением недорогих устройств, то доступных вариантов на текущий момент (лето 2016 года) не так много, если не сказать прямо, что их совсем мало. Альтернативой можно считать использование серии MQ, правда обходиться придется только порогами значений (о точности перевода в ppm я уже высказался выше).

Сигнализатор CO. Применяется электрохимичский датчик и измерение в ppm.

Многие сразу же возразят, дескать, я лично использовал такой датчик, и он работает. В качестве примеров приводят опыты сродни «подышать на датчик», подержать вокруг него руку, пустить облачко сигаретного дыма. Да, показания датчика сразу же изменятся, значения поползут вверх. Да, датчик отразит то, что он нагрелся, то что увеличилась влажность, то, что в атмосфере стало больше углерода и меньше кислорода. Но насколько больше, какое количество исследуемого газа сейчас в атмосфере и самое важное какого именно газа? Вот на этот вопрос ответ при помощи датчиков серии MQ дать уже нельзя. Лучше уж приобрести обыкновенный бытовой сигнализатор опасных газов, того же СО. За вполне сопоставимые деньги вы получите устройство заводского исполнения, с громкой сигнализацией и низким потреблением энергии.

Датчики близнецы

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

Более того, я лично убежден, что все датчики MQ не имеют достаточного уровня селективности, отличаются только внешним дизайном и рекомендациями по подбору резисторов. Датчики реагируют на все содержащее углерод и тем сильнее реагируют, чем более активен углерод в соединении и чем он легче вступает в реакцию с подложкой. Я не верю, что производитель добавляет в подложку дополнительные элементы, повышающие селективность и при этом ничего не пишет в спецификацию. Зато я предполагаю, что один датчик можно превратить в другой, путем использования разных резисторов и смотрения на графики сопротивления и концентрации.

Графики показаний с датчиков MQ-4 и MQ-7 лежащих рядом друг с другом на столе

А ведь все началось с того, что я подключил два датчика (MQ-4 и MQ-7) к одному устройству и начал заливать результаты их работы на ThingSpeak. Один из датчиков должен измерять уровень ядовитого СО, а второй показывать сколько есть в воздухе метана. Меня очень заинтересовали графики, которые повторяли друг друга больше чем почти полностью. Да, один датчик выдавал показания на уровне 100-150 единиц, а второй на уровне 350-400. Пики и плато совпадали по времени от разных датчиков, а всплески лишь оттеняли неминуемую закономерность.

График корреляции показаний датчиков MQ-4 и MQ-7 лежащих на одном столе

Я свел показания обоих датчиков в единый график корреляции и понял, что они показывают одни и те же результаты, правда в разных диапазонах. И задался вопросом – зачем мне датчик метана, который реагирует на все? Начиная от угарного газа и заканчивая алкоголем. Зачем мне датчик СО, который помимо самого СО еще больше реагирует на LPG и водород? Вот именно – незачем.

Update. Прежде чем выкинуть в помойку ненужные датчики, я решил парочку из них разобрать и посмотреть, что же у них внутри. Итак:

Внутренности датчика MQ-4

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

Внутренности датчика MQ-7

Несмотря на другой внешний вид, внутренности MQ-7 идентичны внутренностям MQ-4. А нагреваемая бобышка сероватого цвета, есть ни что иное, как искомый оксид олова, который при нагревании и присутствии углерода или водорода (как раз те самые газы) частично восстанавливается, стремясь стать металлическим оловом, и соответственно изменяет свое сопротивление.

Форматный вывод на Си для микроконтроллеров.

Алгоритмы и программные решения
Форматированный ввод-вывод применяется очень широко, в первую очередь это, конечно, взаимодействие с пользователем, а так-же отладочный вывод, логи, работа с различными текстовыми протоколами и многое другое. В этой статье рассматриваются особенности применения форматированного вывода (ввод оставим на потом) для микроконтроллеров.
Первая программа написанная для ПК традиционно называется «Hello, world» и естественно пишет в стандартный вывод эту знаменитую фразу:

#include <stdio.h> int main(){ printf("%s", "Hello, world"); return 0; }

Первая программа для микроконтроллера обычно зовётся «Blinky» и она просто мигает светодиодом. Дело в том, что заставить работать традиционный «Hello, world» на микроконтроллере не так уж и просто для начинающего. Во первых, нет стандартного устройства вывода и его функциональность ещё нужно реализовать. Во вторых, не всегда бывает очевидно как подружить стандартные функции вывода с целевым устройством. Ситуация усугубляется тем, что в каждом компиляторе (тулчейне) это делается каким-то своим способом.

Форматный вывод.

Что-же, в общем, за зверь такой форматный вывод? Упрощенно говоря, это — вывод значений различных типов в виде текстовых полей.

Текстовое поле состоит из собственно значения, преобразованного в строку символов, и заполняющих символов для получения нужной ширины поля. Заполняющие символы могут находится слева или справа от значения, с помощью этого получается выравнивание по правому или левому краю соответственно. Заполнение также может находится внутри значения между определёнными его элементами, например между знаком и числом (как на рисунке), или между базой шестнадцатеричного числа (0x) и числом.
В качестве заполняющего символа обычно используется пробел, однако иногда могут использоваться нули, например в качестве ведущих нулей, или ещё что-нибудь.
Таким образом, форматированный вывод это — преобразование значений различных типов в текстовую форму и вывод их с определённым выравниванием и определённым заполнением.

Требования и особенности ввода-вывода для МК.

1. Гибкость. В отличии от старших братьев, для МК нет и не может быть стандартного устройства ввода-вывода. В каждой системе будет что-то своё, с уникальными требованиями и особенностями. В одной системе будет вывод в USART, во второй — на ЖК дисплей, в третей — в файл на SD карточке, в четвёртой — всё сразу. Значит система форматированного ввода-вывода должна быть достаточно гибкой, настраиваемой и независимой от аппаратных особенностей целевой платформы.

2. Требования к ресурсам. В МК ресурсов бывает мало и очень мало. В идеале, в прошивку МК должна попасть только та функциональность, которая реально используется. Скорость и размер кода имеют значение, под час решающее. Если мы не используем вывод типов с плавающей точкой, то и в полученной прошивке не должно быть кода, который его осуществляет.

3. Стойкость к ошибкам кодирования. В идеале, хорошо было-бы если ошибка кодирования приводила бы сразу к ошибке компиляции, ну или по крайней мере к предупреждению. Чтоб не надо было заливать программу в железо и ходить отладчиком вылавливать место, где там, в функцию предался неправильный аргумент.

4. Доступность. Библиотека ввода-вывода должна быть в наличии для целевой платформы.

5. Функциональность часто ставится на последнее место в угоду скорости и компактности.

Стандартная библиотека Си.

Стандартным и единственно доступным средством форматированного вывода в Си является семейство функций: printf, sprintf, snprintf и fprintf.
Рассматривать будем функцию printf, как наиболее типичного и часто используемого представителя функций форматного вывода, при необходимости переходя к другим. Итак фунция printf имеет следующий синтаксис:

int ptintf(const char *fmt, ...);

Это обычная функция с переменным числом параметров. Здесь первый аргумент fmt является форматной строкой, которая содержит, как обычный текст, так и специальные управляющие последовательности. Троеточие (…) обозначает список дополнительных параметров, их может быть от нуля и до сколько поместится в стеке. Да, да все параметры в функцию printf передаются преимущественно в стеке (за исключением архитектуры ARM, где первые 4 параметра передаются в регистрах). Запихивает их в стек вызывающая функция, она-же инициализирует кадр стека перед вызовом и очищает после. Сама printf узнать сколько и каких параметров ей было передано может узнать только из форматной строки. При передачи параметров размером меньше (signed char, unsigned char, char и на некоторых платформах signed/unsigned short), чем int, они будут расширенны соответствующим расширением(знаковым или без-знаковым) до int-a. Это сделано для того, чтобы стек был всегда выровнен по границе машинного слова, а так-же уменьшает количество возможных ошибок при нестыковке размера фактического параметра и ожидаемого из форматной строки. Так-же параметры типа float при передаче в функции с переменным числом аргументов, приводятся к типу double.
Форматная строка содержит как символы непосредственно выводимые в поток, так и специальные управляющие последовательности, которые начинаются со знака «%». Управляющие последовательности имеют следующий формат:

%[флаги][ширина][.точность|длинна]спецификатор[дополнительный модификатор]

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

Флаги определяют дополнительные параметры форматирования (их может быть несколько):

Ширина — десятичное число, задаёт минимальное количество символов выводимых для соответствующего параметра. Если выводимое значение содержит меньше символов, чем указано, то оно будет дополнено пробелами (или нулями если есть флаг «0») до нужной ширины слева или справа, если указан флаг «-«. Например:

printf("a =%10d", 123); Будет выведено ("_" - подчерк считать пробелом): a_=_ _ _ _ _ _ _123 printf("a =%-10d", 123); a_=123_ _ _ _ _ _ _ printf("a =%010d", 123); a_=0000000123 

Если вместо десятичного числа указать «*», то значение ширины будет считанно из дополнительного целочисленного параметра. Это позволяет задавать значение ширины поля вывода из переменной:

for(int i=1; i < 10; i++) printf("i =%0*d", i, i);

Здесь первый раз i передаётся в качестве ширины поля, второй — значения.
Точность или длинна — десятичное число после знака точки «.». В случае вывода целых чисел этот элемент означает минимальное количество записанных знаков, если выводимое число короче указанной длинны, то оно дополняется ведущими нулями, если число длиннее, то оно не урезается.

printf("a = %.6d", 123); a = 000123

Таким образом есть уже два способа вывести целое с нужным количеством ведущих нулей.
Для чисел с плавающей точкой в форматах «e», «E» и «f» этот элемент означает число знаков после десятичной точки. Результат округляется.

printf("f = %.2f", 12.3456); f = 12.35

Для форматов «g» и «G» это — общее количество выведенных значимых цифр.

printf("f = %.2g", 12.3456); f = 12

Для строк «s» этот элемент называется длинна и означает максимальное количество выведенных символов, обычно строки выводятся пока не встретится нулевой завершающий символ.

printf("%.5s\n", "Hello, world"); Hello

Также как и в элемента «ширина», в место точности можно поставить звёздочку и передать её значение в виде дополнительного целочисленного параметра:

char str[] = "Hello, world"; for(unsigned i = 1; i < sizeof(str); i++) printf("%.*s\n", i, str); H He Hel Hell Hello Hello, Hello, Hello, w Hello, wo Hello, wor Hello, worl Hello, world

Дополнительный модификатор служит для указания размерности типа:
h — применяется со спецификаторами i, d, o, u, x и X для знаковых и без-знаковых коротких целых short и unsigned short).
l — совместно со спецификаторами i, d, o, u, x и X означают длинные целые long и unsigned long).
l — совместно со спецификаторами s и c «широкие» многобайтные строку и символ соответственно.
L — обозначает тип long double, применяется со спецификаторами e, E, f, g и G.
В компиляторах поддерживающих тип long long, таких как GCC и IAR, часто есть для него нестандартный модификатор ll.
В стандарте С99 добавлены модификаторы «t» и «Z» для типов ptrdiff_t и size_t соответственно.

Работа над ошибками

Основным недостатком функций семейства printf считается вовсе не громоздкость и неторопливость — размер кода и накладные расходы на запихивание параметров в стек и разбор форматной строки обычно считаются приемлемыми, а подверженность ошибкам кодирования. Самое неприятное в этих ошибках то, что они могут быть неочевидными и проявляться не всегда, или не на всех платформах.
Большинство ошибок связано с несоответствием спецификаторов указанных в форматной строке с количеством и типами фактических аргументов. При этом можно выделить следующие ситуации:
— занимаемый в стеке размер параметров ожидаемых из форматной строки меньше размера фактически переданных. Типы фактические параметров совпадают с ожидаемыми. В этом случае просто выведутся параметры указанные в форматной строке, а лишние будут проигнорированы.
— занимаемый в стеке размер параметров ожидаемых из форматной строки меньше размера фактически переданных. Типы фактические параметров не совпадают с ожидаемыми. В этом случае параметры просто будут интерпретированы в соответствии с форматной строкой и в общем случае будет выведен мусор.
— размер фактических параметров меньше ожидаемых. Здесь поведение не определено и зависит от кучи разных факторов — от платформы, от компилятора, от содержимого стека на момент вызова printf. Поведение printf при этом может быть от внешне корректной работы и до чтения и даже записи произвольных участков памяти со всеми вытекающими последствиями.
Многие ошибки возникают при переносе кода с одной платформы на другую у которых отличаются размеры типов. Например:

printf("A = %x", 0x12345678); 

На платформах, где int имеет 32 бита этот код работает правильно, а где int — 16 бит — будут выведены только 2 младших или старших (в зависимости от порядка следования байт) байта.
К счастью некоторые компиляторы, например GCC, знают printf «в лицо» и выдают предупреждения в случае несовпадения фактических параметров с форматной строкой. Однако это работает только если форматная строка задана литералом. А если она хранится в переменной (например extern указатель инициализируемый в другом модуле), то компилятор бессилен и проследить соответствеи параметров может быто очень не просто.

Особенности реализаций

AVR

AVR достаточно неудобная платформа для работы со строками из-за того, что они могут располагаться в различных адресных пространствах и когда работаешь со строкой всегда нужно помнить где именно она расположена. В первую очередь нас естественно интересуют строки в RAM и во Flash.
Примеры для AVR рассчитаны для запуска на симуляторе sImulavr и используют его механизм отладочного вывода как стандартный вывод. Это позволит не отвлекаться на инициализацию устройств выводи и т. д. К тому-же не надо загружать прошивку в устройство для запуска.

AVR-GCC он-же WinAVR

В AVR-GCC, а точнее в avr-libc самая удачная, на мой взгляд, реализация стандартной библиотеки ввода-вывода Си. В ней имеется возможность выбирать необходимый функционал функций семейства printf. Они прекрасно работают со строками как RAM так и во Flash. Все функции семейства, включая snprintf и fprintf разделяют общий код и очень хорошо оптимизированы как по скорости, таки по объёму кода.
Для поддержки находящихся во Flash памяти строк введен новый спецификатор форматной строки %S — S — заглавная, строчная s по-прежнему означает строку в RAM. Но во Flash памяти может быть и сама форматная строка, для этого есть специальные модификации функций с суффиксом «_P» printf_P, fprintf_P, sprintf_P и т. д., которые ожидают форматную строку во Flash.
Для того чтобы printf заработала, нужно написать функцию вывода символа и определить файловый дескриптор стандартного вывода.

#include <avr/io.h> // для printf #include <stdio.h> // для PROGMEM #include <avr/pgmspace.h> // порт для отладочного вывода - определен в параметрах запуска симулятора #define special_output_port (*((volatile char *)0x24)) // прототип функции вывода символа static int my_putchar(char c, FILE *stream); // определяем дескриптор для стандартного вывода static FILE mystdout = FDEV_SETUP_STREAM( my_putchar, // функция вывода символа NULL, // функция ввода символа, нам сейчас не нужна _FDEV_SETUP_WRITE // флаги потока - только вывод ); // функция вывода символа static int my_putchar(char c, FILE *stream) { special_output_port = c; return 0; } // форматная строка во flash PROGMEM char str1[] ="Format str from flash\nlong = %15ld\nFlash string = %10S\n"; // просто строка во flash PROGMEM char str2[] = "string form flash"; __attribute((OS_main)) int main(void) { // инициализируем стандартный дескриптор stdout = &mystdout; // форматная строка в RAM и выводим строку из RAM printf("Format str from ram\nlong = %15ld\nRam string = %10s\n", 1234567890l , "string from RAM"); // форматная строка в flash и выводим строку из flash printf_P(str1, 1234567890l , str2); return 0; }

Помимо stdout есть стандартные дескрипторы stdin и stderr для стандартного ввода и стандартного вывода ошибок соответственно. Используя функцию fprintf можно явно указывать нужный файловый дескриптор и при необходимости можно определить сколько угодно устройств вывода:

static FILE lcd = FDEV_SETUP_STREAM( my_lcd_putchar, NULL, _FDEV_SETUP_WRITE); static FILE usart= FDEV_SETUP_STREAM( my_usart_putchar, NULL, _FDEV_SETUP_WRITE); … stdout = &lcd; stderr = &usart; … fprintf(stderr, "Hello, world!"); fprintf(stdout, "Hello, world!");

В avr-libc имеется три уровня функциональности библиотеки ввода-вывода:
1. нормальный — поддерживается вся упомянутая выше функциональность, кроме вывода чисел с плавающей точкой. Этот режим включен по умолчанию и каких либо опций для него указывать не надо. Поддержка чисел с плавающей точкой занимает много места, а нужна сравнительно редко. Приведенный выше пример, скомпилированный с этим уровнем функциональности, занимает порядка 1946 байт Flash памяти.
2. минимальный — поддерживаются только самые базовые вещи: целые, строки, символы. Флаги, ширина поля и точность, если они есть в форматной строке, разбираются корректно, но игнорируются, поддерживается только флаг «#». Пример, скомпилированный с этим уровнем функциональности, занимает порядка 1568 байт Flash памяти. Его вполне можно было-бы применить на контроллере с 2 Кб flash памяти. Включается указанием в командной строке компоновщика («Linker options» в AVRStudio, а не компилятора, как расплывчато указано в документации avr-libc) следующих опций:

-Wl,-u,vfprintf -lprintf_min

3. максимальный — полная функциональность, включая поддержку чисел с плавающей точкой. Включается опциями

-Wl,-u,vfprintf -lprintf_flt -lm

Скомпилированный пример занимает при этом 3488 байт.
Функции семейства printf из avr-libc не используют буферизацию, не считая буферов для конвертации чисел, и выводят символы в устройство по мере их обработки. Поэтому, если буферизация нужна, то ее можно реализовать самостоятельно в функции вывода символа, там можно реализовать и кольцевой буфер и все, что угодно. Также в этих функциях не используется динамическая память, что в нашем случае очень хорошо, зато активно используется стек. Попробуем определить максимальное использование стека в них. Для этого в приложенном архиве заходим в каталог AvrGccPrintf, компилируем проект посредством AVRStudio и запускаем симуляцию с помощью runSimul.cmd.

После открывает образовавшийся файл trace.log, находим значение указателя стека (SP) после входа в main (после пролога), находим минимальное значение SP (стек растёт вниз) и вычитаем из первого второе. У меня получилось 0x455 — 0x429 = 0x2c = 44 байта использует сама функция fprintf, плюс еще 8 байт в стеке занимают ее параметры, итого 52 байта. Еще 14 байт занимает один файловый дескриптор и ещё 6 байт три стандартных указателя на файловые дескрипторы (stdout, stdin, stderr). Итого 72 байта RAM только на вызов fprintf, без учета всего остального.
Также из файла trace.log можно узнать общее время выполнения функций и где процессор проводит его больше всего.

Подробнее о стандартной библиотеке ввода-вывода avr-libc можно здесь:
www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html

IAR for AVR

Здесь есть несколько версий Си-шных библиотек, с отличающейся функциональностью:
— CLIB — относительно маленькая, но ограниченная библиотека. Нет поддержки файловых дескрипторов, локалей и многобайтных символов. Считается устаревшей.
— Normal DLIB — более новая. Так-же нет поддержки файловых дескрипторов, локалей и многобайтных символов, но есть некоторые плюшки из стандарта С99.
— Full DLIB — полная библиотека Си. Поддерживает всё согласно стандарту С99, но при этом очень объёмная. Рассматривать этот вариант не буду, так, как размер функции printf отсюда превышает доступные 4 Кб кода для бесплатной версии IAR KickStart for AVR.
В IAR имеется возможность выбирать возможности для printf. Для этого заходим с меню Project->Options далее в диалоге General Options->Library Configuration. В списке «Printf formatter» можно выбрать необходимый уровень функционала. Для CLIB это Large, Small, Tiny, для DLIB добавляется еще Full. По возможностям эти уровни примерно соответствуют аналогичным в avr-gcc, поэтому расписывать их не буду.

Для того чтобы printf заработала, надо определить функцию вывода символа:

int putchar(int outchar);

Разберём полный пример. Он также предназначен для запуска на симуляторе.

#define special_output_port (*((volatile char *)0x24)) #define special_exitcode_port (*((volatile char *)0x020)) #include <ioavr.h> #include <stdio.h> // для printf_P #include <pgmspace.h> __flash char str1[] ="Format str from flash\nlong = %15ld\nFlash string = %10S\n"; __flash char str2[] = "Hello"; int putchar(int outchar) { special_output_port = outchar; return outchar; } int main(void) { printf("Format str from ram\nlong = %15ld\nRam string = %10s\n", 1234567890l , "Hello"); printf_P(str1, 1234567890l , str2); special_exitcode_port = 0; return 0; }

Тут выясняются две неприятные особенности. Во-первых функции printf и printf_P видимо не разделяют общий код и printf_P всегда использует максимальный форматтер, независимо от того, что выбрали в настройках для printf, занимая порядка 3500 байт кода. Поэтому приведенный пример не помещается в четыре бесплатных килобайта. Для проверки одну из функций надо закомментировать.
Во-вторых, ни printf, ни printf_P не умеют читать строки из flash памяти — для них нет спецификатора.
Размеры printf для различных уровней функциональности примерно соответствуют аналогичным у avr-gcc, где чуть меньше, где чуть больше — непринципиально. А вот использование стека в разы выше, минимальный размер стека данных, при котором printf заработала, составил 200 байт для DLIB и около 150 для CLIB. Так, что на контроллерах с 2 кб flash, 128 RAM использовать эти функции не получится.
Демо-проект находится в каталоге AvrIarPrintf. Для запуска симуляции, а точнее преобразования генерируемого IAR-ом hex-а в пригодный для потребления simulavr-ом elf, на машине должен быть установлен WinAVR (и прописан в переменной окружения PATH, естественно).

Mspgcc

В стандартной библиотеке mspgcc для форматного вывода реализованы только функции printf и sprintf, плюс еще нестандартная функция uprintf, которая принимает указатель на функцию вывода символа в качестве первого аргумента. Файловых дескрипторов там нет и в помине, выбирать уровень функциональности форматтеров тоже нельзя. При этом printf «весит» порядка двух килобайт так, что запустить её, скажем, на MSP43 Launchpad-е не получится.
Для работы printf нужно, вполне ожидаемо, определить функцию int putchar(int c):

int putchar(int c) { // вывод символа ... return c; } 

IAR for MSP430, IAR for ARM и может еще какой IAR

Вообще в реализациях стандартной библиотеки от IAR Systems всё довольно однообразно для различных платформ, что не может не радовать. Как правило есть минимум две версии стандартной библиотеки — одна урезанная без поддержки файловых дескрипторов, вторая — полная, соответственно, с их поддержкой. Зовутся они как правило «Normal» и «Full» соответственно. Так-же в каждой из них можно выбирать необходимый функционал разбора форматной строки, поддерживаемый функциями семейства printf. Варианты уже уже описаны для IARfor AVR: Large, Small, Tiny и Full.
Если выбрать вариант библиотеки без файловых дескрипторов, то для работы функций вывода нужно определить лишь функцию int putchar(int outchar).
Если используем вариант с дескрипторами, то определить нужно функции __write, __lseek, __close и remove.
Минимальная их реализация, например, для STM32 может выглядеть так:

// Посылает один символ в USART1. static void Putch(uint8_t c) { if(c == '\n') Putch('\r'); while(( USART1->SR & USART_SR_TXE) == 0); USART1->DR = c; } // Вывод буфера в файл/поток, где // handle - номер открытого файла, // buf - буфер с данными, // bufSize - размер буфера, // возвращает количество фактически записанных символов. size_t __write(int handle, const unsigned char *buf, size_t bufSize) { for (int i = 0; i < bufSize; i++) { Putch(buf[i]); } return bufSize; } // Установка текущей позиции в потоке. // Нам сейчас не нужно. int __lseek(int handle, int ptr, int dir) {return 0; } // Закрыть поток. int __close(int handle) { return -1; } // Удалить файл. // Не знаю зачем printf требует определения этой функции. int remove(const char *fname) { return -1; } 

ARM + NewLib

Большинство сборок GCC под ARM используют NewLib в качестве стандартной библиотеки Си. Это достаточно взрослый проект и хорошо соответствует Си-шным стандартам, но при этом она относительно «тяжела» и требовательна к ресурсам. Для настройки библиотеки под свои нужды используется механизм системных вызовов. О нём уже немного писалось тут ispolzuem-libc-newlib-dlya-stm32, поэтому подробно на них останавливаться не буду, а упомяну об особенностях.
Первое это требования к памяти. Все stdio функции из NewLib используют хитрую буферизацию и динамически распределяют память для своих внутренних нужд. А значит им нужна куча и не маленькая, а в целых 3 Кбайт. Плюс примерно 1500 байт на статические структуры и плюс около 500 байт стека. Итого только чтоб напечатать «Hello, world!» нужно порядка 5 Кб оперативки. Что как-бы чуть больше, чем много для STM32-Discovery, на которой я запускал тестовый пример, с её 8 килобайтами. Также при использовании таких функций как printf по зависимостям тянется практически вся stdio плюс функции поддержки плавающей точки. В итоге тестовая прошивка занимает чуть меньше 30 Кб памяти программ. Если отказаться от использования чисел с плавающей точкой, то вместо printf можно использовать её облегченный аналог iprintf. В этом случае объём тестовой прошивки будет около 12 Кб.
Если какая либо из функций stdio не сможет выделить необходимую её память из кучи, то она тихонечко свалится в HardFault без объяснений причин.
Еще один момент это буферизация. Она может несколько запутать. Вызываем:

printf("Hello, World!");

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

printf("Hello, World!\n"); ... printf("Hello again!"); fflush(stdout); 

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

setvbuf(stdout, NULL, _IONBF, 0); 

При этом потребление памяти кучи уменьшится более чем на 1.5 Кб.

Xprintf

Это реализация функций похожих на printf от товарища Chan-а. Качаем отсюда:
elm-chan.org/fsw/strf/xprintf.html
Библиотека содержит следующие функции для форматированного вывода — аналоги функций стандартной библиотеки Си:

void xputc (char c); void xputs (const char* str); void xfputs (void (*func)(unsigned char), const char* str); void xprintf (const char* fmt, ...); void xsprintf (char* buff, const char* fmt, ...); void xfprintf (void (*func)(unsigned char), const char* fmt, ...); 

Все функции написаны целиком на Си и их можно использовать практически на любом микроконтроллере. Однако они не учитывают особенностей некоторых МК, например, нет никакой поддержки строк во Flash памяти для семейства AVR, что не добавляет удобства использования. Для использования xprintf необходимо инийиализировать указатель xfunc_out, присвоив ему адрес функции вывода символа. Рассмотрим пример. Компилятор avr-gcc, проект AvrStudio, рассчитан на запуск в симуляторе simulavr.

#include <avr/io.h> // для PROGMEM и strncpy_P #include <avr/pgmspace.h> #include "xprintf.h" #define special_output_port (*((volatile char *)0x24)) #define special_input_port (*((volatile char *)0x25)) #define special_abort_port (*((volatile char *)0x22)) #define special_exitcode_port (*((volatile char *)0x020)) // функция вывода символа static void my_putchar(unsigned char c) { special_output_port = c; } // строки во Flash памяти PROGMEM char str1[] ="Format str from flash\nlong = %15ld\nFlash string = %10s\n"; PROGMEM char str2[] = "Hello form flash"; // буферы для временного копирования строк char buffer[60]; char buffer2[20]; __attribute((OS_main)) int main(void) { // инициализируем укзатель нашей функцией вывода символа xfunc_out = my_putchar; xprintf("Format str from ram\nlong = %15ld\nRam string = %10s\n", 1234567890l , "Hello"); xfprintf(my_putchar, "Hello, world!\n"); strncpy_P(buffer, str1, sizeof(buffer)); strncpy_P(buffer2, str2, sizeof(buffer2)); xprintf(buffer, 1234567890l , buffer2); special_exitcode_port = 0; return 0; }

Здесь для вывода строк из Flash памяти их приходится предварительно скопировать в оперативку.
Из достоинств этой библиотеки можно выделить компактность кода (~1600 байт для приведённого примера) и лёгкость использования на различных платформах и модифицировать. На этом достоинства заканчиваются. Из недостатков стоит отметить
относительно медленную работу, примерно в полтора-два медленнее чем стандартная printf из avr-libc, и несоответствие стандартам — не поддерживаются некоторые флаги (‘пробел’, ‘ #’, ‘+’ ), спецификаторы (i, p n), не считая флагов для чисел с плавающей точкой и т.д.
Потребление стека порядка 38 байт не считая аргументов.

Описание примеров.

В приложенном архиве находятся следующие примеры:

AvrGccPrintf

Проект для AvrStudio 4. Запускается на симуляторе Simulavr. Чтоб запустить нужно скомпилировать и выполнить скрипт «runSimul.cmd». В логе симуляции «trace.log» можно посмотреть времена выполнения функций и оценить расход стека.

AvrIarPrintf

Тоже, что и в предыдущем примере, только компилируется в IAR for AVR.

AvrXprintf

Проект для AvrStudio 4. Запускается на симуляторе Simulavr. Для вывода используется библиотека xprintf от ELM Chan.

Msp430GccPrintf

Коппилируется mspgcc. Проект для Code::Blocks. Запускать планировалось на MSP430 Launchpad с контроллером MSP430G2231. Пример должен считывать температуру со встроенного датчика и посылать ее через програмый usart. Но к сожалению функция printf из библиотеки mspgcc не помещается в имеющиеся 2 Кб памяти. По этому используется функция puts. которая выводит строчку «Hello, world!».

Msp430IarPrintf

IAR для MSP430. Запускается на MSP430 Launchpad. В отличии от mspgcc, минимальная версия printf умещается в 2Кб флеша MSP430G2231.

Stm32Format

GCC + NewLib. Работает на STM32 Discovery. собирается с помощью makefile. проверял с Yagarto и CodeSourcery.

IarArm

Работает на STM32 Discovery. Собирается с помощью IAR for ARM.

Итоги.

Преимущества использования стандартной библиотеки Си для форматного вывода:
— Стандартность. Этим всё сказано.
— Доступность. В каком-то виде есть практически в любом Си компиляторе.
— Разделение формата вывода и выводимых данных. Форматную строку легко вынести в отдельный файл/модуль, например для дальнейшей локализации.
— Хорошая функциональность.
Недостатки:
— Полностью стандартная реализация в большинстве случаев слишком «тяжела» для микроконтроллеров.
— Использование лишь одной функции, например printf, тянет за собой значительную часть библиотеки вывода, даже если реально используются только ограниченные возможности.
— Неаккуратное использование функций с форматной строкой может привести к трудно обнаруживаемым ошибкам кодирования.
— В каждом компиляторе используется какой-то свой способ для определения низкоуровневых функций вывода.

Arduino & Modbus

• SCADA

В предыдущей статье мы соединили открытую платформу домашней автоматизации OpenHAB с контроллером Arduino использовав очень простой, текстовый протокол. Но это решение поставит нас в тупик, если мы захотим подключить наш контроллер к другой системе, что же делать?

Modbus — самый известный и распространенный стандарт в промышленной автоматизации, его поддерживают миллионы устройств по всему миру, эти устройства легко интегрируется в единую сеть и стыкуются с огромным количеством готового программного обеспечения. Попробуем использовать его в нашем проекте?

Что нам необходимо знать об этом стандарте?
Протокол Modbus использует последовательные линии связи (например, RS232, RS485), а протокол Modbus TCP рассчитан на передачу данных по сетям TCP/IP.
Протокол Modbus имеет два режима передачи RTU и ASCII, в режиме ASCII каждый байт передается как два ASCII символа его шестнадцатеричного представления.
В сети Modbus есть только один ведущий, который с заданным интервалом опрашивает несколько ведомых устройств, каждое из которых имеет свой уникальный адрес от 1 до 254, адрес 0 широковещательный и на него отвечают все устройства, так как ведущий в сети один у него нет своего адреса.
В спецификации Modbus определено два типа данных, один бит и 16 битное слово. Данные организованны в четыре таблицы с 16 битной адресацией ячеек, адресация в таблицах начинается с 0. Для доступа к данным из разных таблиц предназначены отдельные команды.

Как нам подключить Modbus устройство к OpenHAB? За это отвечает модуль Modbus Tcp Binding, этот модуль работает в режиме ведущего и обеспечивает подключение нескольких ведомых устройств через последовательный порт или TCP/IP сеть.
Для того чтобы связать с ним Arduino нам необходимо реализовать в контроллере ведомое Modbus устройство, воспользуемся для этого библиотекой Modbus-Master-Slave-for-Arduino.

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

Рассмотрим на примере нашего скетча основные шаги необходимые для работы с этой библиотекой.

Все функции библиотеки реализованы в одном файле ModbusRtu.h.
Для взаимодействия с ней, в программе нужно создать объект, задав в его конструкторе Modbus адрес, номер последовательного порта, номер выхода, управляющего передачей (для RS485)

Modbus slave(ID, 0, 0); 

Затем определить массив регистров Modbus

uint16_t au16data[11]; 

После этого, при старте программы настроить последовательный порт ведомого

slave.begin(9600); 

В основном цикле программы необходимо вызывать функцию обработки Modbus сообщений

state = slave.poll(au16data, 11); 

И после этого можно обработать полученные данные и сохранить необходимые переменные в регистрах Modbus.

#include "ModbusRtu.h" #define ID 1 // адрес ведомого #define btnPin 2 // номер входа, подключенный к кнопке #define stlPin 13 // номер выхода индикатора работы // расположен на плате Arduino #define ledPin 12 // номер выхода светодиода //Задаём ведомому адрес, последовательный порт, выход управления TX Modbus slave(ID, 0, 0); boolean led; int8_t state = 0; unsigned long tempus; // массив данных modbus uint16_t au16data[11]; void setup() { // настраиваем входы и выходы io_setup(); // настраиваем последовательный порт ведомого slave.begin( 9600 ); // зажигаем светодиод на 100 мс tempus = millis() + 100; digitalWrite(stlPin, HIGH ); } void io_setup() { digitalWrite(stlPin, HIGH ); digitalWrite(ledPin, LOW ); pinMode(stlPin, OUTPUT); pinMode(ledPin, OUTPUT); pinMode(btnPin, INPUT); } void loop() { // обработка сообщений state = slave.poll( au16data, 11); // если получили пакет без ошибок - зажигаем светодиод на 50 мс if (state > 4) { tempus = millis() + 50; digitalWrite(stlPin, HIGH); } if (millis() > tempus) digitalWrite(stlPin, LOW ); //обновляем данные в регистрах Modbus и в пользовательской программе io_poll(); } void io_poll() { //Копируем Coil[1] в Discrete[0] au16data[0] = au16data[1]; //Выводим значение регистра 1.3 на светодиод digitalWrite( ledPin, bitRead( au16data[1], 3 )); //Сохраняем состояние кнопки в регистр 0.3 bitWrite( au16data[0], 3, digitalRead( btnPin )); //Копируем Holding[5,6,7] в Input[2,3,4] au16data[2] = au16data[5]; au16data[3] = au16data[6]; au16data[4] = au16data[7]; //Сохраняем в регистры отладочную информацию au16data[8] = slave.getInCnt(); au16data[9] = slave.getOutCnt(); au16data[10] = slave.getErrCnt(); } 

Стандарт предусматривает отдельную таблицу для каждого типа данных, но особенностью применённой библиотеки является то, что все регистры хранятся в одном массиве в виде перекрывающихся таблиц, поэтому структура регистров контроллера будет выглядеть следующим образом:

Для демонстрации работы с разными регистрами, в процессе работы программы данные из регистра с типом coil будут скопированы в регистр с типом discrete, а из регистров с типом holding в регистры с типом input. Кроме этого состояние кнопки будет сохранено в третий бит регистра au16data[0] (discrete), а значение третьего бита регистра au16data[1] (coil) выведено на светодиод.

Доработаем макет контроллера, который был собран для предыдущих экспериментов, переключим светодиод с 13 на 12 вывод. Обычно на плате самого Arduino уже есть светодиод, подключенный к 13 выводу, в нашей программе он станет индикатором статуса работы. Теперь подключим USB кабель к компьютеру, скомпилируем и загрузим программу в контроллер.

Пора приступать к испытаниям. Значительно облегчает работу на этом этапе эмулятор Modbus мастер-устройства, в сети есть несколько хороших, при этом бесплатных программ, вот некоторые из них:
www.focus-sw.com/fieldtalk/modpoll.html
qmodbus.sourceforge.net
www.mikont.com/products/EAT-Console.html

Среди них можно отметить утилиту EAT-Console которая позволяет не только управлять и опрашивать Modbus устройства, но и отображает данные в графическом виде, что очень удобно при отладке работы с различными датчиками, например датчиками влажности, давления и температуры. Перед началом работы с программой и её конфигуратором рекомендую ознакомиться с документацией.

Для установки эмулятора нужно скачать архив и распаковать его в папку C:\arduino\EATConsole, затем открыть страницу загрузки Eclipse, скачать Eclipse IDE for Java Developers и распаковать его в папку C:\arduino\eclipse, после этого скопировать файлы из папки C:\arduino\EATConsole\eclipse\plugins в папку C:\arduino\eclipse\plugins.

Для создания конфигурации необходимо запустить C:\arduino\eclipse\eclipse.exe, создать пустой проект, скопировать в него пустой файл C:\arduino\EATConsole\menu.ptmenu и добавить в редакторе пункты в соответствии со следующей таблицей. Если же вы скачали проект из репозитория, то в нём, в папке EATConsole уже есть подготовленный файл menu.ptmenu.

Type — тип элемента меню EATConsole.
Address — адрес регистра данных.
Bit – номер бита в регистре.
Name – название элемента меню.
Point – количество десятичных знаков после точки.
Slave – Modbus адрес контроллера.

Теперь сохраним и скопируем файл menu.ptmenu в каталог C:\arduino\EATConsole, для этого можно щёлкнуть правой кнопкой мыши на файле прямо в Eclipse, выбрать в контекстном меню пункт “Copy”, а затем вставить в проводнике в папку C:\arduino\EATConsole.

После этого запустим C:\arduino\EATConsole\EATConsole.exe, настроим последовательное соединение, выбрав пункт меню Файл\Настройки, в диалоговом окне укажем номер порта, скорость 9600, 8 бит данных, 1 стоповый бит.

*Программа работает с портами с 1 по 8 и если USB переходник Arduino встал на порт с большим номером, придётся открыть диспетчер устройств Windows и изменить номер порта для него.

Когда все настройки будут введены, нажмите кнопку “Установить”, сразу после этого программа начнёт опрос устройства и если что-то пошло не так появится сообщение – НЕТ СВЯЗИ. Если же всё было сделано правильно и связь есть в чём можно убедиться по миганию индикатора статуса (светодиод на выводе 13), то пора приступить к испытаниям нашего контроллера.

Попробуем поменять значение в регистрах HLD0…HLD2 и СL0…СL2, при этом должно поменяться значение в соответствующем регистре IN0..IN2 и DT0..DT2, затем нажмём на кнопку макета, при этом должно поменяться значение в поле BTN, щёлкнем по полю LED, при этом должен загореться или потухнуть светодиод.

Что мы получили в результате нашей работы:

1 познакомились с азами протокола Modbus;
2 создали скетч, который превращает Arduino в Modbus slave устройство и позволяет читать и записывать несколько Modbus регистров с разными типами данных;
3 протестировали обмен с контроллером при помощи эмулятора функций Modbus master устройства, для которого создали конфигурацию соответствующую структуре регистров контроллера.

Выводы
Библиотека Modbus-Master-Slave-for-Arduino проста в использовании, позволяет создать ведомое Modbus устройство, которое корректно работает с программным эмулятором. Скомпилированный пример занимает немногим более 5кб памяти программ, так что в контроллере остаётся достаточно места для добавления необходимого функционала.

Стандарт Modbus открыт и популярен, но в нём есть ряд недостатков — в стандарте определено только два типа данных,
протокол требует постоянного обмена между ведущим и ведомыми устройствами, конфигурировать систему приходится вручную.

Имея некоторые недостатки, протокол вполне пригоден для использования в контроллере систем домашней автоматизации, особенно если необходима стыковка с различным программным обеспечением.

В следующий раз займёмся подключением контроллера к платформе OpenHAB.

Test Example Code

by Phillip Burgess

We have example code ready to go for these displays. It’s compatible with the Arduino Uno or Mega…but not other boards like the Leonardo, nor “Arduino-like” boards such as Netduino…programming gurus might be able to port it to other microcontrollers by adapting the C++ source, but as written it does some pretty low-level, non-portable things.

Continue reading »

LED панели, контроллеры, или как сделать светодиодный экран, часть 1

Continue reading »

https://bitbucket.org/jpcgt/flatcam/wiki/Cutting_the_edges_of_rectangular,_polygonal_or_round_shaped_boards

• Byte to Int

  Читаем Serial и записываем в int
  Получение целого однозначного числа(1..9)

Continue reading »

Continue reading »

Шаг 1. Создание векторного изображения из простой/растровой картинки
Обращаем внимание, что векторизация растровой картинки дает не точную копию, а набор кривых, с которыми нужно работать дальше.

Continue reading »

Цветные графические сенсорные дисплеи Nextion

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

Continue reading »

Излучатель ИУТ 0,88-4.01ф Медтеко

Continue reading »

Contents

• Пример простой программы на Си для микроконтроллера AVR
• Общая структура памяти программы на Си
• Типы данных в Си
• Операции и операторы
• Указатели и ссылки в Си
• Операторы управления программой
• Общая структура программы на Си и функция main()
• Функции пользователя
• Массивы в Си
• Структуры, объединения, перечисления
• Препроцессор, ди⁠рективы
• Ввод/вывод в C

Continue reading »

Более чем 80 средств мониторинга системы Linux

• Блог компании ua-hosting.company

Ниже будет приведен список инструментов мониторинга. Есть как минимум 80 способов, с помощью которых ваша машинка будет под контролем.

Continue reading »