Linux Kernel — это, пожалуй, один из самых распространённых (и, возможно, до сих пор недооценённых) программных продуктов в мире. Он является основой всех дистрибутивов Linux (что очевидно), но на этом его роль не заканчивается. Ядро также работает на множестве встроенных устройств практически повсюду. У вас есть микроволновка? Скорее всего, она работает на ядре Linux. Посудомоечная машина? Тоже. Если у вас достаточно средств на автомобиль Tesla, вы даже сможете найти несколько багов, исправить их и отправить патч в код Model S или Model X на GitHub. А что насчёт схем, которые не позволяют Международной космической станции сойти с орбиты и врезаться в Землю? Конечно, и там тоже Linux. Ядро легковесное — значит, отлично работает даже в условиях невесомости.

В этой статье напишем свой первый модуль ядра под Linux

Я решил недавно улучшить свой навык владения C, путем написания проектов. Самая первая мысль, которая пришла мне на ум — это командный интерпретатор, командная оболочка, shell проще говоря. А также я расскажу о системе сборки make, и о том, как правильно писать и документировать C-код.

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

Да-да, мы превратим наш велосипед в мопед! Я вынес из прошлой статьи итоги, и попытался решить все проблемы и замечания. Продолжаем погружение в пучины разработки под Linux!

Учитывая, что я очень давно занимаюсь отладкой и запуском самых разнообразных проектов связанных с Zynq 7000 — со временем количество итераций перезапуска при проведении отладки увеличивалось пропорционально сложности проекта. Когда я только начинал осваивать разработку под Zynq, то каждый раз закидывал новый образ на microSD карту. Это было очень медленным процессом и требовало от меня постоянно подключать/отключать карту. После этого я освоил сетевую загрузку через Ethernet и TFTP, заменяя файлы по сети и проверяя результат после перезагрузки.

Впоследствии, изучив вопрос связанный с типами загрузки, я обнаружил, что есть альтернативный способ загрузки платы через интерфейс JTAG, который впрочем может оказаться единственным доступным, если на плате нет microSD и Ethernet.  

Вот как раз вопросы связанные с тем, как произвести загрузку по JTAG я бы хотел осветить в этой статье. Всем кому интересно — добро пожаловать под кат. 

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

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

В программировании микроконтроллеров новые сборки появляются каждый день.

Какие-то сборки уходят в релиз, а какие-то в циркулируют на разных электронных платах внутри предприятия.

Как отличать прошивки между собой? Как понять, какая прошивка новее, а какая старее?

Проблема в том, что вручную обновлять номер версии прошивки очень утомительно.

В тексте представлен механизм автоматического увеличения версии прошивки

Рассмотрим, как устроены GPIO-драйверы в Linux, и почему это сделано именно так. Поймем, почему для простого мигания светодиодом в этой операционной системе надо пройти через N слоев абстракции.

Введение

Здраствуйте меня зовут Дмитрий. Недавно я написал статью как собрать прошивку для одноплатного компьютера Orange PI i96 с нуля. Если вы не читали то очень советую. И там я упоминал что для того чтобы собрать прошивку на новом ядре Linux, мне пришлось переписать драйверы с учетом архитектуры Device Tree, которую использует современное ядро. В этой статье я опишу как я это сделал.

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

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

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.

Продолжаем изучение SoC Zynq 7000 и разбираемся с тем, как организовать подготовку, сборку Linux для отладочной платы QMTech. В прошлой статье я рассмотрел процедуру быстрой сборки (без кастомизации) основных компонентов встраиваемой системы Linux и шаг за шагом прошли путь до приглашения к вводу в работающей ОС. Согласитесь, что если вы новичок - то работа была выполнена колоссальная! К счастью, всю эту работу можно автоматизировать! И в этой статье я хотел бы уделить внимание этому вопросу и рассказать как это сделать с помощью Buildroot. Эту статью можно считать логическим продолжением общего повествования о начале работы с Linux на Zynq.

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

Всем интересующимся - добро пожаловать под кат!

Сегодня мы затронем сторону, отличную от написания кода. Мы займемся оформлением и написанием документации, как правильно делать коммиты и как оформлять код.

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

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

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

Привет, Хабр!

Мы в beeline cloud не только создаем современные цифровые продукты, но и обучаем разработке в облаке студентов нашего курса Base Cloud DevOps. Однако выстроить эффективный процесс невозможно без знания основных инструментов. Один из них — система контроля версий Git. Перевели для вас статью, которая поможет извлечь из работы с этой утилитой еще больше пользы.

Когда-то я и не задумывался о существовании каких-то правил для составления комментариев к коммитам, но потом любознательность взяла верх. Мне казалось, что простых сообщений наподобие «добавлена функция 2», «исправлена ошибка на панели навигации» или просто «foo» вполне достаточно. Однако моя уверенность в том, что комментарии к коммитам, как правило, никто не читает, оказалась ошибкой. Хорошо составленные commit messages очень важны, они помогают нам самим в будущем извлечь максимальную пользу из своих стараний и продуманности.

• энергетика;
• контрольно-измерительное оборудование;
• оборонно-промышленный комплекс;
• телеком;
• финансовый сектор.

В этой статье я решил сделать небольшое отступление от общей линии повествования и зарулю на дорогу Linux. За то непродолжительное время, что я работаю с Zynq 7000, в тематических чатах я видел много вопросов насчет того, как запустить Linux на отладке. Я в общем-то, недолго думая, сел проштудировал документацию, примеры и завёл его своими руками под ту плату, что у меня есть в распоряжении. После этого я решил обобщить свои знания по этому вопросу и описать процедуру сборки, подготовки загрузочного образа Linux, который включает в себя U-boot, Device Tree Source, RootFS, и само ядро Linux. В дополнение к этому, я решил немного усложнить задачу и выяснил, как можно поморгать светодиодом подключенным к PL-части устройства из пространства пользователя Linux.

Обо всём этом я написал в этой статье. Всем интересующимся - добро пожаловать под кат.

Как только сложность программы выходит за пределы "Hello Word!", у начинающих ардуинщиков появляются проблемы. Самая тяжелая из них - удержать в голове структуру программного кода. Нельзя сказать, что у опытных программистов встраиваемых систем этой проблемы нет. Достаточно попытаться реанимировать собственный проект двухлетней давности, если он недостаточно документирован, то включиться в работу будет очень трудно.

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

Все это хорошо, но новичку просто лениво. Зачем что-то рисовать, если того же результата можно добиться несколькими строчками кода? Ответ: макрокоманды. Такие, например, как WAIT(Time,Counter), она позволяет с легкостью организовать временную задержку. И это будет вовсе не Delay(Time) от Arduino, которая остановит выполнение всего остального пользовательского кода. Нет. По предоставляемым возможностям ближайшей аналогией будет RTOS - операционная система реального времени. Если один автомат замер в ожидании отсчета времени, то остальные автоматы проекта будут продолжать работать.

Рассмотрим практическое использование графических конечных автоматов под Arduino на примере часов-метеостанции.