Если вы спросите у прожжённых системных администраторов, используют ли они realtime‑конфигурацию в Asterisk, с вероятностью 90% ответ будет отрицательный. В качестве обоснования, скорее всего, услышите «При недоступности источников данных телефония станет неработоспособной». Если интересно узнать, как мы обошли это ограничение, читайте дальше.
Искал я как-то себе дешевый VPS сервер. Ну для отладки чего-нибудь, моделирования сетей... Да мало ли еще для чего может понадобится личный сервер? И вот в результатах поиска всплыло, что Oracle предоставляет возможность получить бесплатно и "пожизненно" до двух виртуальных машин (Oracle Cloud Infrastructure Compute). А также еще кое-какие вкусняшки. Зарегистрировался, получил - действительно выдают, действительно работает, и действительно бесплатно. Но хочется же подключить полученные машинки в свою сеть! И, желательно, штатными средствами. Вот из экспериментов и получились две статьи, может быть кому-то они сэкономят часа четыре рабочего времени.
Наконец-то у меня дошли руки до изучения ПЛИС. А то как-то неправильно получается: драйвера на железо под Linux пишу, микроконтроллеры программирую, схемы читаю (и немного проектирую), надо расти дальше.
Так как мигать светодиодами мне показалось не интересно, то решил сделать простенькую вещь. А именно написать модули приемника и передатчика для UART, объединить их внутри FPGA (заодно понять как использовать IP Core), ну и протестировать это все на реальном железе.
Подразумевается, что мы будем писать прошивку под «голое железо». В противном случае применение protothreads смысла не имеет, т.к. мультизадачность должна обеспечиваться средствами ОС. Подразумевается также, что нам необходимо реализовать несколько более-менее сложных алгоритмов, связанных с операциями ввода-вывода. Ну и, как всегда в микроконтроллерах, очевидные требования по экономии RAM и энергопотребления.
В предыдущей статье был представлен вариант реализации примитивов для асинхронной работы с шиной 1-wire для микроконтроллеров Atmel. Ну а сейчас вашему вниманию предлагается реализацию того же самого, но на более мощных микроконтроллерах семейства STM8L (для отладки использовалась обычная оценочная плата STM8L-Discovery с извлеченным LCD-дисплеем). С минимальными изменениями описываемая реализация может быть адаптирована и для семейства STM32.
В семействе STM8 заложена очень полезная возможность экономии энергии в случае, когда быстрые и критичные ко времени обработки выполняются по прерываниям, а низкоприоритетные задачи работают в фоновом режиме. Для этого используется бит AL в регистре GCR и машинная команда WFI. Однако здесь был обнаружен подводный камень, не описанный в текущей версии errata на кристалл.
Предлагаемый Вашему вниманию драйвер шины 1-Wire не является чем-то революционным, все использованные схемотехнические решения давно известны. Причиной публикации стало желание не загромождать статью о программной реализации примитивов 1-Wire-master на основе PWM и ICP.
Если кто-нибудь использовал linux-драйвер шины 1-Wire на основе GPIO, то наверняка замечал, что в момент выполнения обмена данными загрузка SY% подскакивает чуть ли не до ста 100% (что вполне логично для bitbang-реализации). Конечно, можно поставить специализированный контроллер шины 1-Wire с подключением через I2C DS28E17 или использовать UART, но… Все-таки использовать linux для приложений реального времени не лучшая идея. Пусть контроллер на нем занимается высокоуровневой логикой, а весь реалтайм можно вынести на отдельный процессор. Тем более, что задач для этого отдельного процессора в моем проекте более чем достаточно.
Поигравшись с разнообразными решениями IPv6 на стендах и оценив все их прелести, задумался я как-то и над коммерческой эксплуатацией. Конечно, в виде dual stack, а не как «IPv6-only».
Саму методику оценки было решено разделить на 2 части: использование IPv6 при реализации сервисов и использование IPv6 конечными пользователями. Над большими проектами эксперементировать, естественно, не стал. А вот результатом исследования мелочевки готов поделиться с сообществом.
Двухэтажный таунхаус, предназначенный для круглогодичного проживания
Централизованное электроснабжение (как всегда в загородных домах, очень нестабильное)
Централизованное холодное водоснабжение
Централизованное газоснабжение
Газовый отопительный котел Protherm Gepard
Что хотим получить
Возможность удаленного мониторинга микроклимата в доме (чтобы на душе было спокойно в случае долгого отсутствия)
Возможность удаленного управления этим самым микроклиматом (уменьшить температуру обогрева с целью экономии газа, увеличить температуру перед возвращением домой)
Возможность удаленного снятия показаний счетчиков ресурсов, подлежащих оплате (счетчика расчета газа, воды и электроэнергии)
Стоимость устанавливаемого оборудования должна быть экономичная
Стоимость эксплуатации системы должна быть минимальная
В процессе автоматизации домашнего хозяйства было обнаружено, что имеющийся в наличии счетчик расхода газа ВК-G4 обладает интересной особенностью: его в младший разряд встроен магнит, который может замыкать геркон, устанавливаемый снаружи самого устройства (т.е. для его подключения не требуется разрешения от газовой компании). Это даже указано в паспорте на сам счетчик. Правда там рекомендуется использовать «НЧ генератор импульсов IN-Z 61», но на самом деле это просто геркон с креплением на счетчик за невменяемую цену. Поэтому вместо IN-Z 61 было решено использовать самый дешевый датчик Холла с цифровым выходом (т.е. со встроенным триггером Шмитта).
Под термином “клиент” будем понимать зону ответственности за совокупность сетевых устройств.
Требуется обеспечить доступ для нескольких сотен клиентов к неким общим ресурсам в таком режиме, чтобы:
Каждый клиент не видел трафик остальных клиентов.
Неисправности одного клиента (broadcast-storm, конфликты IP-адресов, не санкционированные DHCP-сервера клиента и т.п.) не должны влиять на работу как других клиентов, так и всей системы в целом.
Каждый клиент не должен напрямую получать доступ к ресурсам других клиентов (хотя, как специальный случай, можно предусмотреть и разрешение данного трафика, но с его централизованным контролем и/или управлением ).
Клиенты должны иметь возможность получения доступа к общим внешним ресурсам (которыми могут быть как отдельные сервера, так и сеть Интернет в целом).
Общие ресурсы должны также иметь возможность доступа к ресурсам клиентов (конечно при условии, что известен общему ресурсу известен IP-адрес ресурса клиента).
Адресное пространство для клиентов выделяется централизованно и его администрирование не должно быть чрезмерно сложным.
В качестве примеров практического применения можно назвать изоляцию локальных сетей отделов в крупной организации, организацию VoIP-связи или доступа в сеть Интернет для нескольких независимых потребителей и т.п.
Java native library (JNL) представляет собой JAR-архив, содержащий в себе JNI-код и объекты, которые операционная система может загрузить в качестве разделяемых библиотек. Это позволяет вызывать из Java-приложения функции, реализованные платформо-зависимыми методами. Способы создания JNL — это тема отдельной большой статьи, поэтому считаем, что у вас уже есть JNL и вы хотите ею воспользоваться в своем приложении. Об особенностях использования JNL в приложениях, работающих под управлением сервера приложений, и будет эта статья.
