Вновь возвращаюсь к фирменной среде разработки - ST Visual Develop, для чего есть две причины. Во-первых, оказалось, что писать на ассемблере сколь-либо сложные прошивки без отладчика невозможно, у меня по крайней мере не получилось, т.к. программа все-равно так или иначе отлаживается с помощью светодиода или по UART, через отладочный интерфейс это просто делается быстрее. Во-вторых, мне показалось, что изучать архитектуру только лишь руководствуясь datasheet'ом не совсем правильно. Что-то может быть неправильно понято, что-то может быть упущено. С такими штуками как DMA, встроенный RTC или выполнение кода из ОЗУ, будет проще разобраться с помощью отладчика, не забывая при этом посматривать в datasheet.
STVD - довольно простая среда разработки, я ее освоил за вечер. В этой статье я хочу рассказать, как "с нуля" начать писать и отлаживать прошивки на ассемблере STM8, используя ST Visual Develop.
STVD - работает в ОС семейства Windows, начиная с XP и выше. При этом она прекрасно работает из-под виртуальной машины в Linux. В этой статье я использую STVD 4.3.12, последнюю доступную версию на этот момент, и Windows XP SP3 в качестве гостевой ОС. В качестве микроконтроллера я буду использовать 20-пиновый STM8S103F3P6.
В качестве дизассемблера я буду использовать комплект утилит stm8-binutils. Бинарные файлы этого комплекта для Windows скомпилированы для работы в CYGWIN, т.е. они понимают unix'овский формат пути файла с прямым слешем в качестве разделителя. CYGWIN для Windows 7 и выше ставится без проблем следуя инструкциям на сайте https://cygwin.com/install.html, для Windows XP нужно следовать инструкциям в этом HowTo: windows xp - cygwin 2.5.2 mirror -- getting the last XP release - Stack Overflow.
В качестве альтернативы связке binutils+cygwin, можно использовать naken_util из комплекта naken_asm.
I. Создание минимального проекта Blink
II. Язык ассемблера STVD
III. Процесс отладки
IV. Макроассемблер
В данной статье я попытался рассмотреть вопрос использования ассемблера в Си-программах для компилятора SDCC. Данный компилятор часто подвергается критике по качеству кода, однако он является единственным Open Source компилятором для архитектуры STM8, и единственным компилятором доступным в Linux. Поэтому данная статья может рассматриваться как HowTo по выжимании максимума возможного из SDCC.
Когда я пытался в прошлый раз (почти два года назад) подружиться с SDCC у меня оказалось большое количество вопросов к нему, что вылилось в метания между SDCC, IAR и Cosmic. Была даже идея отказаться от STM8 в пользу Cortex-M0. Однако теперь для Linux появился отладочный интерфейс, что побудило меня еще раз взглянуть на SDCC и попытаться найти к нему подход.
Статья построена аналогично предыдущей: ATtiny13a: использование ассемблера GNU-AS в программах на Си с той разницей, что вместо ATtiny13a будет использоваться 20-пиновый STM8S103F3P6, а вместо GCC - SDCC.
В качестве операционки при написании использовался Slackware GNU/Linux (русские физики рекомендуют), но теоретически, все должно работать и в Windows при условии использования CYGWIN.
По ходу изложения, я буду сравнивать систему команд STM8 и AVR. Я делаю это не для того что "уронить" AVR, а потому что считаю эту архитектуру хорошо сбалансированной, удобной в использовании и легкой в освоении. STM8 это более современная архитектура, и по определению обязана быть более лучшей. Однако AVR удобно рассматривать в качестве какой-то базовой системы, этакой точкой отсчета.
Полные исходники, сборочные файлы и скомпилированные прошивки можно будет скачать по ссылке в конце статьи.
Примечание от 01.09.2022г. В SDCC версии 4.2 поменялся формат передачи аргументов функций. Если раньше все аргументы передавались через стек, то теперь они передаются через регистры. Поэтому для совместимости со старым кодом следует добавлять опцию компиляции "--sdcccall 0".
Вначале я хотел посвятить архитектуре STM8 краткую вводную главу, но когда начал вчитываться в документацию, то понял, что переводить надо все. Потому что лучше, чем написано в документации, я не скажу. Посвятить целую статью теории - это несколько выходит за формат моего сайта. Но все, что там изложено, стоит того, чтобы это прочесть.
Наибольшие вопросы в STM8 у меня вызывал 3-уровневый конвейер, поэтому в основу перевода легла глава, рассмативающая работу этого конвейера.
Если сравнивать систему команд STM8 с ассемблером AVR, то здесь имеется большое количество 16-битных команд, целочисленное умножение и деление, условные переходы объединены с проверками, не надо вечно перепрыгивать через команду. Имеются полноценные битовые команды, которые выполняются за один цикл. В целом, мне показалась, что писать на ассемблере STM8 можно также легко как на Си.
То, что Arduino очень медленно обрабатывает внешние прерывания, я заметил еще осенью прошлого года, когда разбирался с RTC. Тогда я пытался тактировать счетчик часов Arduino от 32кHz вывода DS3231, но такие часы у меня отставали секунд на десять в минуту. Для 16 МГц микроконтроллера, это было абсолютное фиаско.
В следующий раз я столкнулся с проблемой на ATtiny13, когда делал счетчик импульсов. В этот раз Arduino досталась роль передатчика, а ATtiny13a работающей на частоте 9.6 МГц был в роли счетчика. Но несмотря на то, что прошивка была написана на чистом Си, а обработчик внешнего прерывания прерывания состоял всего из одной строчки: "value++;", максимальная рабочая частота счетчика достигала всего 200кГц.
Такой результат меня тоже не устроил, и я решил, что обработчик прерывания нужно писать на ассемблере. Забегая вперед, скажу, что это дало мне прирост по максимальной частоте в три раза т.е. до 600кГц.
Ок, ассемблер это хорошая штука в плане скорости, но полностью прошивку писать на нем довольно тоскливое занятие. В AVR нет даже целочисленного деления. Выходом может стать написание смешанного кода на ассемблере и Си, т.к. gnu ассемблер по сути является бэкендом gcc-компилятора.
Но прежде чем начать использовать ассемблерные функции и прерывания в Си-программах, нужно будет познакомится с процессом компиляции, сборки и линковки таких смешанных проектов.
Архив с полными исходниками, сборочными файлами и скомпилированными прошивками можно будет скачать по ссылке в конце статьи.
Если разобраться в предыдущем посте: дизассемблирование blink.hex, где подробно разобрана реализация blink на ассемблере AVR, то проблем с написанием собственного варианта Blink на ассемблере не будет. Вообще-то программа там уже выложена. Осталось только разобраться с преобразованием исходников в hex файлы.
Мой вариант blink.asm:
.equ DDRB, 0x17 .equ PB0, 0x00 .equ PORTB, 0x18 .org 0x00 ; начало sbi DDRB, PB0; порт PB0 на передачу ldi r25, 0x01; r25=1 ; главный цикл loop: in r24, PORTB; r24=PORTB eor r24, r25; r24 = r24 xor r25 out PORTB, r24; PORTB=r25 ldi r18, 0x3F; r18=0x3F ldi r19, 0x0D; r19=0x0D ldi r24, 0x03; r24=0x03 sleep: subi r18, 0x01; (r18r19r24)-1 вычитание трехбайтного целого числа sbci r19, 0x00 sbci r24, 0x00 brne sleep; если значение в r24 не равно нулю, то переход на начало операции вычитания rjmp loop; возврат на начало главного цикла
Компиляция:
avr-as -mmcu=attiny13 -o blink.o blink.asm
avr-ld -o blink.elf blink.o
avr-objcopy --output-target=ihex blink.elf blink.hex
Смотрим, все ли в порядке:
$ avr-objdump -m avr -D blink.hex blink.hex: file format ihex Disassembly of section .sec1: 00000000 <.sec1>: 0: b8 9a sbi 0x17, 0 ; 23 2: 91 e0 ldi r25, 0x01 ; 1 4: 88 b3 in r24, 0x18 ; 24 6: 89 27 eor r24, r25 8: 88 bb out 0x18, r24 ; 24 a: 2f e3 ldi r18, 0x3F ; 63 c: 3d e0 ldi r19, 0x0D ; 13 e: 81 e0 ldi r24, 0x03 ; 3 10: 21 50 subi r18, 0x01 ; 1 12: 30 40 sbci r19, 0x00 ; 0 14: 80 40 sbci r24, 0x00 ; 0 16: e1 f7 brne .-8 ; 0x10 18: f5 cf rjmp .-22 ; 0x4
Ассемблер считается сложным языком программирования. Хотя, припоминая, к слову, функциональное программирование, где нет ни переменных, ни циклов, а вместо них одни рекурсии и функции, я бы поспорил. Но, мне кажется, что я знаю причину такого мнения. Если взять рядовую книжку по предмету, то прежде чем написать свой blink, сперва придется прочитать добрую сотню страниц, если не больше, про архитектуру, регистры, шины, порты и т.д. Не самое легкое чтиво, надо сказать. Взяв для сравнения книжку Кернигана&Ритчи мы найдем "Hello World!" на первой же странице. Весомый аргумент в пользу Си, на мой взгляд.
В предыдущем посте я упоминал, что размер прошивки с программой Blink написанной на Си для ATtiny45 составляет 82 байта. В AVR каждая инструкция вместе с аргументом занимает два байта, т.е. одно слово. 82 делим на 2, получаем 41 ассемблерная инструкция. Наверно, должен сразу оговориться. Если вы не получаете за это деньги, то изучать Ассемблер нет никакого практического смысла, языка Си хватит "за глаза" для написания своих прошивок. НО... иногда желание заглянуть "под капот" бывает слишком сильным;)
Если уж экспериментировать с ассемблером, то для начала, разумно будет выбрать чип попроще. Мой выбор пал на ATtiny13. Его флеш-память составляет всего 1 Кбайт. Опять же 1024 делим пополам, получаем размер программы до 500 инструкций, что для ассемблера совсем немного. По правде говоря, многие устройства работают на этом чипе, на мой взгляд один из самых популярных микроконтроллеров. По счастливой случайности, распиновка ATtiny13 совпадает с распиновкой ATtiny45, следовательно и исходник blink.c не меняется:
// blink.c for AVR ATtiny 13/25/45/85 #include <avr/io.h> #define F_CPU 1000000UL // частота резонатора 1МГц #include <util/delay.h> int main(void) { // макрос _BV(число) заменяет конструкцию (1 << число) DDRB |= _BV(PB0); // аналог pinMode(PB0,OUTPUT); в Wiring for (;;) { PORTB ^= _BV(PB0); // инвертируем состояние порта PB0 _delay_ms(1000); // ждем 1 секунду } return 0; }
Ах, чуть не забыл. Про книжки по ассемблеру AVR.