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

Основываясь на собственном скромном опыте, могу сказать, что прерывания далеко не самая освященная тема в сообществе Linux. Из-за своих особенностей, а так же сильной привязки к аппаратной части, все обучающие материалы посвященные прерываниям лишены реального и легко воспроизводимого примера. Данный факт мешает пониманию того, что очень часто прерывания и GPIO неразделимы, особенно в области встраиваемого Linux. Многие начинают верить, что GPIO это очень простая и скучная вещь (которая кстати и стала таковой благодаря подсистеме sysfs).

Предисловие

Недавно мною было замечено, что при просмотре мультикастового IPTV через Wi-Fi часть трафика теряется. После детального изучения проблемы было выяснено, что такое поведение объясняется природой мультикаст-трафика, а именно – MAC-адрес получателя пакета. Он не зависит от получателя и формируется из адреса мультикаст-группы. Соответственно, на такие пакеты претендуют все клиенты, подключенные к беспроводной точке доступа. Вследствие этого нам достается лишь часть пакетов и мы видим обрывистую картинку.

Штатными средствами проблема решается либо созданием отдельной точки доступа для клиента, либо созданием статического маршрута для определенных мультикаст-групп, или же выведением клиента в отдельный VLAN. Вся “сила” таких решений проявится, когда в сети будет несколько IPTV-приставок, желающих посмотреть один и тот же канал, плюс необходимость их в интернете добавит сложность к настройке роутера. Свое решение данной проблемы предлагаю ниже.

Думаю, что каждый пользователь хабра, знает, что такое LAMP. Но для меня LAMP это не просто комплект (стэк) ОС Linux + Apache HTTP Server + MariaDB/MySQL + PHP/Python/Perl. Для меня это символ того, что открытое ПО может (и должно) быть причиной революционных изменений в ИТ-отрасли. Я уверен, что именно благодаря LAMP, появился интернет в его сегодняшнем виде. Без того, что скрывается за этими четырьмя буквами, не было бы Google, Facebook,… да и Habrahabr. Ну, по крайней мере, не было бы такими, какими мы их знаем. Только представьте себе, технологии, с помощью которых стало возможно создать компанию с самой большой капитализацией в мире, появились всего-лишь 20-25 лет назад! Когда я писал свой пост "Почему Citrix не стала «новой Red Hat» на рынке виртуализации?", я задумался о том, что серверная виртуализация могла бы стать ещё одной областью ИТ-технологий, где открытое ПО играет ключевую роль. К сожалению, этого (пока?) не произошло, однако OpenStack, вероятно, сможет избежать ошибок, и стать стандартом де-факто для ЦОД. Или нет? Опрос после поста.

Друзья, публикуем выступление Василия Толстого — ведущего инженера Санкт-Петербургского центра разработок EMC с конференции CEE-SECR 2015.

Тема доклада: «Кооперативная виртуализация сети в промышленных серверных приложениях на Линуксе»

Описание доклада: «Обычно сервер делают виртуальным, создавая для каждой его копии индивидуальное виртуальное окружение. Но в некоторых случаях важно сохранить классическую структуру сервера — с одной копией ОС и одним основным процессом, и здесь требуется существенная адаптация системы и приложения. В докладе рассказывается, как это можно сделать в современном Линуксe».



Слайды презентации можно посмотреть здесь.

Для подписчиков Windows Insider Program (Fast builds only, судя по всему) наконец-то стала доступна долгожданная сборка 14316, первая после Build 2016 и включающая в себя тот самый Bash, а если точнее, то «Bash on Ubuntu on Windows», который является обычным bash'ем в составе самой настоящей (не виртуализированной) Ubuntu 14.04 (собственно ее Microsoft называют «Ubuntu on Windows» [иногда сокращая до «uow»]), которая сожительствует с Windows 10 с помощью beta-версии компоненты «Windows Subsystem for Linux», транслирующей вызовы одной вселенной в другую.



Надо сразу отметить, что стеснительные Microsoft форсируют новомодную пепяку именно под названием Bash, хотя на самом деле это весь user-mode *nix софт (в ближайшем будущем точно).

• Часть 1 (Аппаратная)
• Часть 2 (Серверная)
  
  • Драйвер
  • Демон
  • Утилита управления

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

В этой части статьи будет рассмотрено как взаимодействовать с последовательным портом из пространства ядра (kernel space) и как организовать работу с несколькими подсистемами устройства через RS232 в Linux.

Устройство включает в себя следующие подсистемы:

• Аппаратный сторожевой таймер, работающий с watchdog демоном;
• Генератор истинно случайных чисел;
• Радиомодуль nRF24L01+ для сбора данных с автономных датчиков.

В 2012 году Эндрю Мортон был пессимистично настроен в отношении будущего проекта CRIU (Checkpoint and Restore In Userspace), когда принимал первые изменения в Linux ядро для поддержки C/R (Checkpoint/Restore). Идея реализовать функциональность сохранения и восстановления запущенных процессов в пространстве пользователя выглядела сумасшедшей, а спустя 4 года проект не только жив, а всё больше вызывает интерес к себе. До старта проекта CRIU предпринимались попытки реализовать C/R в Linux (DMTCP, BLCR, OpenVZ, CKPT и т.д.), но и все они по разным причинам были обречены на провал в то время как CRIU стал жизнеспособным проектом. К сожалению от этого задача C/R в Linux не стала проще. В этой статье я расскажу об особенностях тестирования CRIU.

Всем привет!
В одной из предыдущих статей мой коллега Des333 реализовал фреймбуфер для LCD, работающего на графическом контроллере ILI9341. Однако, его написание потребовало существенного опыта в разработке RTL-кода.

К тому же, не у каждого под рукой есть embedded LCD-дисплей, зато наверняка есть монитор с VGA-входом.Что же делать, если опыта разработки под FPGA мало, но есть SoC, а сделать что-то интересное хочется?

В этой статье мы расскажем, как разработать графический контроллер, имея на руках плату с SoC (Altera Cyclone V), дисплей с VGA и минимальные знания языков HDL (в нашем случае — Verilog).

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

Здравствуйте, уважаемые читатели! С наступающими вас праздниками.

В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:



Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.

В процессе работы над ОС Фантом, которая вообще не Юникс никаким местом, мне, тем не менее, захотелось сделать в нём Unix-compatible подсистему. Не то, чтобы прямо POSIX, но что-то достаточно близкое. Отчасти из любопытства, отчасти для удобства, отчасти как ещё один migration path. (Ну и вообще было интересно, насколько трудно написать простенький Юникс «из головы».) В качестве цели номер 1 была поставлена задача запустить quake 1 for Unix, которая и была достигнута.

В процессе, естественно, появились open/close/r/w/ioctl, и появилось ощущение, что последний неприлично, постыдно устарел. В качестве упражнения для размятия мозга я реализовал (в дополнение к обычному ioctl) некоторый альтернативный API, который бы позволил управлять свойствами устройств более гибким и удобным с точки зрения пользователя способом. Этот API, конечно, имеет свои очевидны минусы, и, в целом, эта статья — RFC, aka request For Comments.

Итак, API на уровне пользователя:

// returns name of property with sequential number nProperty, or error
errno_t listproperties( int fd, int nProperty, char *buf, int buflen );

errno_t getproperty( int fd, const char *pName, char *buf, int buflen );
errno_t setproperty( int fd, const char *pName, const char *pValue );

Правила:

1. Никаких дефайнов с номерами, только имена.
2. Никаких бинарных данных, только строки

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

В последнее время много разговоров идет о том, что для C++ нужен свой пакетный менеджер подобный pip, npm, maven, cargo и т.д. Все конкуренты имеют простой и стандартизированный механизм подключения нестандартной библиотеки. В C++ же все действуют как умеют: кто-то прописывает в README список пакетов для Ubuntu, CentOS и других дистрибутивов, кто-то использует git submodule и скрипты для их сборки, кто-то использует CMake ExternalProject, кто-то копирует все исходники в один гигантский репозиторий, кто-то делает образ Docker или Vagrant.

Чтобы решить проблему был даже создан стартап — biicode, но он обанкротился и его будущее неизвестно. Взамен появился conan, дополняя зоопарк конкурентов — nuget, cget, hunter, cpm, qpm, cppget, pacm и даже gradle for c++.

Меня не устраивал ни один из перечисленных способов. Я было начал писать пакеты для Conan, но столкнулся с большим числом хаков, неразвитым API, отсутвием гайдлайнов и, как следствие, низкой вероятностью переиспользования чужих пакетов. И тут вспомнилось, что когда-то мне очень понравились идеи пакетного менеджера в NixOS. И подумал — а зачем плодить пакетный менеджер специально для C++, если те же задачи решает обычный пакетный менеджер? Нужно только чтобы он был достаточно гибким и простым в части описания пакета. И Nix идеально подошел на эту роль.

Всем доброго дня!

На прошлой неделе завершилась конференция Build 2016, на которой были представлены главные новости для разработчиков от компании Microsoft.

В их числе и выпуск Visual Studio 2015 Update 2, который уже можно скачать и установить себе на компьютер, а также превью следующей версии инструмента:

• Ссылка на Visual Studio Update 2
• Ссылка на Visual Studio “15” Preview

Разберемся, какие нововведения ожидают разработчиков с Visual Studio 2015 Update 2. Начнем с новостей для разработки на C# и Visual Basic.

Сейчас понятие «бесплатно» в интернете имеет весьма размытые черты: пользуясь бесплатными сервисами вы либо предоставляете свои персональные данные для обработки и показа рекламы, либо смотрите эту самую рекламу по выбору владельцев ресурса или ПО. Часто бесплатные версии обладают ограниченным функционалом, что накладывает существенные ограничения на разработчика.

Однако, парни из Red Hat решили в очередной раз напомнить миру, что «бесплатное» должно быть «бесплатным» без дополнительных условий и приписок мелким шрифтом в стиле «вы обязаны смотреть нашу рекламу каждое полнолуние». Поэтому теперь продукт «Red Hat Enterprise Linux» для разработчиков распространяется по системе «no cost»-подписки, о чем сообщается в пресс-релизе на официальном сайте компании.

Если вы следили за новостями о последних разработках в области инструментов анализа C/C++ кода, то, должно быть, слышали про инструмент PVS-Studio. Я узнал о нем благодаря статьям, которые разработчики публикуют на своем сайте и в которых они рассказывают о проверках проектов с открытым кодом. К настоящему времени уже проверено внушительное число проектов, включая ядро Linux, Qt, Unreal и т.д., и каждый раз им удается находить интересные ошибки, подолгу живущие в коде, никем не обнаруженные. Опечатки, неаккуратное копирование, неопределенное поведение, бессмысленный код, синтаксические ошибки, которые чудесным образом пропускаются компилятором…

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

Пришла весна. Коты думаю о кошках, мужчины о женщинах, а программист — куда бы ещё портировать имеющийся код. Я ещё прошлой осенью стал обладателем Meizu MX4 Ubuntu Edition, и поэтому выбор был давно очевиден. А тут нашлось и время, и силы.

Сегодня мы расскажем об успешно реализованном проекте для крупного немецкого производителя телекоммуникационного оборудования (хабы, роутеры, сетевые серверы и пр.)

Задача

Embedded Debian не предоставляет готовой к использованию среды для сборки произвольных образов системы. Чтобы ее подготовить, требуется использовать стандартный дистрибутив Debian, обладать навыками системного администрирования, подобрать и настроить набор утилит, написав при этом ряд shell скриптов для автоматизации процедуры кросс-компиляции пакетов. Проделав всю ручную работу, вы получите консольный инструмент, пользоваться которым может исключительно технический персонал с определенным уровнем навыков работы с ОС Linux, а это не удобно, встает вопрос по организации многопользовательского доступа к этой среде и ограничению прав, а также постоянной поддержки среды в актуальном состоянии.

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

В век «онлайна», печатная фотография стала больше походить на диковинку, как это было раньше с фотографией цифровой. В последнее время, различного рода фотобудки, стали набирать популярность, как интересный способ развлечь гостей и получить памятный сувенир в виде фотографии. Я фотограф, который увлекается программированием, и при этом сочетании, было бы странно не попробовать сделать себе фотобудку.
В отличии от коммерческих моделей фотобудок, которые есть в продаже, мне хотелось сделать действительно компактную и автономную систему. Чтоб я параллельно основной работе, мог за пару минут ее установить хоть в поле и не таскать с собой лишние десятки килограмм веса. И у меня это получилось.
Под катом будет рассказ о железе, raspberry pi и программировании всего этого под linuх и конечно же мой любимый python. Забегая вперед, скажу, что мне хотелось именно качественных фотографий, поэтому съемка ведется не на веб камеру, а на DSLR, поэтому статья должна получиться еще больше и интересней.

Вступление к серии

Передо мной недавно встала задача, как распространять одну консольную утилиту? Обычные мои инструменты вроде pip, npm и gem не подходили в силу языка самой утилиты — bash. Тогда стало понятно, что нужно распространять свое приложение в том числе и через системные пакетные менеджеры. Для Mac — в силу отсутствия встроенного — таких пакетных менеджеров несколько. И у каждого из них есть свои особенности и недостатки. И в первой части я хочу более подробно остановиться на Homebrew, и как создавать пакеты для него.

Ну а чтобы установить приложения на Linux, то нужно будет собирать пакеты таких форматов: .tar.gz, .deb и .rpm. О чем я расскажу во второй части.

Приветствую хабровчане!

Вот уже пол года как мой основной Desktop работает на Ubuntu, о плюсах и минусах Linux писать не буду, пост не об этом.
Так вот… я к сожалению не владею слепым методом набора текста, да и не было смысла обучаться так как в окнах меня вполне сносно спасала программа PuntoSwitcher которой пользовался около 5-ти лет, однако её аналог Xneur на Ubuntu мягко говоря работал «не очень» и вовсе не работал в Skype.

Некоторое время я мирился с этим, потом пробовал безуспешно написать небольшую программку на Java.

Требования к программе:

1. Быстрый запуск
2. Иконка в трее для выхода из приложения и отмены конвертации
3. Конвертация по глобальной комбинации клавиш

— это тот функционал которым я и пользовался в PuntoSwitcher.