Пользователь
0,0
рейтинг
5 января в 13:20

Разработка → STM32F4: GNU AS: Программирование на ассемблере (Часть 1) из песочницы tutorial

Это моя первая статья для сообщества Хабрахабр и написать ее я решил про то что сейчас волнует меня самого: написание программ для микроконтроллеров STM32 (семейство АRМ) на языке ассемблера. Я использую отладочную плату на основе микроконтроллера STM32F407 (STM32F4 Discovery, Open407I-C), но статья будет не менее полезна и для программирования других микроконтроллеров STM32.

После поисков по интернету так и не удалось найти сколь нить понятного для новичка способа написания прошивок для STM32- и ARM- контроллеров вообще на языке ассемблера. Нет, конечно любой поисковик по сочетанию «STM32 ассемблер» дает очень много результатов, но после внимательного их изучения выясняется что 98% результатов поиска ведут на описание сред в которых по заверению производителей языком программирования микроконтроллеров является С, С++, Assembler.

Более того, как только Вы начинаете искать информацию о том как же все таки программировать на ассемблере в конкретной среде для конкретного микроконтроллера — выясняется, что «гуру не пишут проекты на ассемблере», и в средах ассемблер используется максимум для написания процедур и функций требующих максимального быстродействия, или генерации кода содержащего специфические команды микроконтроллера аналог которых не предлагается языком Си (С++ или библиотеками) in-line вставками.

Дальше было еще интереснее, я выяснил что компиляторов ассемблера на ARM платформу существует как минимум два: GNU AS, и ARMASM. И у них различные форматы исходных файлов… Нет, конечно команды ассемблера одинаковые (слава богу), но вот как они пишутся, как указываются операнды, особенно служебные токены — отличаются так, что компиляция без «танцев» исходных файлов GNU AS на ARMASM (и наоборот) становится невозможна. Причем если GNU AS используется в бесплатно распространяемых средах (например CooCox), то ARMASM идет в составе далеко не самой дешевой среды Keil MDK. Насколько мне удалось выяснить для кода размером не более 32 кб среда является бесплатной, но не думаю что 32 кб для 32-разрядного микроконтроллера является каким то выдающимся размером для прошивки: немного кода работающего с дисплеем, немного шрифтов под дисплей, образов иконок — и 32 кб может и не хватить. Сообщество любителей нашло выход — это использование отдельных образов кода по 32 кб и потом объединение их различными способами — но как то хочется нормальной разработки, а не попыток «впихнуть и распределить невпихуемое» (использование пиратских программ мне не интересно). Есть ли ограничение на размер кода у самого компилятора ARMASM или это ограничение Keil MDK — я не стал выяснять, не очень приятно проделать работу основываясь на данных что все бесплатно, и в середине какого нить уже не тестового проекта получить ошибку компиляции из-за ограничений по размеру…

Таким образом, несмотря на то что в сети проектов написанных под ARMASM больше (по крайней мере так мне показалось исходя из результатов поиска), я решил разобраться с GNU AS — который бесплатен для любых размеров прошивок.

В результате поисков ресурсов (другие 2% результатов по запросу «STM32 ассемблер») на тему ассемблера для STM32 я наткнулся на отсутствие какого то начального состояния у многочисленных авторов. У кого то хорошо описаны инструкции ARM, у кого то сделаны попытки раскрыть параметры ассемблера и линковщика, где то описана минимальная (по мнению автора статьи) конфигурация от которой можно оттолкнуться — но вся эта информация так раскидана — что для начального вхождения практически не пригодна, тем более когда в проекте появляется что-то новое и вы просто не понимаете какие исправления нужно внести чтобы все «заработало»… Особенно тяжело если вы раньше не задумывались о том что делает IDE при компиляции ваших проектов. Теоретически конечно все представляют, что есть ассемблер, линковщик и другие вспомогательные утилиты, но вот какие файлы настроек, ключи для запуска, файлы для работы нужны — все это как то на уровне «ликбеза».

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

Я постараюсь описать все более менее последовательно, чтобы Вы могли не только просто повторить то, что я сделал, но и сделать собственные настройки для своего микроконтроллера, а так же менять эти настройки когда это будет необходимо (это пожалуй самое главное!). Вообще не думаю что все что я написал нужно повторять — просто внимательно прочитайте! Это тот путь который вы должны были бы пройти если бы начинали разбираться во всем сами. Я не буду описывать каким образом я дошел до того или иного шага, это сборная «солянка» от поиска в интернете, просмотра примеров других авторов, разбирательства в файлах которые генерирует CoIDE (CooCox), это не интересно и не нужно, но то что узнал в ключевых моментах, и что реально будет нужно для написания своих проектов я постараюсь отметить.

Для начала необходимо скачать пакет разработчика GNU GCC (из него можно взять программы компилятора ассемблера), это можно сделать например отсюда (справа выбираем пакет в зависимости от операционной системы).

Этот пакет можно распаковать на диск (я распаковал в каталог gcc каталога CooCox, у меня этот пакет используется и для программирования в среде CooCox).



Нужные нам файлы я выделил:


Теперь небольшое отступление для тех кто не задумывался о том как происходит преобразование написанной программы в исполняемый код.

Программа написанная в текстовом редакторе (это может быть как блокнот, так и среды разработки по типу CooCox, Keil) сначала компилируется ассемблером.

Все более менее серьезные программы состоят из различных частей которые размещаются в разных исходных файлах программы, эти части могут иметь различное назначение (код, константы, данные), располагаться в различных областях памяти (FLASH, SRAM, Backup SRAM и т. д.) — поэтому мало просто откомпилировать программу, нужно еще правильно расположить ее части в памяти микроконтроллера. Этим важным делом занимается линковщик — в зависимости от схемы линковки он располагает части программы по так называемым сегментам которые и представляют собой различные области памяти микроконтроллера.

Нам осталась самая малость: разобраться как скомпилировать и как распределить части нашей прошивки.

Здесь очень желательно чтобы вы представляли с чего начинается исполнение программы у микроконтроллера STM32F4, если это не откровение для вас можете пропустить пару абзацев:

При включении микроконтроллер:

  1. По адресу 0х0800 0000(*) загружает значение регистра указателя стека SP. Обычно стек начинается с конца доступной RAM и при заполнении движется от старших адресов к младшим
  2. По адресу 0x0800 0004 загружает значение регистра PC (Program counter) — то есть фактически осуществляет переход по адресу указанному по адресу 0x0800 0004
  3. Осуществляется исполнение программы по адресу загруженному в PC

(*) Адреса разделены пробелом для удобства чтения, в программах правильно писать конечно же 0x08000000

Исходя из выявленных шагов находим в документации на контроллер в каких адресах располагается SRAM у STM32F4 (или у Вашего микроконтроллера, так как различные микроконтроллеры имеют различный объем памяти). Для моего микроконтроллера открываем «RM0090 Reference manual» (для других микроконтроллеров ST посмотрите здесь).



Смотрим оглавление на предмет «чего нить про память»:



Идем на страницу 59



Внимательно читаем! У нашего микроконтроллера есть два банка памяти SRAM1 и SRAM2 размерами 112 кб и 16 кб. Другая интересующая нас информация находится на странице 68.



У микроконтроллера проекта STM32F407 фактически 3 блока памяти расположенных в разных областях адресного пространства:

  • объединенный блок SRAM1 и SRAM2 начинающийся с адреса 0x2000 0000 и имеющий размер 112 кб + 16 кб (всего 128 кб)
  • отдельный блок CCM — начинающийся с адреса 0x1000 0000. Согласно написанному «на борту» у контроллера 192 кб — следовательно блок CCM у нас на 64 кб.
  • Отдельный блок backup SRAM размером в 4 кб

Не стоит обвинять разработчиков микроконтроллера в раскидывании памятью по адресному пространству — эти 3 разных блока памяти исполняют различные функции:

  • SRAM1 и SRAM2 — хранение переменных и данных
  • CCM — хранение переменных и данных, а так же программ исполняющихся из оперативной памяти (!)
  • backup SRAM – хранение переменных и данных с питанием от внешней батареи энергонезависимого питания. В микроконтроллере STM32F4 нет энергонезависимой памяти для хранения констант, и предложен способ хранения переменных в ОЗУ с питанием контроллера от миниатюрной батарейки (типа часовой) с минимальным потреблением

Возьмем банки памяти SRAM1 и SRAM2 и в их конце разместим стек. Вычислим адрес последней ячейки стека:
0x2000 0000 + 128kб = 0x2000 0000 + 0x0002 0000 = 0x2002 0000

Таким образом указатель стека нужно будет установить на значение 0x20020000. Получаем следующую «карту» памяти:
Адрес Значение
0x08000000 0x20020000

Со вторым пунктом проще — мы укажем адрес следующий после нашей таблицы переходов. Поскольку один указатель у нас занимает 4 байта, таких указателей у нас 2 — получается что программу мы можем начинать писать с адреса 0x08000008.

Получаем следующую табличку:
Адрес Значение Примечание
0x08000000 0x20020000 Значение для загрузки в SP (указатель стека)
0x08000004 0x08000008 Значение для перехода по сбросу (включению)

Значения указателей 4-х байтные, формат этот называется word (это вам должно быть известно из курса программирования на любом языке)

Теперь немного «шаманства». Дело в том что платформа ARM имеет очень большое количество микропроцессоров, с различными форматами команд. Для того чтобы определить какой формат команды используется используются 2 младших бита адреса команды. Так вот младший бит установленный в «1» показывает, что команда подлежащая исполнению указана в формате Thumb. В случае, если оба младших бита сброшены — микропроцессор считает что нужно исполнить команду в формате ARM. Для микроконтроллеров STM32 при осуществлении переходов допустим только набор команд Thumb! В случае если мы попробуем «заставить» микроконтроллер перейти на команду в формате ARM — произойдет ошибка!

Если посмотреть двухзначное представление полученного нами адреса то мы увидим что в нашем адресе «закодирована» система команд ARM.

Младший байт адреса (0x08) в двоичном виде:
Бит 0 1 2 3 4 5 6 7
Значение 0 0 0 0 1 0 0 0
Полубайт 0 8

А должно быть:
Бит 0 1 2 3 4 5 6 7
Значение 0 0 0 0 1 0 0 1
Флаг типа команды часть адреса Флаг
Полубайт 0 9

Фактически добавление младшего бита установленного в «1» — это просто увеличение адреса на 1.
Запоминаем правило: при указании указателей в таблице векторов прерываний необходимо увеличивать значение адреса на 1

В качестве программы будем использовать примитивный бесконечный цикл. Чтобы не отправлять Вас в «копание» в документации — это команда «B».

Если вы задумались об ассемблере, или писали на ассемблере для AVR (или i8080, или Z80), то наверное команда «JMP» восьмибитников вам знакома, так вот «B» ее аналог.

Получается что наша программа должна выглядеть следующим образом:

.word  0x20020000 @ Указатель вершину стека

.word  Reset + 1      @ Указатель на программу

Reset:			B Reset

Займемся средой компиляции. Компилятор ассемблера имеет название arm-none-eabi-as.exe. Вызывая компилятор мы должны указать ему файл нашей программы, и файл в который он должен сохранить результат компиляции. Если запустить компилятор с ключем —help, можно найти какие для этого нужны ключи, берем минимально необходимый ключ :

arm-none-eabi-as.exe -o <файл результат> <файл исходник>

Нашу программу мы разместим в файле main.asm. Файл-результат работы компилятора называется «объектный файл», общепринятое расширение таких файлов «.о» — пусть будет называться main.o. Таким образом компилятор мы вызовем строкой:

arm-none-eabi-as.exe -o main.o main.asm

Но это еще не все (к сожалению) — дело в том что этот компилятор может быть использован для различных семейств и типов микроконтроллеров и процессоров и мы до сих пор не указали ему какой же микроконтроллер собираемся использовать. Исходя из того что нам сообщает сам компилятор его устроит указание семейства cortex-m4.

Указать можно двумя путями:

  1. Указать при компиляции при помощи ключа «-mcpu=cortex-m4»
  2. Указать в тексте программы строкой «.cpu cortex-m4»

Дополнительно нужно указать систему команд которую мы будем использовать: «.thumb». Ну и еще дополнительно указывается параметр «.syntax unified» — этот параметр задает некоторые особенности при написании программы, например, разрешает перед числами не ставить префикс «#», иногда не писать вручную некоторые инструкции ассемблера (IT) — компилятор это будет делать за нас (в случае необходимости) и так далее (в этом будем разбираться позже). Почитать дополнительно об этом можно здесь.

Получаем следующую программу:

@GNU AS – просто комментарий в котором указываем компилятор (для себя)

@ Настройки для компилятора:
.syntax unified
.thumb                 @ тип используемых инструкций Thumb
.cpu cortex-m4    @ семейство микроконтроллера 

@ Наша программа:
@ Таблица указателей перехода которая должная быть размещена с адреса 0x08000000
.word	0x20020000	@ Стек
.word	Reset+1	@ Адрес перехода при сбросе. 
			@ Внимание! Для корректности работы необходимо к адресу
			@ прибавить "1" - это показывает процессору что команда
			@ по адресу перехода будет в формате Thumb (а не ARM),
			@ если этого не сделать, то микроконтроллер 
			@ будет уходить в ошибку (в прерывание Hard Fault)

@ Наша программа (должна быть размещена после таблицы указателей переходов)
Reset:			B Reset

Теперь, запустив компилятор командой:

bin/arm-none-eabi-as.exe -o main.o main.asm 

мы увидим что в папке появился файл main.o — таким образом компиляция прошла успешно, объектный файл создан.

Небольшое отступление:
Для удобства я поместил все программы пакета разработчика в отдельный каталог bin в папке проекта (объем всего около 5 мб), а сам запуск компилятора делаю из .bat файла make_project.bat, поскольку компилятор оставляет сообщения об ошибках в консоле — удобнее всего запускать bat файл из FAR.



Для полноты привожу содержимое файла make_project.bat на данном этапе:

CLS

:: Компиляция
bin\arm-none-eabi-as.exe -o main.o main.asm

Теперь из файла main.o при помощи программы-линковщика нужно сделать файл прошивки. Для программы-линковщика необходим файл настройки в котором собственно говоря и будет описано какую часть нашей программы куда нужно поместить.

Здесь могу рекомендовать почитать статью на этом же ресурсе habrahabr.ru/post/191058 — там можно найти один из примеров карты линковщика, есть и другие ресурсы где можно посмотреть какими бывают файлы линковщика, но к сожалению простых решений нигде не предлагается.

Один из самых простых файлов линковщика приведенный по ссылке выше выглядит так:

MEMORY {
       rom(RX) : ORIGIN = 0x00000000, LENGTH = 0x8000 
       ram(WAIL) : ORIGIN = 0x10000000, LENGTH = 0x2000 
} ENTRY(public_function) 
SECTIONS { 
       .text : { *(.text) } > rom 
       _data_start = .;
       .data : { *(.data) } > ram AT> rom 
       _bss_start = .;
       .bss : { *(.bss) } > ram 
       _bss_end = .; 
} 

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

ИТАК, первое и самое заметное: карта линковщика состоит как бы из двух больших секций MEMORY и SECTIONS
В первом блоке (MEMORY) указывается какая память установлена в микроконтроллере, в каких адресах, и какого размера. Адреса и размеры SRAM мы уже выясняли, а вот для FLASH памяти эту информацию нужно поискать в том же «RM0090 Reference manual» или просто вспомнить сколько flash памяти у вашего микроконтроллера (например по полному наименованию микроконтроллера).

После указания имени типа памяти (произвольно, кто то пишет ROM / RAM, кто то MEMORY, я пишу FLASH / SRAM) указываются режимы доступа к памяти: для FLASH памяти R — чтение, X-исполнение. И далее начальный адрес памяти в адресном пространстве и размер.

Должно получиться примерно так:

MEMORY {
	FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 1024kb 
}

Далее идет определение областей или секций. Как вы могли уже прочитать по ссылке выше — основные секции прошивки имеют имена:
  • .text – исполняемый код (размещается во FLASH)
  • .data – переменные (размещаются в SRAM)
  • .rodata – константы (размещаются во FLASH)
  • .bss – переменные с нулевым значением при старте (SRAM)

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

Конструкция блока SECTIONS в общем виде строиться следующим образом:

.text : { /* <--- Тип секции: исполняемый код, в прошивке */
       *(.text);  /*<-- Тип секции в main.asm */
       *(.code);  /*<-- Тип секции в main.asm */
       *(.flashdata);  /*<-- Тип секции в main.asm */
       *(.datar);  /*<-- Тип секции в main.asm */
} > FLASH  /* Размещать в памяти FLASH */

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

Пока вам (и мне) повезло, у нас только одна секция прошивки и одна секция исходного файла — исполняемый код.

Получаем следующее:

/* STM32F40x, flash 1 mb, sram 192 kb, bkpsram 4 kb */

MEMORY
{
	/* FLASH - Программная flash память */
	FLASH      (RX)  : ORIGIN = 0x08000000, LENGTH = 1024K

}
SECTIONS
{
	.text : { /* Секция прошивки */
		*(.text);   /* Секция исходников */
	} > FLASH
}

Примечания пишутся внутри скобок /* */, все примечания пишутся «для себя» и «чтобы не забыть». Этот текст карты линковщика я поместил в файл stm32f40_map.ld.

Я намеренно упростил нашу карту линковщика по максимуму чтобы вы могли понять идею ее написания. Несмотря на упрощение (которое наверняка мне не простят «гуру» программирования и напишут в комментариях, что так писать нельзя) эта карта линковщика для нашего примера полностью работоспособна (а иначе не стоило и мучаться с ее написанием)!

Теперь, коль у нас появились секции — совершенно очевидным становиться необходимость указания в прошивке что и к какой секции относиться! Делается это при помощи команды .section, секция у нас одна .text, правим наш main.asm.
Секция «вроде бы» должна заканчиваться командой «.end», я еще не выяснил до конца нужна это команда на самом деле или нет и поэтому добавил в конце.

Файл исходного текста нашей программы теперь выглядит вот так:

@GNU AS

@ Настройки компилятора arm-none-eabi-as.exe
.syntax unified
.thumb            @ тип используемых инструкций Thumb
.cpu cortex-m4    @ процессор

@ Наша программа
.section .text

.word	0x20020000	@ Стек
.word	Reset+1		@ Адрес перехода при сбросе. 
			@ Внимание! Для корректности работы необходимо к адресу
			@ прибавить "1" - это показывает процессору что команда
			@ по адресу перехода будет в формате Thumb (а не ARM),
			@ если этого не сделать то младшие линейки (F0, F1) 
			@ будут уходить в ошибку (в прерывание Hard Fault)

@ Наша программа (должна быть размещена после таблицы указателей переходов)
Reset:			B Reset

.end

Еще одно отступление: для нашего примера можно не указывать секции вовсе! Дело в том, что если секции не указаны, то при компиляции и последующей линковке будет выбрана «самая подходящая»… Конечно не стоит надеяться на компилятор и лучше самостоятельно указывать что и где должно быть размещено.

Линковщик это утилита arm-none-eabi-ld.exe, при попытке запросить помощь запуская линковщик с ключем -–help выходит не маленькая «портянка», но мы не будем строить монстроидальный запуск, нам нужно только сделать линковку полученной после ассемблера прошивки.

Используем ключ -T для указания файла карты памяти, и ключ -o для задания имени файла-прошивки, это будет файл с расширением .elf.

Чтобы руками не набирать правим наш make_project.bat:

CLS
:: Компиляция
bin\arm-none-eabi-as.exe -o main.o main.asm

:: Линковка
bin\arm-none-eabi-ld.exe -T stm32f40_map.ld -o main.elf main.o


После запуска у нас появляется файл с расширением .elf.

Теперь нужно сделать остановку и поразмыслить — а что же мы получили? Ну да, ассемблер «что то» скомпилировал (файл main.o), а линковщик на основании этого сделал «какую-то» прошивку (файл main.elf), но как нам проверить, что у нас получилось?

По логике действий мы должны залить прошивку в микроконтроллер и посмотреть на результат… И тут мы вспоминаем что прошивка то у нас ничего не делает — поэтому никакого мигающего светодиода не будет! Вообще ничего не будет! Внешне, по пинам микроконтроллера мы не узнаем работает он, или прошивка оказалась ошибочной — и он завис.

По нашей программе проверку работы микроконтроллера пока сделать нельзя. А что можно? — с файлом прошивки .elf — мы даже не можем посмотреть что и куда линковщик расположил (посмотреть хотелось бы не утилитами, а чем нить вроде того же FAR, чтобы уж «точно и железно», перед тем как мы пойдем дальше нужно быть уверенными что на текущий момент все сделано верно).

Значит нужно сделать из прошивки .elf прошивку в формате .bin. Бинарный формат прошивки это фактически байты которые будут загружены в контроллер.

Сделать это можно при помощи утилиты arm-none-eabi-objcopy.exe. Ключем -O мы задаем формат который мы хотим получить, допустимы 2 значения: binary и ihex. Правим наш make_project.bat:

CLS
:: Компиляция
bin\arm-none-eabi-as.exe -o main.o main.asm

:: Выполняем линковку 
bin\arm-none-eabi-ld.exe -T stm32f40_def.ld -o main.elf main.o

::Выделяем из .elf файла - файл прошивки .bin  
bin\arm-none-eabi-objcopy.exe -O binary main.elf output.bin

Запускаем и получаем «вожделенный» файлик output.bin. Размер файла output.bin 10 байт, в FAR можно запустить его просмотр (F3) и в этом режиме переключиться в просмотр кода (F4):



Вот теперь нам есть что анализировать:

  1. В .bin прошивке не указываются адреса по которым происходит «заливка» прошивки в микроконтроллер — этот параметр указывается при программировании (в нашем микроконтроллере STM32F407 начальный адрес должен быть 0x08000000)
  2. Мы планировали что прошивка начнется с таблицы указателей переходов, первый указатель — SP, на конец SRAM1 и SRAM20x20020000. В прошивке идут байты 00 00 02 20 — вспоминаем (или узнаем сейчас) что все данные идут в порядке «младший — старший») и переворачиваем наши байты прошивки переписывая их побайтно справа-на-лево: 20 02 00 00 — вектор SP указан верно !
  3. После указателя SP должен идти вектор сброса: смотрим: 09 00 00 08, переворачиваем и получаем адрес для перехода: 08 00 00 09 — тоже правильно!
  4. Далее идет код команды на языке ассемблера. Я бы рад вам подсказать способ дизассемблирования команды по ее коду — но к сожалению пока такого ресурса не знаю… Поэтому доверяю тому что получилось и считаю что сочетание E7 FE (я уже перевернул байты!) — это и есть наша строчка кода: «Reset: B Reset»

Нашел все таки документ в котором описано как кодируются команды ARM. Скачать можно по ссылке ARMv7-M Architecture Reference Manual.

Смотрим оглавление:



У нас код команды E7 FE — 16-ти битный, значит сразу идем на страницу 127, где будут определены старшие биты команд:

<img src="

Код нашей команды: 1110 0111 1111 1110, в указанном выше списке это последняя строчка «11100x Unconditional Branch, see B on page A7-207», значит идем на страницу 207.

image

Следовательно закодирована команда B относительным адресом 111 1111 1110. Как рассчитать адрес перехода можно понять из этого документа
у нас получается:

0x0800 0008 — 0x0800 000C= 0xFFFF FFFC (1111 1111 1111 1111 1111 1111 1111 1100) или -4

Кодируем -4 при помощи 12 бит: 1111 1111 1100. Теперь берем старшие 11 бит — и это будет поле смещения адреса:

1111 1111 1100 => 111 1111 1110

Наша команда полностью:

(код команды)=11100 (адрес)=111 1111 1110 => разобьем «по правильному»: 1110 0111 1111 1110 = E7 FE

На этом текущее повествование прекратим и подведем итоги:

  1. Мы нашли файлы необходимые для компиляции проектов на языке ассемблера для микроконтроллера STM32F407
  2. Выбрали необходимые ключи компиляции и настройки компилятора
  3. Начали разбираться с картой памяти линковщика, и выяснили какие ключи необходимо использовать для линковки
  4. Получили файл прошивки, преобразовали этот файл в более понятный нам binary
  5. Мы проверили правильность формирования таблицы переходов, кода программы, размещения программы в прошивке на файле формата binary

В следующей статье будем писать прошивку микроконтроллера чтобы реально проверить его работу — будем мигать светодиодом!

Часть 2: STM32F4: GNU AS: Мигаем светодиодом (Оживление)
Горбуков Виталий @VitGo
карма
36,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (40)

  • +2
    Программировать STM32 ассемблере это как есть гречневую кашу пинцетом по одному зёрнышку. Если цель просто писать программы для STM32, то вам крайне необходимо осознать ущербность писанины на ассемблере и как можно скорее перейти на С/С++.
    • 0
      Полностью с Вами согласен ! именно пинцетом, и именно по одному зернышку!!!

      Я любитель, и написание программ на ассемблере это мое хобби (на жизнь зарабатываю совершенно другим, к программированию, компьютерам, микроконтроллерам отношения не имеющем) Мне очень нравиться ассемблер, тем более с системой команд ARM!
      • 0
        а какая ваша основная работа, если не секрет, если программирование на asm под STM32 только хобби?
        • +5
          Управляющий Закрытыми паевыми фондами недвижимости в Управляющей компании (это из области доверительного управления имуществом)…

          В провинции программисты не нужны (нужны только настройщики 1С, администраторы (да и то это все крупные компании админят из Москвы/Питера, удел местных «администраторов» обеспечить канал для настройки), установщики Windows, «сниматели» банеров — и все это вряд ли способно дать более менее заметный доход… ну или дает конечно доход, но единицам и пробиться в эти «круги» не так просто и к сожалению собственный профессионализм при этом роли не играет)
      • +2
        Что ж, достойное хобби! Если вы ещё и Си знаете на достойном уровне то тогда вообще супер.
        Статья кстати тоже достойная.
        • 0
          нет, к сожалению в Си я слабак :-(
          а вот в асме всегда любил «по извращаться», а сколько исходников было потеряно (у меня тут винда-10 «обновила» комп до состояния нового..:-( а архивы как раз на компьютер сбросил чтобы отсортировать...)
          • 0
            нет, к сожалению в Си я слабак :-(

            Вот поэтому я ещё раз вам крайне советую всё таки освоить си (пусть без плюсов), гарантирую после вам уже не будет так нравится ассемблер.
            ЗЫ Это из личного опыта… Собственно поэтому и написал слегка «резковатый» первый комментарий.
            • 0
              все это прекрасно понимаю, на си пишу понемногу…

              но поскольку у меня это занятие хобби и ничего более (по крайней мере пока) — поэтому пишу и на ассемблере…
              с ассемблером я с 1993 года, и честно говоря ни на что его менять не хочу, тем более что ассемблер ARM мне очень нравиться набором инструкций

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

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

                Кстати интересно еще посмотреть на реальных проектах насколько широко используются разные инструкции в случае программы написанной на ассемблере и сгенерированной с ЯВУ.
                • 0
                  не знаю как у вас, но у меня дедлайн еще никогда не ускорял проект… скорее даже наоборот — необдуманные решения примененные из-за спешки способны убить проект впоследствии возникающими «родовыми» травмами…
                  На счет абстракции: на ассемблере вполне можно написать отдельные подпрограммы, с тем или иным функционалом, и потом объединить в каком то алгоритме… да на Си выходит проще, да на СИ проще писать переносимый код (хотя я не видел переносимого кода, кроме случаев когда он состоит из операторов самого языка СИ), проще работать в команде (возможно! но не факт), очень много сред с различными возможностями...
                  — не хочу холивара, я пояснил свою позицию — я не зарабатываю денег написанием программ, и могу себе позволить разбираться с тем языком который мне нравиться (сегодня придумал способ простой инициализации микроконтроллера, в ближайшее время попробую написать). Если будут люди которым это интересно (именно для этого я здесь) — то с удовольствием объединю усилия (есть у меня пара задач которые нужно решить)… пока (судя по количеству комментариев ко второй части публикации — таковых нет :-(… так что буду «развлекать» вас только собственной персоной…

                  ну в общем то у каждого семейства процессоров свои команды, мне после Z80 с его LD по всем случаям ассемблер I8080 казался больно мудреным :-) потом ассемблер x86 — опять другие команды, потом AVR — и все более менее знакомо (уже как говориться все повидал, все попробовал) хотя конечно после первых трех уже особо не грузишься, просто запоминаешь новые мнемоники…

                  а вот ассемблер ARM — это что то действительно новое… на счет сложности — сложно пока не начинаешь разбираться… вообще по моему мнению некоторые вещи очень и очень правильны

                  На счет разных систем команд — все не так страшно, команды одни и те же, просто есть их 32ух битное и 16ти битное кодирование… в принципе по началу об этом можно не задумываться, при желании потом можно провести оптимизацию кода…
                  • 0
                    Кстати, различие LD и MOV для Z80 были только в старых книжках, а более новые в т.ч. и зарубежные заменяют всё это одной командой MOV хотя это не отражает сути самих команд, но видимо они там думают чем меньше разнообразия в написании команд тем легче будет студентам выучить их…

                    Возможно, ассемблер ARM разрабатывался с целью лёгкости машинной оптимизации а не написания программ человеком.
                    • 0
                      я не видел док по Z80 где команды были бы представлены в формате I8080 (то что первый проработка второго знаю, историю создания читал)…

                      на счет ассемблера ARM — мне трудно судить почему у вас о нем такое мнение… :-(
  • +6
    Статья получилась хорошая, но на мой взгляд в ней не хватает одной важной вещи.
    выясняется, что «гуру не пишут проекты на ассемблере», и в средах ассемблер используется максимум для написания процедур и функций требующих максимального быстродействия, или генерации кода содержащего специфические команды микроконтроллера аналог которых не предлагается языком Си (С++ или библиотеками) in-line вставками.

    А в самом деле — зачем писать всю прошивку на ассемблере?
    • +3
      Потом дизассемблировать проще :-)

      Довелось мне как-то раскуривать загрузчики PalmOS на несколько древних уже Palm Tungsten T3 и Palm LifeDrive. У первого набортовой оперативки не было, и бóльшая часть загрузчика была весьма читабельным листингом, было видно «поток сознания» автора. У LD процессор был уже поновее, с оперативкой, так что ассемблерный кусок настраивал стек, а дальше начинался страх и ужас оптимизированного кода от g++.
  • +2
    Статья классная, на мой взгляд. Сам некоторое время писал на ассемблере под STM32F103 и К1986ВЕ92QI (Миландр, но ядро то же). Довольно интересно было. Но сейчас на работе пишем исключительно местными обертками основанными на HAL (таковы правила). Так что производительность иногда очень страдает. Зато читабельность многократно выше. Жду продолжения.
  • +1
    Отличная статья, годится не только для контролероа STM. Очень хочу почитать чуть больше о файле линковщика, конечно, в инете есть инфа по этому вопросу, но вы все так хорошо описываете :)
  • +1
    То, что часто не описывают набор инструкций, связано с тем, что programming manual вполне полно это делает и нет никакой необходимости его переписывать.

    Про магические адреса около 0x0800 0000, то memory mapping определяется состоянием BOOT0 и BOOT1, что описано в reference manual, 2.4. Загрузка всегда начинается с адреса 0x0000 0000, куда при BOOT0 = 0 маппится flash memory (0x0800 0000 — 0x080F FFFF), а при BOOT0 = 1 и BOOT1 = 0 — system memory (0x1FFF 0000 — 0x1FFF 77FF).

    Также, использовать адреса 0x0000 0008 — 0x0000 0040 (т. е. и 0x0800 0008 — 0x0800 0040) не стоит, это адреса векторов exception handler'ов. Если используется NVIC, то таблица прерываний будет продолжаться и после 0x0000 0040 с шагом 4 на каждое прерывание. Рекомендуется не трогать кусок памяти до 0x0000 03FC включительно, см. 2.3.4 в programming manual.
    • 0
      Спасибо за информацию! учту!

      К слову, что мне пока не очень удобно в документации ST — так это очень большая фрагментированность документации… не всегда понятно где же все таки будет написано искомое :-) потом, когда найдешь, вроде бы начинаешь логику понимать, но вот с «нуля» — очень не удобно искать иголку в стоге сена…

      Про таблицу прерываний в курсе, первая программа в статье — это просто проверка возможности написания и компиляции…
  • 0
    Статья — хороший бочонок меда начинающим для вхождения в тему.
    Ложка дёгтя — слова «линковщик»\«линковка» вместо более традиционных «компоновщик»\«компоновка».

    Такое особенно вредно для начинающих — в комментариях уже цитируют…
    • +3
      Традиционно — линкер (linker) ;) Мне так привычнее ещё со времён DOS, Borland Turbo Pascal и Turbo C.
  • 0
    Писать всю прошивку на ассемблере наверное нужно очень редко, но вот разобраться в том, как именно создаётся образ прошивки — это безусловно полезно.

    Только один комментарий:
    В следующей статье будем писать прошивку микроконтроллера чтобы реально проверить его работу — будем мигать светодиодом!
    Надеюсь, что исходники прошивки из следующей статьи будут выложены в удобном для скачивания и обновления виде, например, в виде репозитория на github.

    • 0
      в виде ссылки на яндекс.диск подойдет? там не просто обновлять придется — у меня плата отладочная не stm32f4 discovery — так что без желания и активных действий мигать «из коробки» ничего не будет.

      p.s. вторая статья уже написана и лежит в черновиках, но еще не вычитал :-( обычно когда печатаю допускаю много оЧеПяток, стыдно такое выкладывать… постараюсь завтра разместить, а там уж как модерацию пройдет (эта статья висела 5 дней на модерации в песочницу, я ее потихоньку правил пока админы собирались смотреть)
      • –1
        Дальше оно без модерации, сразу выкладывается. А так в песочнице иногда и по несколько месяцев статьи висят.
      • +2
        Никаких Я.Дисков! Никаких рарчиков! Освойте уже нормальные процессы разработки о обмена исходниками! Тоже мне, рарчики. У нас 2016 год за бортом, а у вас — рарчики. Стыдобень!
      • 0
        в виде ссылки на яндекс.диск подойдет?
        Выкладывать исходные тексты таким образом можно только в случае крайней нужды.

        Советую не пожалеть времени и освоить git!
        Начать можно с Good Resources for Learning Git and GitHub.
  • 0
    Низкоуровневое программирование контроллеров это интересно, стильно, молодежно. Я как то задался целью написать минимальное приложения для STM32 на С без использования ассемблера и сторонних библиотек. Вот что получилось github.com/anatol/stm32f4-examples/tree/master/native/blink01
    • 0
      какой размер получился? (по файлу binary)
      у меня оптимизированная мигалка одним светодиодом заняла 68 байт (та что во второй части статьи, написана «в лоб» для понимания, имеет размер — 116 байт)
      • +1
        На AVR минимальная программа — мигалка состоит из одной инструкции.
        • 0
          :-) прикольный «изврат»
          но речь все таки о программе…
        • 0
          кстати, в комментариях правильно написали: программа не из одной инструкции, а из 1024 ! :-) так как первая инструкция включает/выключает светодиод, а остальные служат для организации задержки :-)))
  • +1
    По-моему objdump c нужными ключами умеет дизассемблировать код.
    • 0
      Для STM32 бинарников использую

      arm-none-eabi-objdump -D -marm --disassembler-options=force-thumb --target binary $INPUT > $OUTPUT
  • 0
    он показывает информацию по секциям…
    в этой публикации цель простота и понятность (до сложного дойдем еще), а так вы правы, например, может быть такая «конструкция»:
    :: Отдельно информация о каждой секции в файл (вывод в файлы)
    bin\arm-none-eabi-objdump.exe  -j .vectors -t -w compile\temp\sys.o > compile\temp\main_vect.lst
    bin\arm-none-eabi-objdump.exe  -j .text -d -t -w compile\temp\sys.o > compile\temp\main_text.lst
    bin\arm-none-eabi-objdump.exe  -j .rodata -d -t -w compile\temp\sys.o > compile\temp\main_rodata.lst
    bin\arm-none-eabi-objdump.exe  -j .bss  -d -t -w compile\temp\sys.o > compile\temp\main_bss.lst
    bin\arm-none-eabi-objdump.exe  -j .ccmdataram -d -t -w compile\temp\sys.o > compile\temp\main_ccm.lst
    bin\arm-none-eabi-objdump.exe  -j .bkpsram -d -t -w compile\temp\sys.o > compile\temp\main_bkpm.lst
    
  • +2
    Каждый, кто писал свой бутлоадер для STM32, по-любому должен был столкнуться с асмом. Немножко так, но достаточно для того, что бы запомнить как начинает работать STM32, откуда берет стек, откуда загружает PC, и как называется команда перехода на ассемблере. Ну и немножко потанцевать с бубном вокруг таблицы векторов прерываний, особенно на младших семействах типа stm32f030. А дальше быстро уйти обратно в Си.

    Имхо — ARM не доставляет много фана в программировании на ассемблере. Потому что много за чем нужно следить, много периферии, много настроек — внимание распыляется по пустякам, а когда дело доходит до кодинга, то уже и кодить не хочется, потому что замучался тонны строк инициализации копипастить, да еще и ошибся при копипасте и сидишь разбираешься в какой бит положил 1 вместо 0 в одном из сотен 32-битных регистров.

    Другое дело 8-битки, да. Меня «прет» иногда покодить что-то для PIC16… А сколько вообще интересных винтажных платформ — 6502, 6809, 8080б 8041… Взять какую-нибудь денди (6502) и закодить для нее демку — вот это было бы здорово. Или из АОН на 8035 сделать часики и термометр. Ну или просто добавть в прошивку поддержку CallerID -)
    • 0
      то есть вы тоже сторонник SPL?
      года два назад когда я писал программы с использованием SPL мне постоянно говорили что это как то по детски и профессионалы всегда пишут в регистры напрямую без всяких прокладок :-)))

      а на счет инициализации — у меня она вообще теперь выглядит как список, для мигалки так:
      Настройка GPIOH PH2/3
      @ ***************************************************************************
      @ * Список конфигурации для мигалки *
      @ ***************************************************************************
      @ * для порта GPIOH выводов PH2, PH3 *
      @ ***************************************************************************
      .word 0x00000011 @ Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_AHB1ENR)*32+RCC_AHB1ENR_GPIOHEN_N*4

      .word 0x00000003 @ value ORR (mask AND [adress])
      .word PERIPH_BASE + GPIOH_BASE + GPIO_MODER
      .word ~(GPIO_MODER_MODER3+GPIO_MODER_MODER2)
      .word GPIO_MODER_MODER2_0 + GPIO_MODER_MODER3_0

      .word 0x000000FF @ конфигурация завершенa

      а например для настройки тактирования так:
      Тактирование STM32F4 168 мгц
      @ ***************************************************************************
      @ * Список конфигурации SYSCLK 168 MHz Standard *
      @ ***************************************************************************
      @ * Конфигурация HSE ( 8Мгц) + PLL, со стандартными значениями множителей *
      @ ***************************************************************************
      @ * НАСТРОЙКИ *
      @ * — - — - — - — - — - — - — - — - — - — - — - — - — - — - — - — - — - — - *
      @ * значения делителей и множителей *
      @ * *
      @ * PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N *

      .equ MOD_INIT_SYSCLK_168STD_PLL_M, 8
      .equ MOD_INIT_SYSCLK_168STD_PLL_N, 336

      @ * Частота тактирования процессора (AHB), документированная 168 мгц *
      @ * SYSCLK = PLL_VCO / PLL_P *
      @
      .equ MOD_INIT_SYSCLK_168STD_PLL_P, 2

      @ * Такт для USB (должен быть 48 мгц для нормальной работы) *
      @ * USB OTG FS, SDIO and RNG Clock = PLL_VCO / PLLQ *
      @
      .equ MOD_INIT_SYSCLK_168STD_PLL_Q, 7

      @ ***************************************************************************

      @ — Дальше настроек нет!!! — @ значение для загрузки в RCC_PLLCFGR
      .equ MOD_INIT_SYSCLK_168STD_PLLCFGR, MOD_INIT_SYSCLK_168STD_PLL_M|(MOD_INIT_SYSCLK_168STD_PLL_N<<6)+(((MOD_INIT_SYSCLK_168STD_PLL_P>>1)-1)<<16)+RCC_PLLCFGR_PLLSRC_HSE+(MOD_INIT_SYSCLK_168STD_PLL_Q<<24)


      @ включение HSE
      .word 0x00000011 @ Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_CR)*0x20+RCC_CR_HSEON_N*4

      @ ожидаем стабилизации частоты кварца
      .word 0x00000021 @ Wait Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_CR)*0x20+RCC_CR_HSERDY_N*4

      @ включаем Power control
      .word 0x00000011 @ Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_APB1ENR)*0x20+RCC_APB1ENR_PWREN_N*4

      @ выходим из режима энергосбережения
      .word 0x00000011 @ Bitband 1
      .word PERIPH_BB_BASE+(PWR_BASE + PWR_CR)*0x20+PWR_CR_VOS_N*4

      @ Установим делитель шины APB2
      .word 0x00000011 @ Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_CFGR)*0x20+RCC_CFGR_PPRE2_DIV2_N*4

      @ Установим делитель шины APB1
      .word 0x00000002 @ str value, ORR [adress]
      .word PERIPH_BASE+RCC_BASE+RCC_CFGR
      .word RCC_CFGR_PPRE1_DIV4

      @ Установка коэффициентов PLL
      .word 0x00000001 @ str value, [adress]
      .word PERIPH_BASE+RCC_BASE+RCC_PLLCFGR
      .word MOD_INIT_SYSCLK_168STD_PLLCFGR

      @ Включаем PLL
      .word 0x00000011 @ Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_CR)*0x20+RCC_CR_PLLON_N*4

      @ Ожидаем готовности PLL
      .word 0x00000021 @ Wait Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_CR)*0x20+RCC_CR_PLLRDY_N*4

      @ Настройки конвейера
      .word 0x00000001 @ str value, [adress]
      .word PERIPH_BASE + FLASH_R_BASE + FLASH_ACR
      .word FLASH_ACR_ICEN + FLASH_ACR_DCEN + FLASH_ACR_LATENCY_5WS + FLASH_ACR_PRFTEN

      @ Выбираем PLL источником тактирования
      .word 0x00000003 @ str value, ( ORR ( MASK[adress] ) )
      .word PERIPH_BASE+RCC_BASE+RCC_CFGR
      .word ~(RCC_CFGR_SW)
      .word RCC_CFGR_SW_PLL

      @ Ожидаем переключения на PLL
      .word 0x00000021 @ Wait Bitband 1
      .word PERIPH_BB_BASE+(RCC_BASE+RCC_CFGR)*0x20+RCC_CFGR_SWS_PLL_N*4

      .word 0x000000FF @ выход

      один раз написана, сохранена как модуль. При необходимости вызываю настройку с указанием адреса списка и все готово… сейчас все используемые иниты периферии перевожу в этот формат…

      p.s. как в первом сообщении верно указал Dark purple: «это как гречневую кашу пинцетом по одному зёрнышку», и если есть правильно, то каша очень вкусная получается :-)
      • +1
        А кто запрещает на С писать прямо в регистры? Просто на ЯВУ проще строить уровни абстракции чем на ассемблере, SPL — это уже некое готовое дерево абстракций которое сделали до тебя. Можно вырастить и своё дерево, только боюсь плоды не будут совместимы с метаболизмом других проектов — и это реальная проблема велосипедов.
        • 0
          мы падаем в холивар относительно языков программирования… :-(
          почему все тогда не используют бейсик? :-)

          я не призываю всех сменить язык программирования, я пишу на том языке что мне интересен, и делюсь опытом с теми кто захочет попробовать…
          • 0
            В бейсике не доступно всё дерево абстракций, а те ветви что доступны довольно высокоуровневые и довольно неуклюжие из-за необходимости обеспечить совместимость несовместимых вещей.
            • 0
              просто развитие бейсика фактически остановилось после того как юникс написали на си и он стал языком на котором написана операционная система и одновременно единственным простым способом писать программы под ОС…
              А дальше свое взяла мода… — стал не модным и просто умер в развитии… примерно как дельфи… неплохой в общем то язык, но пара просчетов — и в результате обочина…
              • 0
                Бейсик вобщем-то не умер, как и делфи. Просто они нынче не популярны из-за второстепенных проблем. Не так давно приходилось бейсиком пользоваться, и на делфи написано корпоративное приложеньице купленное пару лет назад.

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