Links on arm linux

Установка Linux на ARM. Подробная пошаговая инструкция и советы

Установка Linux на ARM — это довольно интересная тема. Даже принимая только то, что это довольно-таки необычно. Почему необычно? П отому что в ARM-процессорах совсем другая архитектура, чем у тех, для которых рассчитано большинство дистрибутивов Линукс.

Для тех , кто не знает, ARM — архитектура маленьких микр оп роцессоров. Если простым языком, то это архитектура процессора у маленьких компьютеров или мобильных телефонов. Поэтому вопрос : вы часто видели Linux на смартфоне (процессоре ARM)?

Основная масса больших и привычных ПК имеют архитектуру х86 или AMD64. Данные процессоры рассчитаны на трудо- и ресурсоемкие задачи:

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

Но в т о ж е время ARMка имеет более низкое энергопотребление при должной производительности, а это как раз очень важно для небольших устройств. И поэтому она распространена в «маленьких» устройствах.

Какие операционные системы подходят для ARM?

В принципе на ARM — устройствах можно запустить любую операционную систему, которая была скомпилирована под данную архитектуру. Поэтому обычные Линукс версии, которые мы уже привыкли наблюдать на своих ПК , просто не подойдут , д аже если они легковесны и подходят по другим параметрам. Но в т о ж е время в сети можно найти приличное количество уже «готовых» дистрибутивов Linux для ARM — процессоров. Ярким представителем является известный всем Android, из менее известных, но популярных — Kali Linux.

Кстати, а вы знали, что популярный Android мегакорпорации Google — это всего лишь «операционка» на основе ядра Linux ? Пр ит ом, что Андроид является самой популярной операционной системой для мобильных телефонов — этот факт, как видите, малоизвестен. Но вообще нужно понимать, что Linux здесь является всего лишь «ядром». А ядро — это всего лишь основной функционал, предполагающий использование устройствами опций аппаратной системы, драйверов, управления, утилиты для командной строки и др. Семейство Linux подразумевает совокупность всех операционных систем, использующих его ядро, но это не есть самостоятельное ядро. Различие всем системам «семейства» придает графическая оболочка, но это совсем другая история. Однако возможность использовать эти ОС без графической оболочки, а только через текстовую командную строку, расширяют сферу их применения. Именно поэтому их можно «заметить» в необычных местах:

• в сетевом оборудовании;
• в производственных станках;
• в начинке самолета или автомобиля;
• даже в современных стиральных машинах.

Итак, из семейства Linux для ARM можно подобрать конфигурации у следующих дистрибутивов:

1. Debian. Это одна из самых старых версии Линукса, большое сообщество, много программ , написанных для этой системы, стабильность работы и мн.др. Его можно «найти» практически везде, также и в ARM — процессорах.
2. Ubuntu. Кто не слышал о б Убунту, тот не слышал о Линукс. С читается , что у него бо л ее продвинутое интерфейсное оформление, чем у Дебиан, да и вообще он сам более продвинутый. Встречается в ARM — процессорах, но совсем недавно анонсирована Ubuntu Phone — специальная ОС для смартфонов, которая будет призвана конкурировать с Android. Проект анонсирован, но пока должного «движения» не замечено.
3. Kali, Arch, Gentoo и др. , и каждый со своей отличительной особенностью , и каждый используется в ARM — системах.

На самом деле , этот список можно продолжать очень долго, потому что прогресс не стоит на месте, а земля наша слави тся умельцами. И многие разработчики «подтачивают» тот или иной дистрибутив Linux под ARM — процессор.

Установка Linux на ARM — устройство

Как правило, приобретая какое-либо устройство на ARM — процессоре, вы его получаете уже с предустановленной ОС. Чаще всего на таких устройствах идет Android. Допустим, вы все равно хотите установить Linux на это ARM — устройство. Тогда у вас есть 2 пути:

1. Полноценная «перепрошивка» на «чистое железо» ;
2. Установка «внутри» или «рядом» с Android (или другой системы, суть от этого не меняется).

При полной «перепрошивке» вы потеряете весь предустановленный производителем функционал. Вряд ли это будет то, чего вы добиваетесь. Поэтому тут можно воспользоваться вторым способом и установить Linux, не удаляя основную операционную систему вашего устройства. Для этого нужно будет настроить запуск chroot-окружения внутри Андроид. Но зато на выходе вы получите 2 параллельно установленные операционные системы и сможете использовать то одну, то другую. С т ак им подход ом можно поэкспериментировать на смартфонах или планшетах, где есть экран. А на простых безэкранных устройствах с таким способом могут возникнуть трудности.

Советы при установки Linux на ARM — устройство

На самом деле , совет будет один. Подумайте , прежде чем устанавливать Linux на свое ARM — устройство, тем более если на нем уже предустановлена производителем ОС. Потому что это не что иное , как хакинг — то есть преднамеренно е вмешательство в работу операционной системы. И никто , кроме вас , разделять риски работы устройства не будет.

Сама технология установки Linux на ARM еще в довольно «сырой» форме. Да, есть какие-то наработки и отдельные дистрибутивы. Есть умельцы, которые делают это и говорят, что это круто. Но в целом материала и стабильности в этом мало. Это не касается тех устройств, в которых Linux предустановлен производителем!

Но в т о ж е время четко вырисовывается тенденция, что за ARM — процессорами будущее. Этому свидетельствует даже тот факт, что первое место в рейтинге суперкомпьютеров ТОП — 500 в 2021 году с большим отрывом по производительности от конкурентов занимает машина на ARM — процессорах!

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

STM32 + linux

Для разработки системы управления одной железякой после длительных поисков мною был выбран ARM-микроконтроллер семейства STM32 — STM32F103 (в «стоножечном» исполнении). А в качестве макетки для разработки и отладки — STM32P103 (там ножек хоть и меньше, но ядро то же самое). «Истории успеха» я понемногу выкладывал в своей ЖЖшке, но вот решил собрать все воедино и рассказать о том, каково же оно — программировать микроконтроллеры в линуксе. Сам проект лежит на sourceforge.

Прежде всего коснусь общего, а потом уже перейду к деталям.

Итак, помимо макетки (или же готового устройства — когда оно будет готово) потребуется JTAG-адаптер. В моем случае это — ST-LINK/V2. Одного железа, естественно, недостаточно: надо еще как-то код компилировать, а потом еще и заливать на контроллер. Для этого были установлены компилятор gcc для ARM (arm-none-eabi) и утилита для работы с ST-LINK (она так и называется — stlink).

В качестве образца я взял этот проект. Отсюда я скачал простенькие демонстрационные проекты и попробовал скомпилировать простейший. А самым первым оказался стандартный Helloworld для МК: мигание светодиодом.

Сразу скажу, на какие грабли я напоролся с самого начала: я забыл про objcopy, без которого получить работающий код будет сложновато. После компиляции проекта обязательно надо создать бинарник при помощи этой утилиты. И не стоит выкидывать из Makefile’ов непонятных (и вроде бы даже ненужных на первый взгляд) целей.

В качестве удобного IDE я использую Geany. Так как на работе у меня два монитора, довольно удобно работать: на одном мониторе у меня открыт Geany с кодом, а на втором — терминал, где я запускаю make и com (терминал из tinyserial).

Весь Makefile я рассматривать не буду, обращу лишь внимание на то, что в нем следует менять:

• BIN — имя получающегося после компиляции бинарника
• STM32_LIBSRC и OBJ содержат подключаемые файлы библиотеки STDPeriphLib, неиспользуемые надо закомментировать
• SRC сдоержит перечень пользовательских исходников

После того, как код написан, запускаем make. Если все в порядке, в текущей директории появится файл $(BIN).bin, который и нужно записать во флеш-память МКшки. Запись выполняется при помощи make load: эта цель сборки просто вызывает st-flash для прошивки микроконтроллера.

Итак, прежде всего необходимо наладить связь компьютера и МКшки. Учитывая то, что в современных компьютерах RS-232 отсутствует, отладочную связь организую посредством USB. Однако, в «боевых условиях» команды МКшка будет получать по RS-232 от другого контроллера, поэтому я решил сразу же смотреть в сторону организации эмулятора переходника USB RS-232. Этот подход удобен еще тем, что не надо заморачиваться с лишним кодом для взаимодействия с устройством по USB (хоть это и элементарно, но лень же!). Да и отлаживать просто: открываем устройство /dev/ttyACM0 как последовательный порт при помощи любого эмулятора последовательного терминала и «общаемся». Да, в качестве эмулятора терминала на первых порах (пока нет никакого ПО со стороны компьютера) я использовал tinyserial.

Отсюда я скачал код эмулятора переходника USB RS-232. Так как проверить работоспособность второй стороны (RS-232) я сразу не мог (некуда подключить), неиспользуемый код работы с USART временно закомментировал.

Для работы с USB используется библиотека от STMicroelectronics. Если не вникать в коды самой библиотеки, все довольно-таки просто: нам нужно переопределить дескрипторы для своей железяки (файлы usb_desc.[ch]), чтобы компьютер опознал ее как переходник USB RS-232, а также изменить обработчики прерываний на события USB (как минимум — обработать принятые данные, а для прозрачной работы в качестве переходника, надо будет еще добавить обработку прерываний USART для передачи полученных оттуда данных по USB).

Для передачи сообщений используем что-то вроде кольцевого буфера, который постепенно будет наполняться, а по необходимости — передаваться по USB. Считывать данные будем в «обычный буфер». Так как пока что я использую только короткие команды, обработкой длинных посылок я не заморачивался. Если же они будут, нужно будет немного усложнить обработчик прерывания по приему данных с USB.

Так как некоторые команды (например, чтение температуры с 1-wire датчиков) выполняются довольно-таки долго, обработчик пришедших по USB команд только модифицирует флаги для подобных операций, а уж основной цикл в main() эти флаги обрабатывает. Операции, выполняющиеся быстро (работа со светодиодом), вызываются непосредственно из этой функции. В отладочных целях я добавил «эхо» на команды в виде краткой ее расшифровки:

Все, теперь при подключении макетки к компьютеру по USB (а она, вообще-то, у меня всегда подключена, т.к. питается через USB) появляется устройство /dev/ttyACM0, с которым можно работать, как с обычным последовательным портом. Например, открыть его при помощи последовательного терминала (как я уже выше сказал, на первых порах пользуюсь tinyserial).

Светодиод, кнопка

Наверное, традиционным является «помигать диодом» в начале изучения какой-нибудь новой железяки, поэтому и я сделаю так же. А заодно повешу на «user button» прерывание, которое будет менять режимы работы светодиода.

Просто мигать не интересно: интересно менять яркость. Для этого достаточно простого «софтового» ШИМа. Настроим таймер SysTick на период в 10мкс. Заведем два счетчика: один для количества «тиков», в течение которых светодиод горит, а второй — для количества «тиков», в течение которых светодиод не горит. Для изменения яркости свечения светодиода я сделал простейшую восьмиуровневую схему изменения скважности ШИМа.
Получилось вот что:

На «пользовательскую кнопку» я повесил внешнее прерывание:

1-wire

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

В сворованном мною примере 1-wire работала через USART, а для чтения/записи использовался DMA. Мне эта идея очень понравилась, поэтому воспользовался именно этим способом (хотя можно было организовать и программный протокол 1-wire).

Стандартная схема подключения 1-wire шины к последовательному порту подразумевает наличие диода Шоттки:

Однако, у меня такого диода не было. Но я углядел, что помимо push-pull режима можно отвечающую за USART_TX ногу перевести в режим с открытым стоком — в этом случае короткого замыкания не будет. Для работы с 1-wire я использовал USART3 (пока я балуюсь, ног мне хватает — поэтому remap делать не надо). На схеме я увидел, что ноги USART3 (PB10 и PB11) уже подтянуты к земле через резисторы по 10кОм, так что мне даже резистор припаивать не пришлось: только подпаял на макетку небольшую платку с гнездами, чтобы удобно было подключать термодатчики.

Подробно расписывать содержимое файла onewire.c не буду: это сделано уже до меня неоднократно, а коснусь лишь непосредственно работы с термометрами.

Для мониторинга температуры теплых (выше -50°C) частей устройства я решил воспользоваться простыми датчиками DS18S20 (заявленная точность измерения — не хуже 0.5°C). Подпаянную на макетку панельку я подключил к нужным выводам, чтобы можно было одновременно подключить к МКшке пару термометров.

Вот, например, что я получаю при работе с термометрами:

Для начала я промаркировал все термометры, чтобы знать, какой идентификатор у кого. А после я решил посмотреть, сильно ли различаются их показания. Температура — первые два байта ответа датчиков. В седьмом байте хранится «остаток» от преобразования температуры встроенным в термометр АЦП. По документации на датчики, этот остаток помогает уточнить значение температуры. Однако, выяснилось, что толку от него — как от козла молока.

В процессе работы датчик сам нагревается, что сказывается на результатах измерения. Поэтому не стоит слишком часто их опрашивать. Кроме того, показания датчиков отличались друг от друга вплоть до полутора градусов! Это нужно иметь в виду: если планируется использовать несколько датчиков так, чтобы мониторить разницу температур между участками чего-то с точностью не хуже 0.5°C, предварительно надо все датчики откалибровать. И показания брать по калибровочным формулам, а не ответу датчиков.

Реальная погрешность датчика иной раз превышает 0.5°C, поэтому все-таки лушче считать, что датчик имеет точность в 1°C.

Датчик Холла

Датчики Холла у меня аналоговые — SS495A. Спецификации на датчик можно найти в интернете. Скажу лишь, что в нормальном состоянии на его выходной ноге напряжение составляет около 2.5В (логическая единица STM32), в зависимости от полярности и величины внешнего магнитного поля он будет изменять свои показания в пределах 0..5В. Учитывая то, что напряжение на выходе может достигать пяти вольт, надо использовать не обычные, а «пятивольтовые» (обозначены как FR в спецификации) входы контроллера.

Имеющиеся у меня магниты (специально для этого датчика) при помещении их рабочей поверхности в пределах 1мм от «морды» датчика (маркированная сторона) приводили к появлению на его выходе нулевого напряжения. Причем уровень логического нуля появляется в довольно-таки небольшой зоне по координатам в параллельной маркированной стороне датчика плоскости, т.е. точность позиционирования получается довольно приличной.

Для опытов я распаял на макетке один датчик. Питание его подключил к 5В, а сигнальный выход вывел на порт PC10, который не сгорит, если на него подать 5В. Для того, чтобы не дергать постоянно порт, я повесил на него прерывание (по аналогии с кнопкой). Обработчик прерывания просто выставляет соответствующий флаг, а уж в основном цикле, если этот флаг выставлен (т.е. магнит либо появился, либо покинул «поле зрения» датчика) проверяем, что у нас на PC10. Если там ноль (есть МП), пишем в терминал «Magnet», иначе пишем «clear». Еще можно принудительно проверить, есть датчик или нет его, нажав «h» в терминале.

Помимо «теплых зон» мне еще надо будет измерять температуру в холодных (вплоть до 75К сверху). Для этого будут использоваться платиновые термосопротивления, подключенные к аналоговому коммутатору ADG506A. Ну и, естественно, мне стало интересно, насколько плох «родной» АЦП МКшки: нельзя ли его использовать для измерения температуры?

Примеров работы STM32 с АЦП полным-полно, я взял пример из STDPeriphLib. Будем запускать АЦП в режиме непрерывного преобразования, а результат заносить в память при помощи DMA. Время преобразования устанавливаю в самое большое (чтобы поточнее было), а сам вход АЦП пока что повешу на ногу PB0 (ADC8):

Для работы с коммутатором нужно сконфигурировать пять бит управляющего порта. Чтобы не париться с преобразованием бит, я просто взял первые четыре бита порта C в качестве адреса, а пятый бит — в качестве ключа, включающего коммутатор:

Прерываний здесь никаких не надо, а в файле interrupts.c надо дописать установку нового флага при поступлении команды (скажем, команды ‘a’) отображения напряжения на датчиках. В main() добавим обработку этого флага:

При поступлении команды в цикле запускаем выставление нужного адреса на коммутаторе, ждем пару миллисекунд, чтобы АЦП отработало, а затем выводим полученное значение. Потом отключаем коммутатор и ждем (на всякий случай) еще пару миллисекунд.

На отдельной макетке я собрал простой резистивный делитель напряжения, соединив все аналоговые входы коммутатора мелкоомными (200..900 Ом) резисторами. К S1 подключил «землю», а к S16 — +3.3В с макетки STM32. Запитал микросхему я старым БП от внешнего HDD (12В).

В макетке STM32P103 эталонное напряжение для АЦП берется от общего питания, поэтому точность получилась низкой: значения плавают иной раз аж на 20 единиц!

Вот, например, что получилось при двух опросах:

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

Шаговый двигатель

С шаговиком я еще не закончил возиться, т.к. подозреваю, что при монтаже элементов на макетке у меня ничего «не взлетит». Надо паять. А пайкой займусь, скорее всего, только в следующем году (надо еще радиодеталей прикупить). Пока лишь вкратце расскажу, как планирую управлять шаговыми двигателями.

Шаговики у меня будут — VSS42 на 1.2 ампера. Управлять такими удобней всего при помощи драйвера ШД — L6208. При работе на эту микросхему надо подавать лишь сигналы управления направлением движения, сигнал разрешения работы да тактовые импульсы. Контроллер сам регулирует ШИМ и устанавливает нужные напряжения на обмотках двигателя.

Укажу пока основное, на что следует обратить внимание:

• Регулировка ШИМа выполняется посредством сравнения падения напряжения на Sense-резисторах с опорным напряжением Vref. Поэтому для тока I_max и сопротивления резисторов R_Sense это падение можно рассчитать довольно просто:
  U_ref = I_max · R_Sense
  Т.е. для выставления предельного тока в 1.2А при R_Sense=0.33Ом нужно задать U_ref=0.4 В. Ни в коем случае нельзя оставлять ноги V_ref висящими в воздухе или прижатыми к земле!
• Режим Slow/Fast decay имеет значение для обычных коллекторных двигателей, шаговикам же Fast decay нужен лишь в режиме microstepping. В общем, если не извращаться, достаточно просто подать +5В на ножку CONTROL. На HALF/FULL тоже просто подаем +5В и работаем в полушаговом режиме. Аналогично поступаем с ногой RESET, если не хотим сбрасывать счетчик фаз (а его сбрасывать и не нужно, если честно отдавать на каждый шаг по 8 синхроимпульсов).
• Вход ENABLE является еще и выходом: если с драйвером L6208 случается неприятность (перегрев, скачок тока), он самостоятельно отключает напряжение на нагрузке, а ENABLE подтягивает к земле. Это значит, что можно проверять, не случилась ли аварийная ситуация, если ногу контроллера, управляющую портом ENABLE, активировать в режиме выхода с открытым коллектором.
  По спецификации STM32, в режиме открытого коллектора при подаче единицы на выход порта просто запирается транзистор, подтягивающий ногу к земле. Если же на выход подать нуль, то нога опять подтягивается.
  Таким образом, подтянув ногу контроллера к +5В (ногу нужно выбирать FT) через, скажем, пятикилоомный резистор, а между ней и ENABLE воткнув, скажем, килоомный резистор (и обязательно не забыть шунтировать ногу ENABLE конденсатором на землю, иначе можно сжечь управляющий контроллер), можно и включать/выключать нужный двигатель, и проверять, не было ли аварий (а для этого можно повесить на соответствующие ноги контроллера прерывание периферии по спадающему фронту).
• Проводники, помеченные в спецификации жирным, должны быть как можно короче и шире. Но при этом надо следить и за тем, чтобы уменьшить паразитные емкости и индуктивности.
  R_Sense должны располагаться как можно ближе к драйверу. Недалеко от них должны быть и конденсаторы C₁ и C₂ (по спецификации): через эту цепь течет не только ток сравнения, но и обратный ток индукции (поэтому, кстати, диоды в эту цепочку включать нельзя).
  Сигнальную землю соединять с силовой землей только далее точки подключения C₁ к земле, иначе ток индукции может попортить электронику просто падением напряжения на проводниках печатки (до меня, правда, не дошло, как это возможно, но лучше прислушаться к требованиям безопасности).
• Еще я прочел интересную штуку: силовое питание нельзя подключать без сигнального! В документации рекомендуется даже брать напряжение 5 В от силового источника при помощи стабилизирующего блока.
  Я, честно говоря, ничего не понял: собственно +5 В подается лишь на управляющие ноги драйвера. Если мы не пользуемся двигателем, то, по идее, у него на всех сигнальных входах может быть 0. Но включать силовое питание таки буду после включения питания контроллера. И выключать в обратной последовательности. И следить, чтобы USB-шнурок, питающий контроллер, не выскочил.

Источник