Блог компании спецпромдизайн

Ряд наших устройств имеет встроенный порт RS-232 для считывания данных с источников бесперебойного питания (ИБП) по двум наиболее распространённым протоколам обмена Megatec и Voltronic. Для облегчения тестирования устройств мы разработали небольшую программу-эмулятор. Именно о ней дальше и пойдёт речь.

Протоколы Megatec и Voltronic текстовые и довольно простые. Обмен данными ведётся на низкой скорости 2400 бит/сек, 8 бит данных, без контроля чётности по принципу запрос-ответ. Запросы представляют собой текстовые строки длиной от одного до трёх символов, оканчивающихся байтом перевода строки (код 0x0D). Ответы приходят также в текстовом виде с завершающим символом 0x0D. Значения в ответах разделяются пробелами. Числа могут передаваться либо с незначащими нулями в начале, либо с дополнительными пробелами.

В зависимости от конкретного ИБП таких команд может быть разное количество, но основную информацию можно получить при помощи четырёх из них. Рассмотрим их подробнее.

Q1 запрос текущего состояния
Ответ ИБП:
(MMM.M NNN.N PPP.P QQQ RR.R S.SS TT.T b7b6b5b4b3b2b1b0
( начальный символ.
MMM.M входное напряжение, В.
NNN.N напряжение, при котором последний раз был осуществлён переход на работу от батареи, В.
PPP.P выходное напряжение, В.
QQQ потребляемая мощность, %.
RR.R частота сети, Гц.
SS.S напряжение на батарее, В. Оно может передаваться в двух форматах: SS.S для линейно-интерактивных ИБП или S.SS для онлайн-ИБП (указывается напряжение на одном элементе).
TT.T температура ИБП, C.
b7...b0 статусные биты, которые могут принимать значение 0 или 1.
b7 1 : работа от АКБ, 0 : работа от сети.
b6 1 : низкий уровень заряда АКБ, 0 : АКБ в норме.
b5 1 : байпас включён, 0 : байпас выключен (только для онлайн-ИБП).
b4 1 : авария ИБП, 0 : ИБП в норме.
b3 1 : линейно-интерактивный ИБП, 0 : онлайн-ИБП.
b2 1 : запущен тест ИБП.
b1 1 : ИБП выключен, 0 : ИБП включён.
b0 1 : звуковой сигнал включён, 0 : выключен.

I запрос информации об ИБП
Ответ ИБП:
#CompanyName Model Version
# начальный символ.
CompanyName производитель ИБП.
Model название модели.
Version версия ИБП.

F запрос информации о номинальных параметрах ИБП
Ответ ИБП:
#MMM.M QQQ SS.SS RR.R
# начальный символ.
MMM.M номинальное выходное напряжение, В.
QQQ номинальный выходной ток, А.
SS.SS номинальное напряжение АКБ, В (может быть в форматах SS.SS или SSS.S).
RR.R номинальная частота выходного напряжения, Гц.

QBV запрос информации об АКБ
Ответ ИБП:
(RRR.R NN MM CCC TTT
( начальный символ.
RRR.R номинальное напряжение АКБ, В.
NN количество батарей в АКБ, шт.
MM количество параллельных групп батарей, шт.
CCC ёмкость АКБ, %.
TTT оставшееся время работы от АКБ, мин.

Помимо команд, которые считывают какие-либо параметры ИБП, есть ещё управляющие команды. Часто используются такие:
T запуск теста АКБ на 10 сек.
TL запуск теста АКБ до полного разряда.
T<n> запуск теста АКБ на заданное количество минут.
CT остановка теста АКБ.
Q включение/отключение звукового сигнала ИБП.

На первый взгляд вышеописанные команды очень простые, но дьявол, как обычно, кроется в мелочах. Например, некоторые ИБП вообще не выдают ответы на команды I и QBV. Примером может служить ряд моделей от Ippon.

Также замечено, что различные ИБП выполняют команду Q (управление звуковым сигналом) за совершенно разное время. То есть от момента выдачи команды Q и до момента смены бита b0 в ответе на команду Q1 может пройти до 30 сек!!! А так как включение и выключение осуществляется одной командой, то при автоматизированном управлении может начаться колебательный процесс. Например, контроллеру через Web-интерфейс задаётся выключенное состояние звукового сигнала. Он анализирует текущее состояние ИБП (по флагу b0), и если оно отличается от нужного, то подаёт команду Q. При следующем запросе Q1 контроллер опять проверяет флаг b0 и видит, что он не поменялся. В результате он опять подаёт команду Q. Но ИБП всё это время на самом деле что-то там у себя внутри обдумывал, поэтому не сразу среагировал на первую Q, а тут уже пришла и вторая. В результате звуковой сигнал может остаться включённым. И, более того, в некоторых ИБП при смене статуса звукового сигнала осуществляется короткий бип. А из-за такого колебательного процесса эти бипы могут издаваться много раз, пока наконец контроллер и ИБП не синхронизируются.

Мы решили эту проблему просто смену состояния звукового сигнала проводим только раз в минуту. За это время у ИБП внутри уже всё устаканится.

Ещё один интересный момент заключается в расчёте оставшейся ёмкости АКБ. Считается она по упрощённой формуле:

Здесь:
U текущее напряжение АКБ.
U_min минимально допустимое напряжение на АКБ (обычно около 10В).
U_max напряжение заряженной АКБ (обычно 13,8...14,2В).

Этого обычно достаточно для оценки оставшегося заряда.

Протокол Voltronic на множестве указанных выше команд отличается только одной из них вместо кода Q1 используется QS. При этом форматы ответов совпадают. В наших устройствах реализовано автоматическое определение протокола обмена как раз на основе данного отличия. Контроллер при включении пробует посылать по очереди команды Q1 и QS. На какую приходит ответ, тот протокол дальше и используется. Если в течение определённого тайм-аута на команду перестают приходить ответы (был подключён другой ИБП на горячую), то определение протокола автоматически запускается заново.

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

Она представляет из себя экран с настройками и выбором COM-порта, через который будет осуществляться обмен. Поддерживаются все указанные выше команды, в том числе и для запуска тестов:

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

Для оценки работы программы в динамике я записал небольшое видео:

Саму программу эмулятора можно скачать здесь.

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

Одно время мы выпускали несложный контроллер облачной СКУД на 100 пользователей. В его основе лежал микроконтроллер PIC18F46K22. В качестве памяти для хранения кодов ключей пользователей использовалась FLASH-память с интерфейсом I^₂C ёмкостью 64 кБ. Сама флешка довольно быстрая, но на шине I²C находилась ещё микросхема часов DS1307, которая работает на скорости не выше 100 кбит/сек. Высокой скорости работы нам не требовалось, поэтому в итоге вся шина была запущена на частоте 100 кГц.

Однако со временем мы начали разрабатывать новую версию контроллера, поддерживающего уже 3000 пользователей. Не хотелось сильно менять архитектуру, поэтому основные узлы были сохранены, но при этом был увеличен объём FLASH-памяти до 256 кБ.

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

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

Но есть и другой способ программный. Заключается он в переделке самой процедуры поиска. Изначально она выглядела так:

typedef struct{    uint32_t COD;    uint8_t nSchedule;} TSKUD_User;bool skudFindUserByCode(uint32_t pCOD){  TSKUD_User user;  for (uint8_t i = 0; i < SKUD_USERS_COUNT; i++)  {    skudReadUser(i, &user);    if (user.COD == pCOD)      return 1;  }  return 0;}

Функция skudReadUser считывала блок данных из I²C памяти, далее осуществлялась проверка на совпадение кода.

При ста пользователях в худшей случае (когда код находился в самом конце массива данных) время поиска занимало порядка 0,1 сек. При переходе же к 3000 пользователей время выросло 3 сек!

Поэтому для ускорения функция была переписана следующим образом:

bool skudFindUserByCode(uint32_t pCOD){  TSKUD_User user;  int16_t m, beg, end;  beg = 0;  end = SKUD_USERS_COUNT - 1;  while (beg <= end)  {    m = (beg + end) / 2;    skudReadUser(m, &user);    if (pCOD == user.COD)      return true;    if ((pCOD < user.COD) || (user.COD == 0))      end = m - 1;    else      beg = m + 1;  }  return false;}

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

О различных частных случаях при реализации бинарного поиска можно почитать в статье:Я не могу написать бинарный поиск (http://personeltest.ru/aways/habr.com/ru/post/146228).

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

1. Если значения совпадают, то мы нашли нужный ключ и можно открывать замок.

2. Если номер искомой карты меньше, то следует его искать в левой части массива. Тут мы отбрасываем сразу половину заведомо не подходящих вариантов. Индекс end теперь будет равен m 1.

3. Если номер искомой карты меньше, то следует его искать в правой части массива. Так же отбрасываем сразу половину заведомо не подходящих вариантов, но меняем индекс beg (он будет равен m + 1).

Если в массиве данных вообще нет искомого значения ключа, то нам нужно выйти из цикла. Условием выхода является beg > end.

Очень важным является дополнительное условие user.COD == 0 в строке:

    if ((pCOD < user.COD) || (user.COD == 0))

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

Можно было бы записывать туда значения 0xFFFFFFFF, но его мы используем в качестве сервисного для служебных нужд системы. Поэтому дополнительное условие user.COD== 0 всегда заставляет алгоритм искать код в левой половине массива данных.

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

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

А вот при бинарном поиске количество сравнений будет составлять log₂3000 11 шт!

Интересно, что если записей будет аж 4 миллиарда, то количество сравнений при использовании бинарного поиска увеличится всего лишь до 32!

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

В итоге мы за 11 итераций нашли искомое значение. Важно понимать, что 11 итераций это максимальное время поиска. В вышеприведённом примере в случае, если бы мы искали значение 2290467, то количество итераций было бы равно 9.

Так в чём преимущество такого решения? В начале статьи я указывал, что алгоритм реализовывался на микроконтроллере. Использование крайне дешёвой памяти с интерфейсом I^₂C снижает общую себестоимость изделия, а новый алгоритм поиска сильно уменьшает время реакции контроллера.

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

Вот работа линейного поиска:

А вот бинарного:

Результат, как говориться, на лицо!