Создавать, запускать, просматривать, перемещать контейнеры и образы с помощью интерфейса командной строки Docker (Docker CLI) проще простого, но задумывались ли вы когда-нибудь, как на самом деле работают внутренние компоненты, обеспечивающие работу интерфейса Docker? За этим простым интерфейсом скрывается множество продвинутых технологий, и специально к старту нового потока курса по DevOps в этой статье мы рассмотрим одну из них — объединённую файловую систему, используемую во всех слоях контейнеров и образов. Маститым знатокам контейнеризации и оркестрации данный материал навряд ли откроет что-то новое, зато будет полезен тем, кто делает первые шаги в DevOps.

Продолжение предыдущей статьи, в которой мы ускорили разработку под embedded linux. Рабочая станция + sftp сервер + nfs сервер ускорили на порядок (10х) доставку изменений кода на целевое железо. Теперь не нужно часами компилировать код. В этой статье продолжаем очеловечивать разработку. На этот раз прикручиваем полноценную графическую IDE и пошаговую отладку кода на целевом железе с помощью программатора J-Link. Но пока только загрузчика U-boot. И автоматизируем развертывание рабочей среды разработчика с помощью Docker.

• перевод / в LVM
• перевод / в mdraid
• замена типа файловой системы (ext3 => btrfs)
• уменьшение размера ФС (resize2fs)

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

Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта,  в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.

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

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

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

Попробуем снова объять необъятное одним постом? На этот раз рассказ будет про УЗО.

Вводная

void fall()
{
  char * s = "short_text";
  sprintf(s,"This is very long text");
}

void fall()
{
  int * pointer = NULL;
  *pointer = 13;
}

Какое-то время назад на Хабре была небольшая волна постов на тему «Почему я [не] выбрал Linux». Как порядочный фанатик я стриггерился, однако решил, что продуктивнее что-нибудь рассказать о своей любимой системе, чем ломать копии в комментариях.

У меня сложилось впечатление, что многие пользователи GNU/Linux слабо представляют, из чего сделана эта операционная система, поэтому утверждают, что она сляпана из попавшихся под руку кусков. В то же время, архитектура большинства дистрибутивов является устоявшейся и регламентируется рядом стандартов, включая стандарт графического окружения freedesktop.org и Linux Standard Base, расширяющий стандарты Unix. Мне при знакомстве с GNU/Linux несколько лет назад для погружения не хватало простой анатомической карты типичного дистрибутива, поэтому я попробую рассказать об этом сам.

Вместо вступления

Немного о многозадачности

Каждый, кто день за днем или от случая к случаю, занимается программированием микроконтроллеров, рано или поздно столкнется с вопросом: а не использовать ли многозадачную операционную систему? Их в сети предлагается довольно много, при этом немало – бесплатных (или почти бесплатных). Только выбирай.

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

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

Летнюю самоизоляцию мы с семьей провели у тещи в деревне. У жены – отпуск, а нас, инженеров-проектировщиков, почти всех перевели на удаленку. Работать в «домике в деревне» значительно приятнее, чем в городе в панельной хрущевке. Так у меня появилась не только отдельная комната, но и дополнительные полтора часа свободного времени, которые в мирное время уходили на дорогу до офиса и обратно. Все это позволило довести до конца электронно-деревянно-кнопочный проект, который задумал еще лет 6 назад.

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

Всю весну я пытался объяснить детям (3 и 6 лет), что «папа на работе» и «папа дома» — это фактически разные сущности, но на практике всё оказалось сложнее. На дворе осень, по городу катится вторая волна пандемии, а дети снова заперты дома. Как дать им понять, что папу трогать нельзя? Нам помогли цветовой код и геймификация.

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

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

* АПР - аэропоника с пневматическим распылением

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

Вышло ли из этого что-то и что конкретно - под катом. Сразу предупрежу: статья огромная, потому что материала много. И очень много фото.