STM32 (2): удобная среда разработки — SES + CubeMX: методика ускорения разработки (часть 1)

STM32 (2): удобная среда разработки — SES + CubeMX: методика ускорения разработки (часть 1)

В предыдущей статье мы рассмотрели и настроили среду разработки на основе

Segger Embedded Studio (SES).

В этой статье я опишу методику ускорения разработки ПО под STM32 путём подключения HAL (Hardware Abstraction Level, библиотека абстракции от аппаратуры) от ST.

В прошлый раз мы упоминали пакет CMSIS (Cortex-M Software Interface Standard) — это набор общих для всех Cortex-M контроллеров дефайнов (#define). Эта, условно говоря, библиотека разработана для стандартизации процесса разработки и повышения переносимости кода между всеми Cortex-M контроллерами. У неё есть очевидное положительное качество — её легковесность, так как дефайны, раскрываясь при компиляции, не занимают места. И, да — она облегчает работу на Cortex-M (в том числе и на STM32). Но если вы будете писать код с использованием лишь CMSIS, вам придётся заполнять все структуры (множество структур) самостоятельно. И, более того, о, ужас, писать непонятные вещи, подобные этому:

GPIOA->ODR &= ~GPIO_ODR_ODR0;

Компания STMicroelectronics пошла дальше и разработала продукт называемый STM32CubeMX (CubeMX). CubeMX — свободный, кроссплатформенный пакет для настройки HAL от ST в графической среде. Процесс работы с использованием CubeMX выглядит примерно так: выбираем тип контроллера, настраиваем его интерфейсы, выбираем IDE, под которую нужно создать проект, нажимаем «Сгенерировать проект», открываем проект в выбранной IDE, работаем над функционалом. К сожалению CubeMX не поддерживает SES. Как это компенсировать я и расскажу на простом примере.

Для начала работы, скачайте CubeMX:
https://www.st.com/en/development-tools/stm32cubemx.html
Нужно нажать Get Software и, к сожалению без регистрации/авторизации скачать не получится.

Устанавливаем, запускаем, создаём проект (New Project —> ACCESS TO MCU SELECTOR):

В открывшемся окне (загружается из базы продуктов ST) выберите свой контроллер — либо в списке, либо введите часть его названия в поле поиска слева вверху. По идее на генерацию кода это не должно влиять, но так как CubeMX у ST выполняет частично и функции продажи, придётся выбрать даже тип корпуса. В прочем, если вам придётся реально отлаживать комплекс на уровне железа (осциллограф, анализатор, тестер) — будет ещё удобнее видеть где какие конкретные выводы находятся. Ведь CubeMX нарисует вам выбранный контроллер в выбранном корпусе с реальным расположением и названиями ног и выводов!

Вверху вы увидите три вкладки — Pinout & Configuration, Clock Configuration и Project Manager.

Начнём с самого основного — настройки частоты на которой будет работать наш контроллер. Перейдите на вкладку Clock Configuration. Вы увидите следующее (картина будет отличаться в зависимости от выбранного контроллера, я для примера рассматриваю один из самых простых — STM32L011):

Видите как много параметров в настройке частоты? А теперь введите в поле HCLK (MHz) (обычно чуть выше и правее середины схемы) значение. CubeMX даже подскажет вам максимальную частоту, которую вы можете себе «позволить» на выбранном контроллере.

После нажатия Enter, CubeMX сам рассчитает всю цепь, а в случае некорректного значения сообщит об ошибке.

Далее во вкладке Project Manager введите название проекта, пути и прочее. В поле Toolchain / IDE выберите MDK-ARM V5. Последнее важно для импортирования проекта в SES. Теперь нажмите «GENERATE CODE» (находится справа вверху). CubeMX создаст проект, скопирует HAL под нужный контроллер и, что самое главное — сгенерирует высокоуровневый код (с использованием HAL'а), который выполнит инициализацию всего того, что мы настроили в графической среде.

Как я уже писал — под SES CubeMX не умеет делать проекты. Сейчас мы будем это исправлять. Открываем SES и создаём проект, выбираем тот же контроллер, что и в CubeMX. Здесь не повторяюсь — этот процесс описан в предыдущей статье.

Открываем оба каталога — с проектом CubeMX и с проектом SES. Далее будем копировать файлы из каталога с проектом CubeMX в корень каталога проекта SES (себе). Я буду показывать процесс на примере проекта под STM32L0xx. В случае использования другого контроллера, имена каталогов изменятся соответственно.

1. Удаляем из проекта SES файл main.c (нажать на нём правой кнопкой и выбрать «X Delete»).

2. Копируем себе каталоги Src и Inc.

3. Перемещаем файл Src/system_stm32l0xx.c в каталог STM32L0xx/CMSIS/Device/Source (с замещением).

4. Копируем каталог STM32L0xx_HAL_Driver (у CubeMX находится в каталоге Drivers). Я обычно копирую его в каталог STM32L0xx, который SES создаёт в корне проекта.

5. Добавляем новые файлы исходного кода: жмём правой кнопкой мыши по Source Files, выбираем Add Existing File... и указываем все файлы из каталога Src.

6. Повторяем эту процедуру, указывая все файлы из каталога STM32L0xx/STM32L0xx_HAL_Driver/Src

7. Открываем свойства проекта (правая кнопка на проекте —> Options...), ищем User Include Directories и указываем:

.
./Inc
STM32L0xx/STM32L0xx_HAL_Driver/Inc

На этом самая сложная часть импорта ST HAL'а в проект завершилась. На данном этапе ваш проект должен компилироваться, собираться, загружаться и работать.

Для проверки правильно ли выставилась частота контроллера, добавим в наш main следующий функционал. Найдите вызов функции SystemClock_Config() и добавьте до и после неё соответствующий вывод:

printf ("Unset clock speed is: %dMHz ", HAL_RCC_GetSysClockFreq () / (1000 * 1000));
SystemClock_Config(); printf ("Clock speed is set to: %dMHz ", HAL_RCC_GetSysClockFreq () / (1000 * 1000));

У меня выводит следующее:
Unset clock speed is: 2MHz Clock speed is set to: 32MHz

Завершающее эту статью замечание. В коде, созданном в CubeMX вы увидите множество комментариев, в том числе и вида

/* USER CODE BEGIN 1 */
/* USER CODE END 1 */

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

Разумеется выставить частоту контроллера не единственная задача на наших проектах, поэтому в следующей статье я покажу что ещё можно делать в CubeMX и как добавлять в свой проект дальнейшие изменения если вы удалили комментарии USER CODE BEGIN/END.

STM32 (1): удобная среда разработки — SES: обзор, подготовка к работе

STM32 (1): удобная среда разработки — SES: обзор, подготовка к работе

В этой статье я предлагаю рассмотреть и настроить среду разработки на основе

Segger Embedded Studio (SES).

В отличие от других IDE, используемых для разработки под STM32 (в большинстве своём, основанных на Eclipse), SES, являясь проприетарным продуктом, представляет собой консистентную (целостную) IDE. SES предоставляет следующие возможности:

• Создание проектов под микроконтроллеры (через GUI-Wizard);
• Группировку проектов в «решения» (Solution);
• Массу настроек проекта (так же через GUI);
• Сборку проектов в различные выходные форматы (ELF, bin, hex);
• Загрузку прошивки в микроконтроллер через JTAG;
• Пошаговую отладку программы;
• Отладочный вывод (RTT — о нём ниже);
• Многое другое ещё не освоенное мной.

SES является кроссплатформенным продуктом (Linux, Mac, Windows), производителем предоставляется возможность бесплатно (свободно) пользоваться ей в некоммерческих целях. На момент написания этой статьи (май 2019) скачивание даже не требовало регистрации (что по нынешним меркам граничит с фантастикой).

И дополнительный бонус — в SES есть возможность включить в проект Segger RTT (Real Time Transfer, иногда переводят как Real Time Terminal) — очень быстрая и легковесная реализация отладочного вывода (printf) с устройства на компьютер и даже ввода данных с компьютера на устройство (!). Последнее я не использовал и не проверял.

В других IDE отладочный вывод надо реализовывать в коде самому, а иногда и дорабатывать JTAG (допаивать SWO — Single Wire Output, например). А если говорить о Semihosting'е, то придётся ещё дополнительное окно открывать. В компании Segger это реализовали по трём проводам (режим подключения SWD — Single Wire Debug). А сам отладочный вывод отображается в самой SES, во включающейся в режиме отладки вкладке Debug Terminal.

Из недочётов SES можно указать отсутствие поддержки ST-Link, но сделать J-Link из китайского ST-Link'а — не проблема (возможно, напишу о том как это делается).

Отмечу, что SES вся такая целостная и проприетарная не страдает недостатками подобных IDE (Keil, например). В SES можно экспортировать Makefile из проекта (правда вы скорее всего захотите его доработать, если решите работать с проектом на чистом Makefile). Можно открыть файл разметки секций и карты памяти в самом редакторе и править их руками, затем пересобирать проект с новым расположением секций. SES поставляется и работает на обычном GCC (и clang, чем компилировать — можно выбирать). Отсюда вытекают все положительные последствия — привычные настройки, ключи и поведение компилятора.

Для тех, кого я убедил попробовать SES, ссылка для скачивания: скачать SES

SES построена по принципу модульной системы — поддержка всего и вся здесь осуществляется модулями. Для того чтобы создать наш первый проект, нужно установить модуль для интересующего нас микроконтроллера и CMSIS (если, конечно вы не хотите писать код под Cortex-M, не отрываясь от документации). Модули легко устанавливаются (скачиваются из интернета) через GUI. Откройте диалоговое окно Tools —> Package Manager. 

Как видно из снимков этого диалогового окна — у меня уже установлены модули поддержки STM32L0, STM32F4 и CMSIS.

Найдите нужный вам тип контроллера и установите поддержку его. Зависимости устанавливаются автоматически. Например, для STM32 будет установлен CMSIS.

После откройте окно создания проекта (File —> New Project ... ), выберите проект под нужный тип контроллера (установленные вами пакеты поддержки контроллеров будет доступны здесь). Нажмите Next и в следующем окне укажите конкретный процессор (Target Processor) из выбранного семейства.

Если вы здесь забудете это сделать — ничего страшного, это можно будет поменять в последствии в свойствах проекта сколько угодно раз. Дальше Next, Next до упора, Finish. Всё, проект создан, вы можете подключить J-Link к компьютеру и отлаживаться.

В следующей статье я расскажу о том как можно путём некоторых изощрений (или извращений) облегчить себе жизнь. Речь пойдёт о HAL (Hardware Abstraction Level — библиотека абстракции от аппаратуры, облегчающая работу с ней).

Git: базовые функции или как не потерять лицо перед коллегами (создание репозиториев)

Git.3: создание репозиториев

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

GitLab, который мы использовали в примерах из первой заметки является удалённым сервером, со своими пользователями и их правами. В примерах этих статей мы будем заливать изменения в репозиторий. У вас это не получится сделать с моим репозиторием. Для этого нам понадобилось бы учиться создавать пользователей на GitLab'е, мне давать вам права разработчика и/или публиковать свой ssh-ключ и пр. В будущих заметках мы, возможно, будем учиться как этому так и прочему функционалу GitLab'а. Пока наша задача быстро начать работать на равных с другими коллегами (и не потерять лицо перед ними). 

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

Репозиторий создаётся следующим образом. Создайте каталог с названием вашего репозитория, добавив к нему «.git» и перейдите в него, например:

mkdir GitTutor.git
cd GitTutor.git

Здесь расширение .git говорит о том, что создаваемый каталог будет Git-директорией, той, о которой мы говорили в первой статье. Здесь важно понять — созданный выше каталог не является каталогом с вашим проектом, в него не нужно класть ваши файлы (!).  Далее создайте пустой репозиторий следующей командой (в вашей Git-директории GitTutor.git):

git init --bare (здесь два минуса перед bare)

Git создаст пустой репозиторий. Этот репозиторий будет иметь полную функциональность, без каких либо ограничений по сравнению с вашими рабочими (удалёнными) репозиториями. Его можно (нужно) клонировать так же как и удалённый:

cd WorkingDirectory

git clone /Path/To/RepositoryName.git
cd RepositoryName

Путь к каталогу, в котором лежит репозиторий можно указать как полный так и относительный. Эта команда склонирует репозиторий в каталог RepositoryName.

С этим каталогом (клонированной копией репозитория) вы можете делать всё, что описано в статьях предшествующих этой — клонировать, добавлять файлы, коммитить изменения. Пока можете потренироваться без риска. А в следующей статье мы рассмотрим как работать с удалёнными репозиториями.

Git: базовые функции или как не потерять лицо перед коллегами (работа с изменениями)

Git.2: работа с изменениями

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

Первое — зафиксировать изменения в системе контроля версий (коммит):

git commit -am "Описание коммита"

Эта команда запишет ваши изменения в локальную базу Git'a. Ключ -a означает что нужно записать изменения всех файлов. Следует пользоваться этим ключом с осторожностью — если вы не хотели сохранять в базе изменения в некоторых файлах (например, те файлы, которые не компилируются на данный момент), то ключ -a запишет и эти файлы. В таком случае нужно указать имена файлов, изменения которых нужно зафиксировать. Ключ -m - означает указать сообщение. Если не указывать ключ -m (и последующее описание коммита, соответственно), то Git запустит редактор, в котором вам будет предложено ввести описание коммита. Пример коммита файлов поштучно:

git commit -m "Добавлены файлы main.c, main.h" main.c main.h

Пользоваться ли редактором для внесения комментария к коммиту или вводить его с ключом -m — личные предпочтения каждого. Лично я предпочитаю задавать комментарий в командной строке.

Повторю то, что уже тысячи раз писалось — несмотря на то, что Git позволяет ставить пустую строку в комментарий, не забывайте описывать свои изменения (коммиты). Когда-то их наличие может спасти вас от часов головной боли.

Теперь рассмотрим ситуацию когда вам нужно добавить новый файл в репозиторий. Если вы просто создадите файл в каталоге репозитория и сделаете commit -a, Git не запишет его в систему контроля версий (более того — вас даже не предупредят о том, что файлы были проигнорированы). А если вы сделаете commit с указанием конкретного имени нового файла, Git и вовсе выдаст ошибку. Для того чтобы Git начал считать этот файл частью репозитория, нужно сделать следующее:

git add список_имён_файлов

Если нужно добавить несколько новых файлов, можно использовать ключ -A. Что ещё более замечательно — этот ключ не только добавляет файлы, но и удаляет и перемещает (помечает к удалению или перемещению). Если быть точнее — этот ключ приводит репозиторий в соответствие с существующим деревом каталогов, что удобнее, чем добавлять, удалять и перемещать файлы поштучно вручную отдельными командами Git'a.

git add -A

NB!

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

Здесь нужно сделать commit (без ключа -a). В ситуации когда было изменение репозитория (добавлены или удалёны файлы) нужно зафиксировать изменения:

git commit -m "Добавлены файлы ... удалены файлы... перемещены файлы..."

Если вы не закоммитите изменения репозитория (добавленные файлы), то в последствии, когда вы измените содержание файла(-ов) и попытаетесь коммитить и добавление файла и его изменение, будут проблемы. Git закоммитит файл в том состоянии, в котором он был на момент выполнения git add. Это нормально и является следствием концепции Git'а, вглубь которой мы сейчас не полезем.

NB! Важно.

О частоте коммитов и их названиях. Не ленитесь делать коммиты в базу и осмысленно их комментировать. Лично я рекомендую фиксировать изменения являющиеся какими-то этапами — например, созданы файлы, добавлены основные шаблоны, завершена сложная функция. Называть их рекомендую соответственно — «добавлены файлы main.c, main.h», «добавлен отладочный вывод». В случае, если «сложная функция» оказалась очень большой, прогресс в процессе работы над ней можно коммитить соответственно подфункциям. Когда я совсем никак не могу найти оправдание коммита, я называю его «Operating commit» (что означает «операционный коммит»).

Итог

На данный момент вы умеете скачивать (клонировать) репозиторий, записывать изменения в локальную базу (вести базу версий), и добавлять в неё новые файлы.

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

Git: базовые функции или как не потерять лицо перед коллегами (введение, клонирование)

"Repository — a place where things are or may be reposited,
or laid up, for safety or preservation."
Daniel Webster 1913 dictionary

Git.1: введение, клонирование

Предупреждение: эта заметка будет объёмнее, чем последующие, так как здесь будут даны общие данные и расписаны некоторые понятия. Наберитесь терпения.

Серия статей «Git: базовые функции или как не потерять лицо перед коллегами» является памяткой для тех, кто периодически забывает о том, как работать с Git'ом в редко возникающих ситуациях или никогда не работал и нуждается в коротких подсказках как работать с этой системой в объёме ежедневных/еженедельных операций с репозиториями. Так же эти заметки могут служить инструкцией для быстрого начала работы с Git'ом для новичков и студентов.

Сам я ощутил потребность в подобном источнике информации, когда я устроился на новую работу, в достаточно большой коллектив, где Git действительно использовался для командной работы, а не как система архивирования, что не редко встречается. Меня хотели быстро подключить к проекту, сказали забрать репозиторий и прислали ссылку на него. А я не только не помнил, что с этим делать - я даже не мог вспомнить, когда выкачивал репозиторий в последний раз! В памяти всплывали только команды commit и push (это мы делаем несколько чаще, чем выкачиваем репозитории). Я с ужасом осознал, что это — всё, что я знаю о Git'е на данный момент. Тут я подумал, что хорошо бы было иметь памятки, неглубокие, но содержащие нужный минимум, и в которые можно было бы заглядывать по мере необходимости. Это и побудило меня записать и опубликовать информацию для коллег. 

Кому ещё могут быть полезны эти заметки?

• Руководителю, которому нужно иногда смотреть, что происходит с кодовой базой в отделе или проекте.
• Тем, у кого имел место отпуск или другой перерыв в работе.
• Тем, кому надо подготовиться к зачёту или к защите своего первого диплома в техническом ВУЗе.

Знакома какая-то из вышеописанных ситуаций? Тогда читайте — это для вас.

Перед тем как начать, укажу общие сведения:

• Для примеров я буду использовать сервис GitLab. Почему я выбрал его? Потому что этот продукт включает в себя Git-сервер и достаточно серьёзную надстройку над ним в виде bug-, issue-трекинга и иных инструментов. Если мы в этих заметках будем касаться какого-то функционала этого сервиса (помимо самого Git'а) — знакомство с ним будет плюсом вашей (и моей) карьере, так как GitLab нередко используется как внутрикорпоративная система во многих компаниях (даже в IBM, Sony и NASA!).
• Для доступа к моим учебным репозиториям не будет запрошен пользователь и пароль - все они настроены как «публичные».
• Структура этих заметок будет примерно следующая: описание рассматриваемой проблемы или постановка задачи, её решение в простых терминах, затем, опционально: заметки о дополнительных нюансах, потенциальных ошибках, возможностях и более подробная техническая информация.
• Прошу вас сообщать мне о допущенных ошибках или упущениях (терминология, аспекты, и пр.). Не стесняйтесь задавать дополнительные вопросы. Так же буду благодарен за предложения тем, которые вы считаете уместным рассмотреть.

Начнём с самого первого нашего контакта с системой Git — как скачать репозиторий?

git clone https://gitlab.com/daftsoft/StartProject.git

Эта команда создаст каталог с названием проекта без расширения (.git), в нашем случае — StartProject, и скачает последнюю версию репозитория в этот каталог.

NB!

В терминологии (и в идеологии) Git'а скачивание репозитория называется «клонированием». Впрочем, не во всех коллективах используют этот термин, нередко говорят «скачать».

NB!

Если вас не устраивает имя проекта по-умолчанию (имя проекта Git'а без .git), вы можете склонировать репозиторий в каталог с указанным именем:

git clone https://gitlab.com/daftsoft/StartProject.git LocalProjectDirectory

Если в проекте есть субмодули (уточните это у старших в отделе или у начальника/руководителя), нужно использовать ключ --recurse-submodule

git clone https://gitlab.com/daftsoft/StartProject.git --recurse-submodules

Если нужно забрать один субмодуль, например, если в проекте их очень (слишком) много, то из каталога, где лежит репозиторий выполнить:

git submodule init
git submodule update --remote Submodule (Submodule — имя субмодуля)

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

Всё. Вы можете начинать работать с кодом — изучать, компилировать, отлаживать.

Git может работать по двум протоколам — https и ssh.

Примеры ссылок (адресов репозиториев): 

HTTPS:
https://gitlab.com/daftsoft/StartProject.git

SSH:
git@gitlab.com:daftsoft/startproject.git

NB!

Потенциальная почва для ошибок, которые трудно заметить.

Обратите внимание на то, что разделители в адресах с разными протоколами разные. Нетрудно ошибиться и долго ломать голову — почему же Git не выкачивает репозиторий, а только пишет fatal, fatal, fatal...

.git на конце ссылки консольный Git добавляет сам — её можно опустить.

NB!

Вы уже могли догадаться, что Git должен где-то хранить служебную информацию — историю изменений, авторов и прочее. Да, вся служебная информация Git'а хранится в каталоге .git («скрытый» каталог в UNIX-системах). Каталог, в котором расположен .git называется git-директорией. Пока (а лучше никогда) залезать в него не надо — и у вас всё будет работать.

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

Ретро-статья: про «уровни» языков программирования и assembler

Эта статья является вводной в курс языка программирования низкого уровня Assembler (далее — Asm). Так как эта статья вводная, мы ограничимся весьма поверхностной информацией и общими сведениями. 

Было бы логично начать с определения, что мы будем принимать за низкий уровень, а что — за высокий. Языки программирования делятся на низкоуровневые и высокоуровневые. В данном случае подразумевается степень приближённости языка программирования к языку человеческому (а так же отдалённость его от машинного языка). Дело в том, что процессор работает по своим принципам, и общаться с ним можно только на его языке. Следовательно, самый низкоуровневый язык — это язык машинного кода, так как он является родным для процессора и находится дальше всего от человеческого языка. Следующим по высоте является язык Asm, поскольку Asm представляет собою мнемонику, набор легко запоминаемых обозначений (легко запоминаемых, относительно самого машинного кода). То есть Asm оперирует напрямик с процессором и его командами. Дальше стоят языки высокого уровня, такие как BASIC, Pascal, C/C++, Fortran. И на последней ступени, на данный момент, стоят RAD системы (Rapid Application Development — быстрая разработка приложений). Такие как Visual BASIC, Visual С#, Delphi и прочие, как правило визуальные. Сейчас RAD системы принято называть «студиями», так как фирмы выпускают именно студии, визуальные, содержащие большинство распространенных языков. В наше время можно наблюдать две основные студии — Borland Developer Studio и Microsoft Visual Studio. Borland Developer Studio включает в себя Delphi (язык на основе Pascal, который в процессе эволюции получил название Delphi Language) и C#. Отдельно поставляется версия RAD системы на основе C++ — C++ Builder. Но есть вероятность что фирма Borland в ближайшем будущем совместит две эти студии в одну. Microsoft Visual Studio включает в себя Visual BASIC, Visual C++ и Visual C#. Работа в студии наиболее похожа на обычное межличностное человеческое общение, на языке напоминающем человеческий (а во многих случаях и вовсе прямо сводится к тырканью мышью по различным областям экрана). 

Не сложно предположить, что всякая программа в конечном счёте всё равно будет переведена на язык процессора. Процесс перевода с человеческого языка на машинный называется трансляцией. Процесс построения программы — это трансляция, — преобразование программы в набор объектных файлов, содержащих машинный код, и линковка — объединение объектных файлов в результирующий исполняемый файл под данную конкретную операционную систему. Если мы пишем на машинном языке, нам не требуется ничего компилировать, достаточно всего лишь сохранить в файл и можно запускать. Компиляция с Asm'а — это всего лишь последовательный перевод одной команды Asm'а в определённый набор команд процессора. Компиляция программы на Asm'е подобна переводу с Американского на Британский. В то время как компиляция с языка высокоуровневого напоминает скорее перевод с иероглифов, русского или иврита, на, допустим, тот же Британский. 

Уровень языка также отвечает за то, насколько процесс разработки, компиляции и сборки финальной программы контролируется разработчиком. То есть, программисты на машинном коде и на Asm'е полностью контролирует процесс работы своей программы. Конечно, они же говорят практически на Британском. В случае с высоким уровнем языка, и подавно с RAD системами, мы практически не можем контролировать работу процессора, в лучшем случае мы как-то можем повлиять на результат работы программы. Весь процесс перевода языков берёт на себя транслятор. Здесь можно упомянуть такое понятие, как оптимизация. Оптимизация это способ организации алгоритма, т.е. каким именно образом данный алгоритм (или задача, поставленная перед программистом) будет преобразована в машинный код. В случае с Asm'ом, всей оптимизацией занимается сам разработчик. В языках высокоуровневых, оптимизацию берёт на себя транслятор, и разработчик не знает, как будет оптимизирована его программа. Но нужно указать, что трансляторы пишут так же люди весьма умные и оптимизируют они очень и очень хорошо. Разработчику придётся немало потрудиться, дабы добиться такого уровня оптимизации вручную. 

На Asm'е можно писать как под платформу х86 (x86-based PC, те которые мы привыкли видеть, построенные на процессорах архитектуры x86, к этой платформе относятся компьютеры, начиная с IBM PC и заканчивая Pentium IV, а так же все, так называемые клоны), так и под любую технику с цифровым микроконтроллером, так как этот язык представляет собой некий стандарт. Стандарт языка, по которому принято строить языки интерпретации команд процессора. А процессор, как известно, есть и у микроволновой печки, и у стиральной машины, и у всеми любимых телефонов. То есть на Asm'е можно программировать всё, что поддаётся программированию. Но это конечно, если фирма-изготовитель позаботилась о реализации Asm'а под свою микросхему. В противном же случае нам придётся всё-таки иметь дело с машинным кодом, да ещё и со своеобразным. Изучить даже самый распространённый язык процессора, язык процессора x86, будет задачей весьма непростой. Да и не поможет это, так как при переходе на другой контроллер придётся всё переучивать, потому что у каждой микросхемы свой язык, своя система команд. То есть нам помимо Британского придётся изучить и Латиницу. А в следующий раз и Французский и так далее. Поэтому мы выбираем Asm в качестве базового языка. Тем более что Asm, будучи во много раз более удобным, чем язык машинного кода, не снижает быстродействия и не ограничивает разработчика от каких либо возможностей, предоставляемых ему микроконтроллером. Таков стандарт. 

Поскольку Asm полностью отражает структуру программируемого устройства, его реализации под различные платформы так же будут варьироваться, но сам принцип останется прежним. В связи с этим разработчику всё-таки придётся изучать и саму аппаратную часть, которая различается от процессора к процессору. То есть без наречий всё-таки не обойдётся. Здесь, во вводной статье, я не буду расписывать, как и в чём конкретно изменяется Asm внешне, в зависимости от платформы, но разработчики, знающие хотя бы архитектуру x86 уже могут представить, чем он может отличаться. Смею предположить, что их догадки будут верны. И так изучение Asm'а, как указано выше, начинается с изучения платформы под которую разработчик собирается писать и всегда связано с изучением операционной системы и её API. API — Application Programming Interface, интерфейс программирования приложений. Это некая спецификация, с которой так же придётся считаться. Всё это сразу резко отдаляет момент написания первой, пусть даже самой простейшей программы, на неопределённый срок, что очень часто отпугивает начинающих программистов, решивших перейти на Asm. 

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

Что касается нас, мы можем изучать Asm не только для того чтобы писать на нём в чистом виде. Практически во всех языках высокого уровня и студиях осуществлена возможность вставки кусков кода Asmа в высокоуровневую программу. Это делается для достижения максимальной скорости выполнения отдельных участков кода, например в случаях, требующих особой скорости выполнения математических операций или прямого доступа к каким либо аппаратным ресурсам. Плюс само знание Asm'а, даже может без его использования, является неотъемлемой частью знаний настоящего специалиста в программировании и разработчика. Это нужно просто для понимания того, с чем мы работаем. 

Оригинал — 23.04.2005, здесь в редакции от 20.10.2022.

При редакции, некоторые технические и стилистические моменты были оставлены неизменными.

P.S.

Ещё пол года — и эта статья будет совершеннолетней!