После поисков по интернету так и не удалось найти сколь нить понятного для новичка способа написания прошивок для 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, если это не откровение для вас можете пропустить пару абзацев:
При включении микроконтроллер:
- По адресу 0х0800 0000(*) загружает значение регистра указателя стека SP. Обычно стек начинается с конца доступной RAM и при заполнении движется от старших адресов к младшим
- По адресу 0x0800 0004 загружает значение регистра PC (Program counter) — то есть фактически осуществляет переход по адресу указанному по адресу 0x0800 0004
- Осуществляется исполнение программы по адресу загруженному в 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 | 0 | 1 | 0 | 0 |
| Полубайт | 0 | 8 | ||||||
А должно быть:
| Бит | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Значение | 0 | 0 | 0 | 0 | 0 | 1 | 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.
Указать можно двумя путями:
- Указать при компиляции при помощи ключа «-mcpu=cortex-m4»
- Указать в тексте программы строкой «.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):
Вот теперь нам есть что анализировать:
- В .bin прошивке не указываются адреса по которым происходит «заливка» прошивки в микроконтроллер — этот параметр указывается при программировании (в нашем микроконтроллере STM32F407 начальный адрес должен быть 0x08000000)
- Мы планировали что прошивка начнется с таблицы указателей переходов, первый указатель — SP, на конец SRAM1 и SRAM2 – 0x20020000. В прошивке идут байты 00 00 02 20 — вспоминаем (или узнаем сейчас) что все данные идут в порядке «младший — старший») и переворачиваем наши байты прошивки переписывая их побайтно справа-на-лево: 20 02 00 00 — вектор SP указан верно !
- После указателя SP должен идти вектор сброса: смотрим: 09 00 00 08, переворачиваем и получаем адрес для перехода: 08 00 00 09 — тоже правильно!
- Далее идет код команды на языке ассемблера.
Я бы рад вам подсказать способ дизассемблирования команды по ее коду — но к сожалению пока такого ресурса не знаю… Поэтому доверяю тому что получилось и считаю чтосочетание 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.
Следовательно закодирована команда 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
На этом текущее повествование прекратим и подведем итоги:
- Мы нашли файлы необходимые для компиляции проектов на языке ассемблера для микроконтроллера STM32F407
- Выбрали необходимые ключи компиляции и настройки компилятора
- Начали разбираться с картой памяти линковщика, и выяснили какие ключи необходимо использовать для линковки
- Получили файл прошивки, преобразовали этот файл в более понятный нам binary
- Мы проверили правильность формирования таблицы переходов, кода программы, размещения программы в прошивке на файле формата binary
В следующей статье будем писать прошивку микроконтроллера чтобы реально проверить его работу — будем мигать светодиодом!
Часть 2: STM32F4: GNU AS: Мигаем светодиодом (Оживление)
Комментарии (40)
Amomum
05.01.2016 16:09+6Статья получилась хорошая, но на мой взгляд в ней не хватает одной важной вещи.
выясняется, что «гуру не пишут проекты на ассемблере», и в средах ассемблер используется максимум для написания процедур и функций требующих максимального быстродействия, или генерации кода содержащего специфические команды микроконтроллера аналог которых не предлагается языком Си (С++ или библиотеками) in-line вставками.
А в самом деле — зачем писать всю прошивку на ассемблере?
farcaller
05.01.2016 19:24+3Потом дизассемблировать проще :-)
Довелось мне как-то раскуривать загрузчики PalmOS на несколько древних уже Palm Tungsten T3 и Palm LifeDrive. У первого набортовой оперативки не было, и бoльшая часть загрузчика была весьма читабельным листингом, было видно «поток сознания» автора. У LD процессор был уже поновее, с оперативкой, так что ассемблерный кусок настраивал стек, а дальше начинался страх и ужас оптимизированного кода от g++.
Vadimatorikda
05.01.2016 16:43+2Статья классная, на мой взгляд. Сам некоторое время писал на ассемблере под STM32F103 и К1986ВЕ92QI (Миландр, но ядро то же). Довольно интересно было. Но сейчас на работе пишем исключительно местными обертками основанными на HAL (таковы правила). Так что производительность иногда очень страдает. Зато читабельность многократно выше. Жду продолжения.
infrapro
05.01.2016 16:49+1Отличная статья, годится не только для контролероа STM. Очень хочу почитать чуть больше о файле линковщика, конечно, в инете есть инфа по этому вопросу, но вы все так хорошо описываете :)
grossws
05.01.2016 17:39+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.
VitGo
05.01.2016 17:57Спасибо за информацию! учту!
К слову, что мне пока не очень удобно в документации ST — так это очень большая фрагментированность документации… не всегда понятно где же все таки будет написано искомое :-) потом, когда найдешь, вроде бы начинаешь логику понимать, но вот с «нуля» — очень не удобно искать иголку в стоге сена…
Про таблицу прерываний в курсе, первая программа в статье — это просто проверка возможности написания и компиляции…
victorv
05.01.2016 20:33Статья — хороший бочонок меда начинающим для вхождения в тему.
Ложка дёгтя — слова «линковщик»\«линковка» вместо более традиционных «компоновщик»\«компоновка».
Такое особенно вредно для начинающих — в комментариях уже цитируют…
Muzzy0
05.01.2016 22:04+3Традиционно — линкер (linker) ;) Мне так привычнее ещё со времён DOS, Borland Turbo Pascal и Turbo C.
Frantony
06.01.2016 00:19Писать всю прошивку на ассемблере наверное нужно очень редко, но вот разобраться в том, как именно создаётся образ прошивки — это безусловно полезно.
Только один комментарий:
В следующей статье будем писать прошивку микроконтроллера чтобы реально проверить его работу — будем мигать светодиодом!
Надеюсь, что исходники прошивки из следующей статьи будут выложены в удобном для скачивания и обновления виде, например, в виде репозитория на github.
VitGo
06.01.2016 02:53в виде ссылки на яндекс.диск подойдет? там не просто обновлять придется — у меня плата отладочная не stm32f4 discovery — так что без желания и активных действий мигать «из коробки» ничего не будет.
p.s. вторая статья уже написана и лежит в черновиках, но еще не вычитал :-( обычно когда печатаю допускаю много оЧеПяток, стыдно такое выкладывать… постараюсь завтра разместить, а там уж как модерацию пройдет (эта статья висела 5 дней на модерации в песочницу, я ее потихоньку правил пока админы собирались смотреть)grossws
06.01.2016 03:27-1Дальше оно без модерации, сразу выкладывается. А так в песочнице иногда и по несколько месяцев статьи висят.
gbg
06.01.2016 10:43+2Никаких Я.Дисков! Никаких рарчиков! Освойте уже нормальные процессы разработки о обмена исходниками! Тоже мне, рарчики. У нас 2016 год за бортом, а у вас — рарчики. Стыдобень!
Frantony
06.01.2016 11:06в виде ссылки на яндекс.диск подойдет?
Выкладывать исходные тексты таким образом можно только в случае крайней нужды.
Советую не пожалеть времени и освоить git!
Начать можно с Good Resources for Learning Git and GitHub.
googol
06.01.2016 00:43Низкоуровневое программирование контроллеров это интересно, стильно, молодежно. Я как то задался целью написать минимальное приложения для STM32 на С без использования ассемблера и сторонних библиотек. Вот что получилось github.com/anatol/stm32f4-examples/tree/master/native/blink01
VitGo
06.01.2016 02:55какой размер получился? (по файлу binary)
у меня оптимизированная мигалка одним светодиодом заняла 68 байт (та что во второй части статьи, написана «в лоб» для понимания, имеет размер — 116 байт)gbg
06.01.2016 10:51+1На AVR минимальная программа — мигалка состоит из одной инструкции.
VitGo
06.01.2016 11:09кстати, в комментариях правильно написали: программа не из одной инструкции, а из 1024 ! :-) так как первая инструкция включает/выключает светодиод, а остальные служат для организации задержки :-)))
markhor
06.01.2016 11:09+1По-моему objdump c нужными ключами умеет дизассемблировать код.
googol
06.01.2016 19:04Для STM32 бинарников использую
arm-none-eabi-objdump -D -marm --disassembler-options=force-thumb --target binary $INPUT > $OUTPUT
VitGo
06.01.2016 14:30он показывает информацию по секциям…
в этой публикации цель простота и понятность (до сложного дойдем еще), а так вы правы, например, может быть такая «конструкция»:
:: Отдельно информация о каждой секции в файл (вывод в файлы) 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
tronix286
07.01.2016 10:27+2Каждый, кто писал свой бутлоадер для STM32, по-любому должен был столкнуться с асмом. Немножко так, но достаточно для того, что бы запомнить как начинает работать STM32, откуда берет стек, откуда загружает PC, и как называется команда перехода на ассемблере. Ну и немножко потанцевать с бубном вокруг таблицы векторов прерываний, особенно на младших семействах типа stm32f030. А дальше быстро уйти обратно в Си.
Имхо — ARM не доставляет много фана в программировании на ассемблере. Потому что много за чем нужно следить, много периферии, много настроек — внимание распыляется по пустякам, а когда дело доходит до кодинга, то уже и кодить не хочется, потому что замучался тонны строк инициализации копипастить, да еще и ошибся при копипасте и сидишь разбираешься в какой бит положил 1 вместо 0 в одном из сотен 32-битных регистров.
Другое дело 8-битки, да. Меня «прет» иногда покодить что-то для PIC16… А сколько вообще интересных винтажных платформ — 6502, 6809, 8080б 8041… Взять какую-нибудь денди (6502) и закодить для нее демку — вот это было бы здорово. Или из АОН на 8035 сделать часики и термометр. Ну или просто добавть в прошивку поддержку CallerID -)VitGo
08.01.2016 13:25то есть вы тоже сторонник 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
Alexeyslav
08.01.2016 23:40+1А кто запрещает на С писать прямо в регистры? Просто на ЯВУ проще строить уровни абстракции чем на ассемблере, SPL — это уже некое готовое дерево абстракций которое сделали до тебя. Можно вырастить и своё дерево, только боюсь плоды не будут совместимы с метаболизмом других проектов — и это реальная проблема велосипедов.
VitGo
09.01.2016 06:58мы падаем в холивар относительно языков программирования… :-(
почему все тогда не используют бейсик? :-)
я не призываю всех сменить язык программирования, я пишу на том языке что мне интересен, и делюсь опытом с теми кто захочет попробовать…Alexeyslav
10.01.2016 22:08В бейсике не доступно всё дерево абстракций, а те ветви что доступны довольно высокоуровневые и довольно неуклюжие из-за необходимости обеспечить совместимость несовместимых вещей.
VitGo
11.01.2016 06:53просто развитие бейсика фактически остановилось после того как юникс написали на си и он стал языком на котором написана операционная система и одновременно единственным простым способом писать программы под ОС…
А дальше свое взяла мода… — стал не модным и просто умер в развитии… примерно как дельфи… неплохой в общем то язык, но пара просчетов — и в результате обочина…Alexeyslav
11.01.2016 16:14Бейсик вобщем-то не умер, как и делфи. Просто они нынче не популярны из-за второстепенных проблем. Не так давно приходилось бейсиком пользоваться, и на делфи написано корпоративное приложеньице купленное пару лет назад.
Dark_Purple
Программировать STM32 ассемблере это как есть гречневую кашу пинцетом по одному зёрнышку. Если цель просто писать программы для STM32, то вам крайне необходимо осознать ущербность писанины на ассемблере и как можно скорее перейти на С/С++.
VitGo
Полностью с Вами согласен ! именно пинцетом, и именно по одному зернышку!!!
Я любитель, и написание программ на ассемблере это мое хобби (на жизнь зарабатываю совершенно другим, к программированию, компьютерам, микроконтроллерам отношения не имеющем) Мне очень нравиться ассемблер, тем более с системой команд ARM!
avrfun
а какая ваша основная работа, если не секрет, если программирование на asm под STM32 только хобби?
VitGo
Управляющий Закрытыми паевыми фондами недвижимости в Управляющей компании (это из области доверительного управления имуществом)…
В провинции программисты не нужны (нужны только настройщики 1С, администраторы (да и то это все крупные компании админят из Москвы/Питера, удел местных «администраторов» обеспечить канал для настройки), установщики Windows, «сниматели» банеров — и все это вряд ли способно дать более менее заметный доход… ну или дает конечно доход, но единицам и пробиться в эти «круги» не так просто и к сожалению собственный профессионализм при этом роли не играет)
Dark_Purple
Что ж, достойное хобби! Если вы ещё и Си знаете на достойном уровне то тогда вообще супер.
Статья кстати тоже достойная.
VitGo
нет, к сожалению в Си я слабак :-(
а вот в асме всегда любил «по извращаться», а сколько исходников было потеряно (у меня тут винда-10 «обновила» комп до состояния нового..:-( а архивы как раз на компьютер сбросил чтобы отсортировать...)
Dark_Purple
Вот поэтому я ещё раз вам крайне советую всё таки освоить си (пусть без плюсов), гарантирую после вам уже не будет так нравится ассемблер.
ЗЫ Это из личного опыта… Собственно поэтому и написал слегка «резковатый» первый комментарий.
VitGo
все это прекрасно понимаю, на си пишу понемногу…
но поскольку у меня это занятие хобби и ничего более (по крайней мере пока) — поэтому пишу и на ассемблере…
с ассемблером я с 1993 года, и честно говоря ни на что его менять не хочу, тем более что ассемблер ARM мне очень нравиться набором инструкций
еще раз повторюсь — у меня не стоит дедлайнов по срокам, не нужно работать в команде, и т.д.
Alexeyslav
Когда нет дедлайнов это приводит к тому что проект не заканчивается никогда.
Да, и я бы сказал не ассемблер а макро-ассемблер нужен, на голом ассемблере далеко не уедешь, а вот дополнительные уровни абстракции делают ассемблер не хуже С когда въедешь в тему и будут какие-то наработки.
Теперь я понимаю, почему многие не хотят писать на ассемблере под ARM-контроллеры — и система команд довольно громоздкая, и названия самих команд несколько странные и не логичные а тут еще узнал что еще и разные системы команд на одном контроллере применяются(наверно для эффективного использования конвеера для разного рода задач?) — свихнутся можно на раз.
С другой стороны, прикладным программистам больше платят чем системным ибо обхват софта больше, видимая польза и спрос соответственно.
Кстати интересно еще посмотреть на реальных проектах насколько широко используются разные инструкции в случае программы написанной на ассемблере и сгенерированной с ЯВУ.
VitGo
не знаю как у вас, но у меня дедлайн еще никогда не ускорял проект… скорее даже наоборот — необдуманные решения примененные из-за спешки способны убить проект впоследствии возникающими «родовыми» травмами…— не хочу холивара, я пояснил свою позицию — я не зарабатываю денег написанием программ, и могу себе позволить разбираться с тем языком который мне нравиться (сегодня придумал способ простой инициализации микроконтроллера, в ближайшее время попробую написать). Если будут люди которым это интересно (именно для этого я здесь) — то с удовольствием объединю усилия (есть у меня пара задач которые нужно решить)… пока (судя по количеству комментариев ко второй части публикации — таковых нет :-(… так что буду «развлекать» вас только собственной персоной…На счет абстракции: на ассемблере вполне можно написать отдельные подпрограммы, с тем или иным функционалом, и потом объединить в каком то алгоритме… да на Си выходит проще, да на СИ проще писать переносимый код (хотя я не видел переносимого кода, кроме случаев когда он состоит из операторов самого языка СИ), проще работать в команде (возможно! но не факт), очень много сред с различными возможностями...
ну в общем то у каждого семейства процессоров свои команды, мне после Z80 с его LD по всем случаям ассемблер I8080 казался больно мудреным :-) потом ассемблер x86 — опять другие команды, потом AVR — и все более менее знакомо (уже как говориться все повидал, все попробовал) хотя конечно после первых трех уже особо не грузишься, просто запоминаешь новые мнемоники…
а вот ассемблер ARM — это что то действительно новое… на счет сложности — сложно пока не начинаешь разбираться… вообще по моему мнению некоторые вещи очень и очень правильны
На счет разных систем команд — все не так страшно, команды одни и те же, просто есть их 32ух битное и 16ти битное кодирование… в принципе по началу об этом можно не задумываться, при желании потом можно провести оптимизацию кода…
Alexeyslav
Кстати, различие LD и MOV для Z80 были только в старых книжках, а более новые в т.ч. и зарубежные заменяют всё это одной командой MOV хотя это не отражает сути самих команд, но видимо они там думают чем меньше разнообразия в написании команд тем легче будет студентам выучить их…
Возможно, ассемблер ARM разрабатывался с целью лёгкости машинной оптимизации а не написания программ человеком.
VitGo
я не видел док по Z80 где команды были бы представлены в формате I8080 (то что первый проработка второго знаю, историю создания читал)…
на счет ассемблера ARM — мне трудно судить почему у вас о нем такое мнение… :-(