Проект инфо-панели оповещения об авариях (Часть 1)

Вместо Intro


История создания проекта могла бы и не начаться, если бы не одно непритяное «Но» — в отделе имеется оборудование, которое должно работать бесперебойно, в режиме 24/7/365 (круглосуточно, без выходных, всегда) — собственно, это аппратные станции (оптические мультиплексоры, SDH-оборудование) и сервера SIP телефонии (а так же Call центр, но об этом нам сообщают сами операторы, их очень хорошо обучили реагировать на малейшие сбои).
Само оборудование находится в серверной, удалённой от кабинета, и достаточно зашумлённой (50-80db внутри — это норма, даже говорить приходится на повышенных тонах, т.к. иначе просто не слышно собеседника уже в полу метре).
В случае любых сбоев оборудования, необходимо их быстро устранять (сбои могут возникать как с нашей стороны, так и со стороны присоединённых операторов, а так же по независимым причинам, например, обрыв оптики, перегрузка на линии, прочие потери данных), в связи с чем требуется постоянно сделить за показателями работоспособности.
Меры принимаются, но ранее это происходило с некоторой задержкой в виду отсутствия возможности контроля.
Визуальный контроль за оборудованием возможен (индикация предупреждений и аварий предусмортена), но для этого требуется быть рядом с оборуддованием, что постоянно не представляется возможным.

Заинтересовавшихся прошу под кат. (Осторожно, трафик ~10-15МБ фото)

Содержание


Часть 2

Для тех, кому не интересна предыстория, можно её смело пропустить, и перейти к основной идее поста.

Преамбула


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

Первым вариантом стал комплекс их:
  • Виртуального сервера (ubuntu 11.04, 512MB RAM, NoGUI).
  • Скриптов на том же сервере (написаны на Perl).
  • Устройства оповещения типа «Мигалка».


Аппаратные характеристики текущего (работающего) устройства оповещения:
ATMega48 + Арлан 9000 + светодиодная лента (1 секотр) 12V + IRLML2402 в качестве ключа.
Устройство работает в режиме ожидания байта на USART, отправляет этот же байт эхом обратно, и проверяет, что именно пришло.
Если «1» — разрешает работу прерывания таймера (срабатывает около раза в секунду, перебрасывает пин, управляющий ключом-MOSTFET'ом).
Если «0» — запрещает его работу.
В обоих случаях, после выхода из прерывания, MCU продолжает ожидать байтов от USART.
Питается от 12V с самым простым стабилизатором КР142ЕН5А (5V на выходе, чего более чем достаточно для питания MCU и срабатывания низковольтного IRF-ключа).

В серверной части всё даже проще. CRON запускает каждую минуту скрипт (даже не скрипт, скорее цикл запуска самого скрипта и паузы ожидания), таким образом, чтобы интерпретатор запускался каждые 10 секунд. Устройств мало, потому можно решить данную задачу в лоб.
Скрипт последовательно проверяет состояния устройст SNMP запросами, запоминая состояния. Если хоть где-то возвращается статус аварии, происходит передача символа «1» на исполнительное устройство. Если везде всё хорошо — передаётся «0».
Всё работает, но не сказать, что удобно — неизвестно, ЧТО себя плохо чувствует.

[/Предыстория]
Теперь основная часть.

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

Суть устройства:
MCU: ATMega1284p (выбрал то, что имелось в наличии, буквально на руках), кварц на 18.432MHz /RAM: 16kB, Flash: 128kB, EEPROM: 4kB, USART/;
Ethernet модуль: ENC28J60; /Исходники библиотеки и описание работы с модулем здесь/
Индикация: 20 модулей 8x8 LED DOT Matrix (приобретены на E-Bay);
Звук: Пьезоизлучатель, DAC 8bit R-2R на резисторах, частота сэмплирования будет ~22kHz, Однотональные сигналы;
Дополнительная переферия: Термомерты DS12B20;
Питание: \В настоящий момент под вопросом, поскольку не хочется лишних проводов к устройству, и есть желание собрать его по схеме POE, но готовый модуль не выдержит 48V, потому, вероятно, будет использован 12V БП в качестве POE-адаптера\
В качестве внутреннего источника питания, и стабилизатора, используется модуль Step-Down DC-DC Converter на LM2596 (с того же E-Bay);
Отладка: UART в режиме RS232 (на скорости 115200), включается только при старте MCU, если есть потенциал на заданном пине MCU, иначе не включен и почти не потребляет системных ресурсов;

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

Готовое устройство будет иметь размер видимой области 20х400мм (1 строка на 20 модулей), в дальнейшем может стать двустрочным, или увеличит шрифт (вероятнее первое).
Планируется работа в сети Ethernet (полностью самостоятельная).
Организация работы в сети Ethernet происходит через модуль ENC28J60 (особая благодарность пользователю easyelexnronix, Lifelover за драйвер модуля, а так же примеры работы с ним).
Планируется возможность звуковых оповещений (наличие и необходимость звукового сигнала управляется сервером), а так же возможность воспроизведения потокового звука (декодирование будет происходить так же, на стороне сервера; проблема с воспроизведением и малой процессорной мощностью, а так же полное отстутствие DMA, решается воспроизведением из кольцевого буфера); индикация текста — динамическая.

Итак, по порядку:
Ядро
От MCU требуется многозадачность, и одновременно жёсткое реальное время (для звука), потому была предпринята попытка использовать FreeRTOS, но после подсчётов накладных расходов, от такой затеи пришлось отказаться. Воспроизведение звука (относительно) высокого качества требует обработки данных на частоте в 22кГц (дабы не мучаться с ресемплированием звука), на переключение задач в таком режиме потребуется значительная часть ресурсов MCU. При стандартной частоте системных прерываний (100..1000Гц) звук PCM без DMA воспроизвести невозможно.

Звук
Обработка звука происходит по прерыванию таймера. То же прерывание, при отсутствии данных в буфере звука, будет самостоятельно отключать себя.
Однотональная пищалка будет подключена к выходам PWM-генератора, что не исключает возможности работы только одного пьезоизлучателя для оповещений.
Обработчик прерывания звука
ISR (TIMER3_COMPA_vect)
{
#ifdef STREAM_SOUND
	cli();					// Disable interrupts
	if (plaing_now)				// If now plaing..
	{
		snd_R++;			// Increase read position,
		bytes_remain--;			// and decrease bytes remain count
		if(snd_R >= MAX_SND_BUFFER-1)	// Then if ReadPos reaches EndOfBuffer
		{
			snd_R = 0;		// Reset it.
		};
		if(bytes_remain <= 0)		// And if it's NO bytes remains..
		{
			plaing_now = 0;		// Stop plaing
			DAC_PORT = 0;		// And set DAC to ZERO.
		};
		DAC_PORT = snd_buffer[snd_R];	// Set DAC Value to Buffer[Read];
	};
	if (!plaing_now) {			// If interrupt triggered, but NOT plaing now..
		TCCR0B &= (0xF8);		// Disabling timer.
		TCNT0 = 0;			// And Reset timer's value.
	};
	sei();					// Enable interrupts.
#endif
};
Прерывание таймера заставляет обработчик переместить указатель буфера на шаг вперёд, проверить, не переместился ли он при этом за конец буфера, если да — вернуть в начало, вычесть 1 из оставшихся байт в буфере, если 0 — остановить воспроизведение, отключить таймер и вывести тот же 0 на порт DAC, иначе — вывести на порт байт из буфера.


Индикатор
Реализация индикатора планируется на сдвиговых регистрах с защёлками 74HC595(драйвера столбцов + драйвер строк) + IRLML2402 в качестве драйвера строк (буфер).
Регистры используются в качестве драйвера столбцов, т.к. их токовая нагрузка позволяет запитать целую строку (8 точек) одновременно.
Данные строки будут постепенно проталкиваться через регистры по горизонтали, начиная с «правого» края, чтобы не заморачиваться с дополнительным буфером кадра, а полностью изображение выводиться построчно.
При этом, регистры имеют общую шину данных, но раздельные шины тактирования (+1 к сэкономленым пинам MCU).
Динамическая индикация на частоте 125Hz не должна восприниматься глазом как мерцание (имеется в виду общая частота регенерации), частота переключения линий составляет 1kHz (используется таймер, отсчитывающий милисекунды).
Благодаря наличию защёлок в регистрах, удастся полностью избежать мерцания при переключении строк (добавлю небольшую паузу в несколько тактов после перехода выходов регистров в Z-состояние, защёлкиванием новых данных и переходом к рабочему режиму).

Источник питания
Как уже оговаривалось, питание будет поступать из вне на модуль ENC28J60, т.к. его конструкция позволяет, снимать напряжение с 3 и 4 пар кабеля (они не замкнуты на корпус и ни к чему не подключены). Затем это напряжение будет поступать на DC-DC преобразователь и понижаться до 5V.
В настоящий момент стоит вопрос уровней напряжения:
Ядро нужно питать от 4.5-5V, т.к. иначе не гарантируется работа его на частоте выше 12MHz (допустима для 3.3V), но сетевой интерфейс обязательно питать от 3.3V, иначе чип сильно греется, и есть опасность его выхода из строя. Преобразователь в наличии только один, потому необходим доволнительный Low Drop 5V -> 3.3V на ток до 250mA, опять же, желательно импульсный с высоким КПД. В наличии, к сожалению, нет.

upd: Мне уже советуют собрать преобразователь на россыпи элементов и питать всё от нормального POE без ограничений в 12V. Вот только в данной схемотехнике мне пока не очень везло. Если что и начинало работать, то порой оно довольно эффектно сгорало.

Вероятно, будет добавлена поддержка RTC в конечный проект (DS1307). В том числе, постараюсь описать работу с NTP (будет некрасиво, но базовый функционал опишу).
За одно снова вспомню/выучу принципы обработки данных на разных уровнях OSI.

В настоящий момент имеется:
  • Частично собранная библиотека (сеть видится, осталось добить проверку наличия линка и обработчики данных… все… много..)
  • Ethernet модуль ENC28J60
  • Step-Down DC-DC Converter (LM2596)
  • Индикаторы (в разобранном виде) (20 шт)
  • MCU ATMega1284p на отладочной плате (выглядит довольно неряшливо, но она делелась для себя).
  • Пьезоизлучатель
  • Термометр DS18B20, переписанная почти с нуля библиотека. Базовый минимум функций: «Прочитать байт», «Запуск преобразования», «Считать Scratchpad».
  • RTC DS1307

Библиотека термометра будет переписана для оптимизации и исключения задержек в работе MCU при преобразовании. В настоящий момент, преобразование температуры заставляет замереть MCU на ~750мс, что создаёт очень неприятные паузы при работе с сетью, а так же звуком.

Немного фото
ENC28J60:

Step-Down DC-DC Converter (LM2596):

Сами модули:

Модуль в сборе + сзади распиновка и частично видна схема переходника.

Ссылка на сами LED-модули (не магазин), а так же пример управления ими здесь.

Отладочная плата + модуль в ней. Светит ГОРАЗДО ярче, чем на фото. Запитан от 5В без ограничительных резисторов. Зря-зря-зря… но работает же! Второй столбец питается через резистор-подтяжку, придерживающий 1-Wire для DS18B20 (левее):


Чего нет:
  • Дописанных библиотек
  • DMA а очень жаль.
  • Знакогенератор. (Допиливается)
  • Переходников для LED модулей (цоколёвка модулей просто ужасна, а для панели удобнее будет собирать их, когда ряд с одной стороны, а столбцы — с другой.


/Заказывать переходники оказалось коммерчески не выгодно. Цену на заводе заломили в размере 4000 (без НДС) за 40 штук. С НДС получаем почти 5k деревянных. Придётся оттачивать навыки работы с мини-дрелью и ЛУТа./

Матрица символов планируется 6х8, без оптимизаций шрифтов.
//A
{
0b00000000,
0b00100000,
0b01010000,
0b01010000,
0b10001000,
0b11111000,
0b10001000,
0b00000000,
}

Причём, на индикатор будут выведены только 6 старших битов, оставшиеся 2 будут пропущены.
Псевдографики пока не будет.
Вывода картинки из «сети» пока, вероятно, тоже. Но описать графический буфер недолго, можно сделать и анимации прямо с сервера.

Была идея купить Raspberry PI и написать скрипт поверх неё… но это не спортивно. Там система ARM-11, 512MB RAM, Linux… да там можно поднять сам сервер мониторинга!.. но вот реальное время в любой *nix системе — мягкое, а для вывода индикации требуется жёсткое.
Конечно, можно было сделать RPI + любой более простой контроллер типа ATMega48 (да, тоже есть в наличии), с обменом по SPI/UART и переферией поверх самого контроллера, но это тоже не спортивно.
Цель проекта ставилась для себя «Уложиться в малый бюджет и собрать устройство оповещения», потому выполняется именно так. Почти здоровый спортивный интерес.

Продолжение следует.
Share post

Similar posts

Comments 11

    0
    т.е. это все, чтоб сделать панель с выводом текста?
    для мониторинга?
    для этого давно придуманы СМС оповещалки.
    а на обычный монитор можно выводить только неисправное оборудование.
      0
      Странно, что не вижу своих комментариев… но ладно.
      Прошу прощения за столь долгий ответ.

      По порядку:
      Да, это для того, чтобы сделать панель с текстом (и звуковым оповещением).
      Понимаю, что СМС оповещения придуманы. Но в нашем случае админы (которые бы могли это сделать для нас) не хотят этого делать, ибо наше оборудование находится в серой подсети, а основные сервера, которые занимаются опросом статистики — в белой (внешней), и не могут собирать данные от нас. Плюс, они и так перегружены. А может, им просто лень это делать
      На обычный монитор можно выводить. Но для этого нужен отдельный ПК, который будет этим заниматься. Нам не дают. Да и надо же чем-то заняться в относительно свободное время. Плюс, попытка проверить свои навыки.
      А продолжение показывает, что это если не вызов, то способ потрепать себе нервы (ибо работа с фоторезистом идёт крайне плохо, в том числе из-за того, что есть в наличии).
      0
      Странное конечно решение. Регистры, с одной шиной данных но с разными защелками? Но ведь классика говорит что проще сделать один большой регистр сдвига у которого один вход синхронизации и один вход данных. Залить данные в него можно будет аппаратно через SPI с использованием DMA. Да, темболее существуют даже готовые микросхемы для управления матричными индикаторами, есть 8x8 но они относительно дорогие, а есть для матриц 16x24(или в конфигурации 8x32) точки — т.е. 6(4) матриц на одну м/с. и она поддерживает 4 уровня яркости каждой точки аппаратно.
      Так же имеются регистры сдвига со встроенными драйверами светодиодов, т.е. внешние резисторы становятся НЕНУЖНЫМИ а ток через диоды регулируется всего одним входом.
        0
        DMA — это хорошо, но в Меге его нет. А так — согласен полностью. Потому приходится изворачиваться с тем, что имеется.
        Про готовые чипы — тоже соглашусь. Но не водится у нас такого в городе. А если искать и заказывать, то пересылка, а так же сами чипы будут слишком высокой себестоимости. К несчастью, это так.
        А по регулировке яркости — то довольно легко можно реализовать посредством модуляции входа ~OE на регистрах, а соответствующие затворы транзисторов — подтянуть к неактивному уровню.
          0
          Там предусмотрена аналоговая регулировка яркости, т.е. тока через диоды — не нужны внешние резисторы. Этот вход играет роль переменного резистора на выходах регистра, они регулируются все сразу одной ручкой только с одним преимуществом — регулируешь ток а не сопротивление т.е. индикаторы не будут мерцать при нестабильном питании.

          Когда-то закупил штук 20 таких за 5$ а теперь их и вовсе в продаже нет, есть только 16-битные и довольно дорогие если не брать целую партию.

          для SPI в меге есть DMA на 8 бит. пока передаются эти 8 бит, можно готовить следующую порцию данных, никаких ногодрыгов занимающих полезные такты.
          Ну, получится один такой большой регистр на 256 бит к примеру — на 32 индикатора хватит. Если делать алгоритм вывода из RAM, то он скорей будет ждать окончания передачи чтобы следующую порцию передать, а в случае ногодрыга — плюс еще и время на выборку следующей порции и время на переключения.
            0
            По поводу ногодрыга понимаю. Потому уже некоторое время подумываю переписать на SPI/UART. Там по сути не слишком сложно — поставить дополнительный вентиль на провод данных. В данном случае — два… И на тактирование. Планировал изменить ближе к моменту сборки.
            А сам «ногодрыг» был скорее начальным тестом, а потом просто забыл изменить, ибо работает и так — каюсь.
            К тому же, этот процесс проходит более гладко, т.к. регистры могут не поспеть за SPI. Да и «экономия» времени будет очень и очень незаметной.
            2*9*8 = 144 бита передаются считанные микросекунды. Хотя, даже на 8МГц не заметно ни мерцаний, ни дребезга.

            \\ Что заметно на осциллографе — так это шум от ключей в момент переключения. Ток на всю строку до 2А (порядка 30мА/сегмент при допустимых по даташиту 80-ти), а нагрузка получается индуктивной… и это даёт довольно ощутимые всплески — местами до 1-2V.
              0
              Нет, нагрузка не индуктивная. Просто стабилизатор не успевает отрабатывать изменение нагрузки. Лечится очень просто — увеличением емкости выходного конденсатора, желательно емкость распределить и поставить блокировочные конденсаторы чуть ли не на каждый индикатор.
              Ведь представь, помимо всплесков по шинам питания, по ним же гуляют ВЧ-токи и все это сыплется в эфир.
              Чтобы сгладить импульсы от сканирующей частоты в 1000Гц нужна суммарная емкость 100мкф/1А — примерно по 1-5мкф на каждый индикатор было бы просто замечательно, только не электролиты.
                0
                В тот момент запитывал от литиевой ячейки 18650 (буквально только что заряженной). Напряжение в районе батареи — стабильное (достаточно), а вот непосредственно в районе «силовых» транзисторов, отвечающих за горизонтальные шины, напряжение гуляет довольно неплохо в момент переключения.
                В будущем преобразователе уже предусмотрел силовые дроссели и большое количество конденсаторов.
                Планирую поставить общую ёмкость в цепи 5V, затем данная цепь разделяется резисторами 0.1Ом на десять, в каждой стоит дроссель с максимальным током 600мА, затем собираются обратно в новую шину. Частота преобразования… думаю в пределах 40-80кГц… она уже будет подбираться экспериментально.
                Не собирал я преобразователи нормально… буду надеяться, что не сожгу.
                  0
                  Дроссели не нужны они только ухудшат ситуацию, только конденсаторы. И резисторы не нужны, дорожки и так уже имеют сопротивление — они только усугублят проблему. Дорожки шин пошире сделать, может даже напаять сверху проводочек для усиления сечения.
                  Не забывай что по каждой их них токи текут большие, хоть и импульсные.
                  Конденсаторы надо располагать так чтобы минимизировать контур распространения высокочастотных колебаний, считая конденсатор источником напряжения а остальную цепь контуром. Провода от преобразователя к индикаторам — потенциальная проблема, на них не должен замыкаться высокочастотный ток, конденсаторы должны быть ближе к ключам и индикаторам.
                  Есть одна замечательная книжка которую необходимо прочитать, как приду домой вспомню её название. Пытался найти в бумажном варианте — 300грн стоит и похоже жуткий дефицит.
                    0
                    «Конструирование высокоскоростных цифровых устройств. начальный курс черной магии» ISBN 5-8459-0807-8 (рус.)
                      0
                      Спасибо, попробую поискать.

        Only users with full accounts can post comments. Log in, please.