Программирование голого железа Raspberry Pi

Я уже затрагивал тему программирования голого железа (bare metal). Заметку на эту тему опубликовал здесь же на форуме. Сейчас решил вернуться к этой теме. Но понял, что она слишком обширна и, наверное, не до конца отвечает тематике нашего форума. В общем, в этой теме буду по мере появления у меня настроения потихоньку публиковать материалы по теме, а также отвечать на вопросы, если таковые возникнут.

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

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

Для этого я подготовил небольшой обзор, который даст представление о bare metal софте под Raspberry Pi.

В обзоре есть упоминание эмулятора Спектрума. Также обратите внимание на демку Pi on Fire, в которой звуковое сопровождение написано под два AY.

Обзор bare metal программ для Raspberry Pi

P.S.В этой заметке я написал, что полноценного эмулятора Raspberry Pi не существует, но на самом деле эмулировать Raspberry Pi можно, но с некоторыми оговорками. Об этом я расскажу чуть позже.

Вот пример bare metal игры, написанной на чистом ассемблере:
https://www.youtube.com/watch?v=cFWNbK_dK0g

В обзор добавил информацию об ещё одном эмуляторе ZX Spectrum - πBacteria. Эмулятор написан на ассемблере, а исходники доступны.

https://www.youtube.com/watch?v=QkasVkToxNU

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

Итак, для начала скачайте и установить эмулятор QEMU. Последнюю сборку под Windows можно скачать отсюда: https://qemu.weilnetz.de/w64/
Также нам потребуется кросс-ассемблер FASMARM для Windows. Скачать его можно отсюда: https://arm.flatassembler.net/

Далее скопируйте текст программы в блокнот и сохраните в файл HelloWorld.s:

Код:

---

org 0x6001000
    mov r0, 0x9000  ; Загружаем в регистр r0 адрес консоли 0x10009000, вначале младшую половину
    movt r0, 0x1000    ; а потом старшую половину
    adr r1,text    ; Загружаем в регистр r1 адрес начала текста
    mov r2,0    ; Обнуляем счётчик в регистре r2
loop:
    ldrb r3,[r1,r2] ; Загружаем в регистр r3 код следующего символа надписи
    str r3,[r0]    ; Выводим в консоль код символа из регистра r3
    add r2,1    ; Увеличиваем счётчик на единицу
    cmp r3,10    ; Сравниваем код символа с кодом перевода строки
    bne loop    ; Переходим к следующему символу, если код символа не равен коду перевода
finish:
    b finish    ; В конце программы зацикливаем строку саму на себя
text:
    db "Hello, World!", 10

---

Сам я лично вместо стандартного блокнота пользуюсь Notepad++ и подсветкой синтаксиса, которую сделал похожей на привычный мне PyCharm:

https://pic.maxiol.com/images2/16928...helloworld.png

Распакуйте архив с ассемблером. Оттуда понадобится только исполняемый (.exe) файл. И положите рядом с ним ваш HelloWorld.s. Теперь всё готово для компиляции! Открываем консоль, переходим в папку с ассемблером и нашим файлом, и подаём команду:

Код:

---

fasmarm HelloWorld.s

---

https://pic.maxiol.com/images2/16928...84.compile.png

На выходе получаем файл HelloWorld.bin объёмом 54 байта. Теперь осталось только его запустить под эмулятором. Для запуска подаём такую команду в консоли:

Код:

---

"c:\Program Files\qemu\qemu-system-arm.exe" -M vexpress-a9 -serial stdio -kernel HelloWorld.bin

---

И наслаждаемся результатом:

https://pic.maxiol.com/images2/16928....consolehw.png

Появились вопросы? Задавайте!

Итак, давайте потихоньку двигаться дальше. Предлагаю внести в пример из предыдущего сообщения небольшие изменения. А именно, после строки с директивой org добавить ещё три строки:

Код:

---

    blx start
    thumb
start:

---

То есть по итогу должно получиться вот так:
https://pic.maxiol.com/images2/16928...hellothumb.png

Так как мы что-то добавили в программу, то исполняемый код должен увеличиться на несколько байт. Давайте скомпилируем и проверим. И что мы видим? Исполняемый код стал объёмом 46 байт, то есть ещё короче чем был! А был, напомню, 54 байта.

Что же произошло? Давайте попробуем разобраться и дизассемблировать код обеих вариантов с помощью популярного дизассемблера IDA Pro.

Вот так выглядит код первоначального варианта (54 байта):

https://pic.maxiol.com/images2/16928...84.hello32.png

Всё совпадает с ассемблерным текстом! (На команду MOV R0 не обращайте внимания. По умолчанию IDA для простоты восприятия заменяет некоторые последовательности команд в метакоманды. Вот и здесь она заменила две команды загрузки регистра R0 по половинкам (MOV и MOVT) в одну длинную загрузку, которая на самом деле отсутствует в наборе команд процессоров ARM. Где-то в настройках IDA Pro это можно отключить и тогда всё будет отображаться, как есть.)

А вот так выглядит дизассемблер модифицированного варианта (46 байт):

https://pic.maxiol.com/images2/16928...84.hello16.png

И тоже всё совпадает, и даже дополнительная команда BLX появилась. Но при этом код стал короче!

А произошло следующее: директивой thumb мы дали команду ассемблеру все дальнейшие команды вместо стандартного 32-х битного режима ассемблировать в 16-битном режиме thumb. А, собственно, командой BLX мы дали понять процессору, что код, на который будет осуществлён дальнейший переход, будет исполняться в режиме thumb.

В режиме thumb все команды, в отличие от 32-х битного режима, кодируются только двумя байтами. В результате исполняемый код такой программы становится более компактным. И всё было бы отлично, если бы не кое-какие ограничения. И прежде всего это ограниченный набор команд - их всего лишь 36. Есть и другие ограничения, но сейчас не будем на них останавливаться.

Что касается меня, то режим thumb привлёк моё внимание именно ограниченным набором команд. Дело в том, что за долгую историю архитектуры ARM было выпущено несколько поколений процессоров. Для них было придумано большое количество команд, у каждой из которых есть свои особенности. Разобраться и изучить их все довольно проблематично. А здесь же мы имеем только 36 команд, с помощью которых можно запрограммировать практически любое действие. При этом, если вам когда-нибудь вдруг станет тесно в рамках thumb, вы всегда сможете перейти на 32-х битную систему команд без необходимости что-то менять в своём коде. Наверное, здесь можно привести аналогию с процессорами i8080 (КР580ВМ80А) и Z80. Если писать код для процессора i8080 (аналогия с thumb), то код будет работать и на i8080, и на Z80. Но если вам становится тесно, то вы можете начать использовать дополнительные регистры и команды процессора Z80 (аналогия с 32-х битным режимом ARM), но тогда уже потеряете совместимость с i8080.

В конце хочу привести полный список из 36 команд процессоров ARM в режиме thumb:

№	Мнемоника	Команда	Пример	Эквивалент кода ARM
1	ADC	Сложение с учетом переноса	ADC Rd, Rs	ADCS Rd, Rd, Rs
2	ADD	Сложение	ADD Rd, Rs, Rn	ADD Rd, Rs, Rn
3	AND	Логическое "И"	AND Rd, Rs	ANDS Rd, Rd, Rs
4	ASR	Арифметический сдвиг вправо	ASR Rd, Rs	MOVS Rd, Rd, ASR Rs
5	B	Безусловный переход	B label	B label
6	BCC	Переход по условию CC	BCC label	BCC label
7	BIC	Сброс битов (маскирование)	BIC Rd, Rs	BICS Rd, Rd, Rs
8	BL	Переход со ссылкой	BL label	BL label
9	BX	Переход и смена режима ядра	BX Hs	BX Hs
10	CMN	Сравнение с отрицанием	CMN Rd, Rs	CMN Rd, Rs
11	CMP	Сравнение	CMP Rd, #Offset8	CMP Rd, #Offset8
12	EOR	Исключающее "ИЛИ"	EOR Rd, Rs	EORS Rd, Rd, Rs
13	LDMIA	Групповая загрузка регистров	LDMIA Rb!, {Rlist}	LDMIA Rb!, {Rlist}
14	LDR	Загрузка целого слова	LDR Rd, [PC, #lmm]	LDR Rd, [PC, #lmm]
15	LDRB	Загрузка байта	LDRB Rd, [Rb, Ro]	LDRB Rd, [Rb, Ro]
16	LDRH	Загрузка полуслова	LDRH Rd, [Rb, #lmm]	LDRH Rd, [Rb, #lmm]
17	LSL	Логический сдвиг влево	LSL Rd, Rs, #Offset5	MOVS Rd, Rs, LSL #Offset5
18	LDRSB	Загрузка байта со знаком	LDRSB Rd, [Rb, Ro]	LDRSB Rd, [Rb, Ro]
19	LDRSH	Загрузка полуслова со знаком	LDRSH Rd, [Rb, Ro]	LDRSH Rd, [Rb, Ro]
20	LSR	Логический сдвиг вправо	LSR Rd, Rs	MOVS Rd, Rd, LSR Rs
21	MOV	Пересылка	MOV Rd, #Offset8	MOVS Rd, #Offset8
22	MUL	Умножение	MUL Rd, Rs	MULS Rd, Rs, Rd
23	MVN	Пересылка с инверсией	MVN Rd, Rs	MVNS Rd, Rs
24	NEG	Инверсия (побитовое "НЕ")	NEG Rd, Rs	RSBS Rd, Rs, #0
25	ORR	Логическое "ИЛИ"	ORR Rd, Rs	ORRS Rd, Rd, Rs
26	POP	Извлечение регистров из вершины стека	POP {Rlist}	LDMIA R13!, {Rlist}
27	PUSH	Размещение регистров в вершине стека	PUSH {Rlist}	STMDB R13!, {Rlist}
28	ROR	Циклический сдвиг вправо	ROR Rd, Rs	MOVS Rd, Rd, ROR Rs
29	SBC	Вычитание с переносом	SBC Rd, Rs	SBCS Rd, Rd, Rs
30	STMIA	Групповое сохранение регистров	STMIA Rb!, {Rlist}	STMIA Rb!, {Rlist}
31	STR	Сохранение целого слова	STR Rd, [Rb, Ro]	STR Rd, [Rb, Ro]
32	STRB	Сохранение байта	STRB Rd, [Rb, Ro]	STRB Rd, [Rb, Ro]
33	STRH	Сохранение полуслова	STRH Rd, [Rb, Ro]	STRH Rd, [Rb, Ro]
34	SWI	Программное прерывание	SWI Value8	SWI Value8
35	SUB	Вычитание	SUB Rd, Rs, Rn	SUBS Rd, Rs, Rn
36	TST	Побитовая проверка	TST Rd, Rs	TST Rd, Rs

Rs - Регистр-источник (Register source)
Rd - Регистр-приёмник (Register destination)
Ro - Отступ (Register offset)
Rn - Второй аргумент в арифметических операциях
Rlist - Список регистров

В предыдущем сообщении я привёл список команд, с помощью которых можно запрограммировать любую процедуру. Однако осталось кое-что, о чём следует иметь представление, прежде чем делать свои первые шаги в программирования на ассемблере ARM. И речь идёт о регистрах процессора.

В отличие от Спектрума тут всё довольно просто - у процессоров есть 16 регистров, которые обозначаются как r0-r15, а также два специальных регистра - CPSR и SPSR. Собственно, на этом всё :)

Но, на самом деле, как обычно, есть нюансы. Их много, но я остановлюсь лишь не некоторых из них.

Начнём с регистров общего назначения. Как уже было написано выше их всего 16. И все они 32-х битные, то есть каждый из них может хранить 4 байта, и, соответственно, процессор за одну команду может оперировать с таким объёмом данных. Однако не всеми регистрами Rxx вы можете распоряжаться, как заходите. Некоторые из них имеют специальное назначение, а некоторые и вовсе недоступны из режима Thumb.

Первые 8 регистров (r0-r7) - это регистры общего назначения, которые доступны из любого режима процессора, не важно Thumb (CODE16) это или ARM (CODE32). Пять следующих регистров (r8-r12) доступны только из режима ARM. Остаётся ещё три регистра, которые отведены под специальные задачи и помимо традиционного обозначения r13-r15 имеют псевдонимы.

r13 (SP) - это указатель стека, такой же как на ZX Spectrum, только разрядностью побольше.
r14 (LR) - это, так называемый, регистр связи. Он необходим, например, для вызова подпрограмм. На ZX Spectrum, когда мы вызываем подпрограмму по команде CALL, адрес возврата записывается на стек. В процессорах же АРМ всё происходит несколько иначе - адрес возврата записывается не на стек, а как раз в этот самый регистр связи. Причём, если вы потом из подпрограммы вызовете ещё одну подпрограмму, то адрес возврата затрёт предыдущий и из первой подпрограммы вы уже не сможете вернуться. Вот поэтому при вложенных подпрограммах необходимо самому заботится о сохранении регистра LR и его своевременном восстановлении.
r15 (PC) - это программный счётчик. Тут без особенностей, он такой же, как на Z80.

Вот так будет нагляднее:

https://pic.maxiol.com/images2/16928...mregisters.png

CPSR (Current Program Status Register) - это регистр, который хранит флаги, а также информацию для обработки прерывания.
SPSR (Saved Program Status Register) - этот регистр хранит копию CPSR при обработке прерывания. Опять же, для нас этот регистр пока неактуален, как и всё, что связано с прерываниями.

На прерываниях останавливаться не будем, а вот про флаги поговорить, безусловно, стоит. В общем-то почти все флаги нам знакомы по процессору Z80:

Q (Saturation) - насыщение/переполнение в DSP-операциях (для нас пока неактуально)
V (oVerflow) - переполнение (знаковое)
C (Carry) - перенос бита (беззнаковый)
Z (Zero) - нулевой результат (равенство)
N (Negative) - отрицательное значение (бит 31 установлен)

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

Предикат	Отрицание	Флаги	Комментарий
EQ	NE	Z	==
CS / HS	CC / LO	C	>= (беззнаковое)
MI	PL	N	< 0
VS	VC	V	переполнение
HI	LS	zC	> (беззнаковое)
GE	LT	NV || nv	>= (знаковое)
GT	LE	NzV || nzv	> (знаковое)
AL	-	-	Безусловная команда

Как и в Z80, здесь есть команда условного перехода, в качестве суффикса которой как раз используются обозначения условий из таблицы. И мы в программе "Hello, World!" уже использовали условный переход:

Код:

---

    cmp r3,10    ; Сравниваем код символа с кодом перевода строки
    bne loop    ; Переходим к следующему символу, если код символа не равен коду перевода

---

В первой строчке мы сравниваем содержимое регистра r3 с числом 10. А во второй команде, при условии BNE (branch if not equal - bne) мы переходим на метку loop. На Спектруме аналогом этой команды была бы команда jr nz,loop.

Любопытно, но по умолчанию почти все команды никак не затрагивают флаговый регистр. Вы можете до посинения вызывать команду SUB R1,1 и ожидать, что рано или поздно произойдёт обнуление регистра, сторожа его командой BEQ:

Код:

---

    mov r1,100
loop:
    sub r1,1
    beq exit  ; Данная команда никогда не сработает
    b  loop
exit:

---

Однако вас будет ожидать разочарование - команда BEQ никогда не сработает. А всё потому, что флаговый регистр не будет реагировать на результат команды SUB. И вот чтобы флаговый регистр всё-таки отреагировал, вам необходимо явно указать, что вам требуется реакция флагового регистра. Делается это довольно просто - суффиксом S. То есть вместо SUB, вам нужно использовать команду SUBS.

Код:

---

    mov r1,100
loop:
    subs r1,1
    beq exit  ; Команда сработает, когда в R1 будет 0
    b  loop
exit:

---

В качестве бонуса, суффикс S вы можете использовать даже в команде MOV. То есть вот такая команда BEQ вполне себе сработает после MOVS:

Код:

---

    movs r1,0
    beq label  ; Данная команда сработает

---

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

Код:

---

    movs r1,0
    moveq r2,1  ; Команда сработает
    movne r2,2  ; Команда не сработает

---

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

Думаю, что для начала этой информации о регистрах процессоров ARM вам будет достаточно.

Вывод в консоль фразы "Hello, World!" - это, конечно, хорошо, но малоинтересно. Гораздо интереснее что-то графическое, цветастое, с анимацией и чтобы ещё попроще было в коде. И такая штука у меня есть для вас! Крохотная демка под названием FreeFull. Размер исполняемого файла всего лишь 254 байта, но выглядит всё довольно эффектно!

https://pic.maxiol.com/images2/16929....freefull2.png

Не поленитесь, скомпилируйте и запустите её самостоятельно! Сделать это можно по аналогии с упомянутым примером "Hello, Wolrd!".

>> Вот << прямая ссылка на исходный текст.

Изучить этот исходник будет довольно интересно. Несмотря на то, что там всего лишь 94 строки текста, вы сможете увидеть, например, как инициализируется графический экран и как затем на нём попиксельно формируется картинка.

Интересно, хоть один человек найдётся, который отважится на компиляцию и запуск? А то у меня складывается ощущение, что я тут всё это сам себе рассказываю ;)

Адаптировал демку из предыдущего сообщения к железу Raspberry Pi и запустил её на реальных Raspberry Pi Zero, 1 и 2:

https://youtu.be/XT2WUvBWvJc

Итак, двигаемся дальше. Буквы в терминале - хорошо, красивая картинка на экране - ещё лучше! Но хочется какого-то интерактива. И вот здесь не всё так просто, как хотелось бы. Но об этом чуть ниже. А пока предлагаю вам текст короткой программы, которая опрашивает клавиатуру и выводит в терминал код нажатой клавиши:

Код:

---

org 0x6001000
    blx start
    thumb

start:
; Опрашиваем клавиатуру
    movw r0,0x6004  ; Keyboard Status Register
    movt r0,0x1000
    ldrb r1,[r0]
    and r1,0x10
    cmp r1,0x10
    bne finish
    movw r0,0x6008  ; Keyboard Data
    movt r0,0x1000
    ldrb r1,[r0]
    and r1,0xff

; Преобразуем байт в ASCII-строку в HEX-представлении
    adr r2,key_code+1
    mov r3,2
    mov r0,r1
hex_convert:
    and r1,0xf
    cmp r1,0xa
    addcs r1,0x7
    add r1,0x30
    strb r1,[r2]
    sub r2,1
    lsr r1,r0,4
    subs r3,1
    bne hex_convert

; Выводим строку в консоль
    movw r0,0x9000  ; Адрес консоли 0x10009000
    movt r0,0x1000
    ldrb r1,[key_code]
    strb r1,[r0]
    ldrb r1,[key_code+1]
    strb r1,[r0]
    ldrb r1,[key_code+2]
    strb r1,[r0]
 
finish:
    b start

key_code:
    db "00 "

---

Результат работы программы:

https://pic.maxiol.com/images2/16931...4.keyboard.png

В эмулируемом компьютере клавиатура подключена с помощью MMIO (Memory-mapped I/O) контроллера PL050, порты которого смотрят прямо в память, а базовым является адрес 0x10006000:

Address	Type	Description
Base + 0x00	rw	Control register.
Base + 0x04	r	Status register.
Base + 0x08	rw	Received data (read)/ Data to be transmitted (write).
Base + 0x0c	rw	Clock divisor register.
Base + 0x10	r	Interrupt status register.

А это значения битов статусного регистра:

Bits	Name	Description
0	KMID	This bit reflects the status of the KMIDATAIN line after synchronizing.
1	KMIC	This bit reflects the status of the KMICLKIN line after synchronizing and sampling.
2	RXPARITY	This bit reflects the parity bit for the last received data byte (odd parity).
3	RXBUSY	This bit indicates that the PrimeCell KMI is currently receiving data. 0 = idle, 1 = receiving data.
4	RXFULL	This bit indicates that the receiver register is full and ready to be read. 0 = receive register empty, 1 = receive register full, ready to be read.
5	TXBUSY	This bit indicates that the PrimeCell KMI is currently sending data. 0 = idle, 1 = currently sending data.
6	TXEMPTY	This bit indicates that the transmit register is empty and ready to transmit. 0 = transmit register full, 1 = transmit register empty, ready to be written.
7	-	Reserved. Read unpredictable.

Здесь используется стандартный набор 2 скан-кодов AT-клавиатуры:

PS/2 keyboard scan codes (scan code set 2)

KEY	MAKE	BREAK	-----	KEY	MAKE	BREAK	-----	KEY	MAKE	BREAK
A	1C	F0,1C		9	46	F0,46		[	54	FO,54
B	32	F0,32		`	0E	F0,0E		INSERT	E0,70	E0,F0,70
C	21	F0,21		-	4E	F0,4E		HOME	E0,6C	E0,F0,6C
D	23	F0,23		=	55	FO,55		PG UP	E0,7D	E0,F0,7D
E	24	F0,24		\	5D	F0,5D		DELETE	E0,71	E0,F0,71
F	2B	F0,2B		BKSP	66	F0,66		END	E0,69	E0,F0,69
G	34	F0,34		SPACE	29	F0,29		PG DN	E0,7A	E0,F0,7A
H	33	F0,33		TAB	0D	F0,0D		U ARROW	E0,75	E0,F0,75
I	43	F0,43		CAPS	58	F0,58		L ARROW	E0,6B	E0,F0,6B
J	3B	F0,3B		L SHFT	12	FO,12		D ARROW	E0,72	E0,F0,72
K	42	F0,42		L CTRL	14	FO,14		R ARROW	E0,74	E0,F0,74
L	4B	F0,4B		L WIN	E0,1F	E0,F0,1F		NUM	77	F0,77
M	3A	F0,3A		L ALT	11	F0,11		KP /	E0,4A	E0,F0,4A
N	31	F0,31		R SHFT	59	F0,59		KP *	7C	F0,7C
O	44	F0,44		R CTRL	E0,14	E0,F0,14		KP -	7B	F0,7B
P	4D	F0,4D		R WIN	E0,27	E0,F0,27		KP +	79	F0,79
Q	15	F0,15		R ALT	E0,11	E0,F0,11		KP EN	E0,5A	E0,F0,5A
R	2D	F0,2D		APPS	E0,2F	E0,F0,2F		KP .	71	F0,71
S	1B	F0,1B		ENTER	5A	F0,5A		KP 0	70	F0,70
T	2C	F0,2C		ESC	76	F0,76		KP 1	69	F0,69
U	3C	F0,3C		F1	05	F0,05		KP 2	72	F0,72
V	2A	F0,2A		F2	06	F0,06		KP 3	7A	F0,7A
W	1D	F0,1D		F3	04	F0,04		KP 4	6B	F0,6B
X	22	F0,22		F4	0C	F0,0C		KP 5	73	F0,73
Y	35	F0,35		F5	03	F0,03		KP 6	74	F0,74
Z	1A	F0,1A		F6	0B	F0,0B		KP 7	6C	F0,6C
0	45	F0,45		F7	83	F0,83		KP 8	75	F0,75
1	16	F0,16		F8	0A	F0,0A		KP 9	7D	F0,7D
2	1E	F0,1E		F9	01	F0,01		]	5B	F0,5B
3	26	F0,26		F10	09	F0,09		;	4C	F0,4C
4	25	F0,25		F11	78	F0,78		'	52	F0,52
5	2E	F0,2E		F12	07	F0,07		,	41	F0,41
6	36	F0,36		PRNT SCRN	E0,12, E0,7C	E0,F0, 7C,E0, F0,12		.	49	F0,49
7	3D	F0,3D		SCROLL	7E	F0,7E		/	4A	F0,4A
8	3E	F0,3E		PAUSE	E1,14,77, E1,F0,14, F0,77	-NONE-

[свернуть]

То есть каждая клавиша имеет скан-коды для нажатия (make) и для отпускания (break). Так, при нажатии клавиши "A" мы получаем скан-код 0x1C, и продолжаем получать его вплоть до отпускания клавиши. А в момент отпускания генерируется двухбайтный скан-код 0xF0, 0x1C.

Теперь для тренировки вы можете попробовать подправить программу таким образом, чтобы она выводила не скан-код клавиши, а непосредственно её значение.

Для программирования голого распберри есть версия Лазаруса -Ультибо.
http://www.freepascal.ru/forum/viewtopic.php?t=11237
https://ultibo.org/wiki/Main_Page
https://ultibo.org/
Есть графический движок для Ультибо https://bshark.org/

Цитата:

---

Сообщение от Smalovsky

Для программирования голого распберри есть версия Лазаруса -Ультибо.

---

Да, спасибо, я встречал уже упоминания о Ultbio. А ещё народ на Си пишет серьёзные вещи под голое железо с использованием уже упоминавшейся библиотеки Circle. Отличный пример такого результата - эмулятор ZXBaremulator. Это всё хорошо, но такие решения по сути своей ничем не отличаются от обычного программирования на языках высокого уровня - всю работу по обслуживанию железа берут на себя библиотеки, не важно через операционную систему или напрямую. А, как я уже писал, для меня программирование на ассемблере голого железа - это своего рода спорт. В данном случае результат - дело второе, важнее сам процесс. Мне лично это доставляет точно такое же удовольствие, как и программирование на Спектруме. А особенно, если что-то получается ;)

Не знаю, заметили вы или нет, но примеры, которые я привёл выше, хоть и написаны на ассемблере для процессора ARM, который лежит в основе Raspberry Pi, не предназначены для запуска из на Raspberry Pi. Приведённые примеры относятся к плате разработке Arm Versatile Express. О чем говорит ключ запуска эмулятора QEMU "-M vexpress-a9"

Есть несколько разновидностей этого устройства и выглядят они примерно так:

https://pic.maxiol.com/thumbs2/16932...eexpressin.jpg https://pic.maxiol.com/thumbs2/16932....vexpress1.jpg

На задней панели выведены следующие разъёмы и порты:

https://pic.maxiol.com/images2/16932...1rearpanel.png

Одних только UART можно насчитать 4 шт.!

Данная плата предназначена прежде всего для разработчиков и в свободной продаже отсутствовала. Но я выбрал его в качестве целевой просто потому, что именно для неё я нашёл первые примеры на ассемблере с выводом графики (помните демо FreeFull?), которые можно было скомпилировать и запустить под эмулятором QEMU. При этом эмулятор поддерживает необходимый минимум устройств:

• PL041 audio
• PL181 SD controller
• PL050 keyboard and mouse
• PL011 UARTs
• SP804 timers
• I2C controller
• PL031 RTC
• PL111 LCD display controller
• Flash memory
• LAN9118 ethernet

И программируется всё это легко, так как адресуется, как обычная память (MMIO). Пример инициализации и работы с графическим экраном (PL111) есть, с клавиатурой (PL050) я тоже привёл. Не хватает реализации работы с внешним накопителем (PL181), и неплохо бы ещё уметь программировать звук (PL041). Но, опять же, адреса этих устройств известны, и при достаточном усердии и с ними тоже можно научиться работает. И всё бы хорошо, но реальные устройства - это слишком нишевый продукт, да ещё и недоступный для простых смертных.

Другое дело Raspberry Pi - одна из моделей скорее всего лежит где-нибудь в закромах у многих! Но тут обратная ситуация, во-первых всё программируется сложнее, так как прямого доступа к железу всё-таки нет, а во-вторых все примеры, которые можно найти запускаются исключительно на реальном железа, а под эмулятором они же работать не хотят.

Вот поэтому я начал своё изучение ARM с платформы Arm Versatile Express под эмулятором параллельно пытаясь разобраться как всё-таки можно что-то писать под Raspberry Pi и потом запускать не только на реальном железе, но и под эмулятором для отладки. И мои старания не прошли даром, мне удалось таки решить эту задачу.

А в заключении этого сообщения хочу поделиться с вами ссылкой на страничку Arm IntrO Challenge, где помимо уже опубликованной демки FreeFull, есть ещё несколько примеров на ассемблере для Arm Versatile Express.

https://io.netgarage.org/arm/digitalcold2.png

https://io.netgarage.org/arm/blasty1.png

А теперь давайте перейдём непосредственно к Raspberry Pi. Если вы, как и я, всерьёз интересовались bare metal программированием Raspberry Pi, то вы довольно быстро вышли на репозиторий Perter'а Lemon'а aka krom. О нём я уже упоминал в одном из предыдущих постов.

Вот адрес этого замечательного репозитория: https://github.com/PeterLemon/RaspberryPi

Здесь автор на чистом bare metal ассемблере на примерах показывает как запрограммировать то или иное действие на Raspberry Pi. Здесь вы найдёте примеры "Hello, World!" в графическом режиме, опроса геймпада NES, подключенного к GPIO-порту, вывод звука в разных режимах, анимацию фракталов, и даже вывод видео! А также много чего ещё, включая эмулятор GameBoy. Это поистине бесценная кладезь примеров! И там помимо исходных текстов сразу лежат скомпилированные бинариники для запуска на реальных микрокомпьютерах Raspberry Pi. И я лично убедился, что они работают! Рекомендую и вам сделать то же самое. Для этого нужно всего лишь скачать с репозитория скомпилированные ядра (kernel*.img) и записать их на SD-карту вместо существующих, рядом с другими системными файлами. Более подробно о загрузке Raspberry Pi я писал ранее.

Но при попытке запустить эти примеры под эмулятором, вас будет встречать лишь чёрный экран. Собственно, и меня он встречал. А когда я спросил Питера, как же он отлаживал свой код, он мне ответил, что после того, как написал что-то и откомпилировал, он честно записывал всё на SD-карту и проверял что получилось на реальной Raspberry Pi. То есть никакого отладчика и никакого эмулятора. Капец, как грустно! Я так точно не умею! И это на фоне того, что мне так и не удалось найти ни одного упоминания о том, что кто-то что-то запустил под эмулятором QEMU, кроме RaspbianOS с кастомным ядром.

Однако в итоге выяснилось, что всё не настолько печально! И вот вам в качестве доказательства пара скриншотов программ Питера Лемона, запущенных под эмулятором QEMU:

https://pic.maxiol.com/thumbs2/16934...mondelbrot.png https://pic.maxiol.com/thumbs2/16934...384.videos.png

Очень интеесная тема! Спасибо!

Прежде чем окончательно перейти к теме эмуляции, мне хочется рассказать про ещё один метод отладки программ прямо на железе.

Первые bare metal программы начали появляться практически сразу после выхода Raspberry Pi. Понятное дело, что про эмуляцию на тот момент речи не шло, так как платформа только-только вышла. И поэтому энтузиасты вслепую писали свой код, далее записывали скомпилированное ядро на SD-карту и проверяли его работоспособность непосредственно на железе.

Вот так выглядела типичная проверка кода без какого-либо инструментария:

1. Выключаем Raspberry Pi
2. Извлекаем из неё SD-карту
3. Вставляем SD-карту в кард-ридер
4. Подключаем кард-ридер к компьютеру
5. Монтируем карту и ждём
6. Копируем бинарный файл на SD-карту
7. Синхронизируемся и ждём
8. Размонтируем карту
9. Вставляем SD-карту в Raspberry Pi
10. Включаем Raspberry Pi
11. Начинаем всё сначала

Очень долго и муторно. А ведь именно так и отлаживал свои программы упомянутый мной выше Питер Лемон. Но, к счастью, энтузиаст David Welch (dwelch67) придумал и воплотил метод, который существенно облегчил жизнь bare metal программистам. Суть метода заключается в том, что на SD-карту один раз записывается загрузчик, а сама Raspberry Pi подключается к компьютеру посредством USB-TTL адаптера:

https://pic.maxiol.com/thumbs2/16935...9127.uart1.jpg
https://pic.maxiol.com/thumbs2/16935...9127.uart2.jpg

Подключение осуществляется всего тремя проводами к разъёму GPIO:

• GPIO6 - GND
• GPIO8 - RXD
• GPIO10 - TXD

https://pic.maxiol.com/thumbs2/16936...aspberrypi.png
Единственная задача загрузчика - загрузка файла по UART в ОЗУ и передача ему управления. Это мне напомнило загрузку компьютер Вектор-06Ц, только там использовался не UART, а магнитофонный порт :) Сам загрузчик располагается по адресу 0x200000, то есть у вас есть 0x200000 байт (2 Мб) под собственную программу.

Таким образом, с помощью этого загрузчика всё сводится к следующим действиям:

1. Выключаем Raspberry Pi
2. Включаем Raspberry Pi
3. На компьютере набираем команду передачи файла.

Но всё можно ещё более упростить, если распаять кнопку RESET, пины под которую есть на всех моделях Raspberry Pi:

https://pic.maxiol.com/thumbs2/16935...7.rpireset.jpg

Так вот если эту кнопку распаять, то первые два пункта сводятся просто к нажатию на RESET.

Думаю, что такой метод отладки не потерял своей актуальности и сегодня, когда QEMU более-менее сносно научился эмулировать Raspberry Pi.

Ну и в заключении приведу ссылку на репозиторий с исходниками и скомпилированным загрузчиком (есть несколько его версий), о котором шла речь в этом сообщении: https://github.com/dwelch67/raspberrypi

Отснял небольшой ролик с демонстрации работы загрузки по UART:

https://youtu.be/Q6lSKKkWipk

Используемый загрузчик: https://github.com/dwelch67/raspberr...r05/kernel.img
Самая первая программа (мигание светодиодом): https://github.com/dwelch67/raspberr.../blinker01.bin

В видео используется вот этот терминал: https://www.emtec.com/zoc/index.html
Если кто-то знает какой-то терминал попроще и побесплатнее, и который ещё заработает в этой связке, то пожалуйста, поделитесь ссылкой.

UPDATE

Нашёл ещё одну терминальную программу, которая успешно передаёт файлы. На этот раз программа бесплатная и с исходниками. Называется Tera Term.

https://pic.maxiol.com/images2/16937....terraterm.png

Не знаю проблема ли это моего конкретного адаптера или, возможно, это везде так, но нормальное общение и передача данных возможна только на скорости 115200 бит/сек - ни больше, ни меньше. Имейте это ввиду, если вдруг захотите тоже попробовать.

Ну вот теперь мы вплотную приблизились к эмулятору Raspberry Pi. На самом деле я мог бы сейчас одной фразой сказать, как скомпилировать программу, чтобы она запустилась на эмуляторе. Но, думаю, что так будет менее интересно. Судя по активности, данная тема заинтересовала лишь 2-3 человека, да и для них, скорее всего интересен не конечный результат, а повествование. Поэтому я расскажу, как я пришёл к конечному результату, шаг за шагом.

Для того, чтобы писать приложения под операционную систему особенно не требуется каких-то изощрений. Писать и отлаживать можно прямо на Raspberry Pi. Другое дело низкоуровневое программирование - bare metal. Здесь нужно либо поверять написанную программу на реальном железе, либо иметь эмулятор. Правда в итоге написанную программу всё равно придётся запускать на настоящем микрокомпьютере, так как ни один эмулятор не способен обеспечить 100%-ного качества эмуляции. Пик интереса к bare metal программированию пришёлся на 7-10 лет назад, спустя короткое время после выхода Raspberry Pi, когда этот микрокомпьютер утвердился в качестве некоего стандарта, и когда появилось достаточное количество информации о его схемотехнике. Но на тот момент вообще не существовало какого-либо эмулятора этого устройства. Да, уже тогда существовал QEMU, который неплохо эмулировал устройства, базирующие на архитектуре ARM, но среди них не было платформы Raspberry Pi. Разработчики игры PiFox, очевидно для удобства отладки, на базе QEMU сделали свой эмулятор, который худо-бедно мог эмулировать архитектуру Raspberry Pi. Доводилось мне читать упоминания и о других подобных начинаниях. Но в конечном итоге, спустя несколько лет в QEMU появилась официальная поддержка Raspberry Pi. И начали они с эмуляции Raspberry Pi 2. А на сегодня мы имеем возможность эмулировать Raspberry Pi 1, 2, 3 и Zero.

Когда я только начал изучать вопрос, то поиски приводили меня лишь к всевозможным инструкциям для запуска RaspbianOS на QEMU. Сам запуск осуществлялся на кастомном ядре и на архитектуре отличной от Raspberry Pi - Arm Versatile. Предлагались инструкции по самостоятельным конфигурированию и сборке ядра, также готовые ядра под разные версии RaspbianOS. Но в итоге в QEMU завезли нативную эмуляцию Raspberry Pi и появилась возможность использовать стандартное ядро для запуска RaspbianOS. Правда, ядро не может подхватываться из образа, его предварительно необходимо оттуда извлечь, положить рядом с загружаемым образом и прописать в ключ запуска.
Вот так примерно будет выглядеть довольно длинная строка запуска нативной эмуляции RaspbianOS:

Код:

---

qemu-system-aarch64 -M raspi3b -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1" -dtb ./dtbs/bcm2710-rpi-3-b-plus.dtb -sd 2020-08-20-raspios-buster-armhf-full.img -kernel kernel8.img -m 1G -smp 4 -serial stdio -usb -device usb-mouse -device usb-kbd

---

И действительно, всё загружается и работает. Только это никак не помогает понять как же загрузить свою собственную программу в эмулятор QEMU. Из всего этого стало лишь понятно, что нужен особым образом скомпилированный kernel. И что я только не делал, как только не экспериментировал, но моя программа отказывалась запускаться под эмулятором. Вот оно по всем законам должно работать, но работает! И, честно сказать, руки мои практически опустились. Но тут мои поиски привели меня вот к этому примеру. Этот пример написан на ассемблере, он в графическом виде выводит надпись "NO OS" на экран, а также выводит надпись "No OS installed" в консоль. И при этом данный пример должен был запускаться под эмулятором! (Тоже скачайте его себе для экспериментов, я в дальнейшем буду объяснять всё именно на его примере!)

И у меня получилось скомпилировать и запустить эту простую программу под эмулятором!

https://pic.maxiol.com/thumbs2/16937...8384.noos1.png https://pic.maxiol.com/thumbs2/16937...8384.noos2.png

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

FASMARM

В качестве кросс-ассемблера я остановил свой выбор на FASMARM. Я уже достоверно не помню как я на него вышел, но скорее всего потому что этот кросс-ассемблер фигурировал в примерах Питера Лемона. По своей сути FASMARM является аддоном для Flat Assembler и работает как под Windows, так и под Linux. Этот инструмент представляет из себя крохотный по сегодняшним меркам исполняемый файл. Он не требует инсталляции и не подтягивает какие-либо сторонние библиотеки.

Любопытно, что данный кросс-ассемблер сам написан на ассемблере. А что самое интересное - все последние версии FASMARM компилируются на Flat Assembler'е, то есть на самом себе.

Скачать сам ассемблер и его исходники можно с официальной странички: https://arm.flatassembler.net/

Использование его предельно простое:

Код:

---

fasmarm filename.s

---

А на выходе моментально получим готовый для запуска файл filename.bin.

Но определяющим при выборе ассемблера для меня стал всё-таки синтаксис. Дело в том, разные программы написанные на ассемблере ARM под разные компиляторы скорее всего потребуют доработок, а иногда весьма серьёзных из-за различий в синтаксисе. Например, FASMARM для обозначения комментариев использует привычную для меня точку с запятой ( ; ), а стандартные инструменты для этой же цели используют "собаку" ( @ ). Также весьма существенно отличается синтаксис макросов, обозначение чисел, наличие и отсутствие некоторых псевдокоманд. Нет смысла сейчас подробно останавливаться на этих различиях, а достаточно просто знать, что они есть.

Большую часть примеров, которые я находил в начале моего изучения, я смог скомпилировать на FASMARM либо вообще без переделок, либо с какими-то минимальными доработками. И вот как раз тот самый единственный найденный мной пример, который должен запускался под эмулятором, ни в какую не хотел переделываться под FASMARM. Да, к тому же ещё требовал линковки. Пришлось разбираться как компилировать другим инструментом. Оказалось, что там тоже нет ничего сложного.

Arm GNU Toolchain

Для начала нужно скачать инструментарий на сайте ARM. Инструментарий бесплатный, но с недавних пор, чтобы скачать его из РФ придётся воспользоваться VPN или Tor.
Качаем с этой страницы: https://developer.arm.com/downloads/...hain-downloads
Прямую ссылку на установочный файл не привожу, так как с выходом новых версий она меняется. Но вам нужно будет скачать примерно такой файл: arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-arm-none-eabi.exe ,где:
w64-i686 - платформа компилятора Windows 64 бит
arm-none-eabi - целевая платформа ARM 32 бит

Скачиваем и устанавливаем.

Чтобы скомпилировать тот самый пример я подготовил вот такой bat-файл, основываясь на информации из Makefile:

Код:

---

@set file=boot-arm-raspi
@set toolchain="c:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\12.3 rel1\bin\arm-none-eabi"

python bmp2inc.py > bmp_no_os.inc
%toolchain%-as -o %file%.o -mcpu=arm1176jzf-s %file%.s
%toolchain%-ld -o %file%.elf -Ttext 0x8000 %file%.o

@if exist %file%.o del %file%.o

---

На выходе получаем boot-arm-raspi.elf, который можем запустить в эмуляторе следующей командой:

Код:

---

"c:\Program Files\qemu\qemu-system-arm.exe" -M raspi2b -serial stdio -kernel boot-arm-raspi.elf

---

Оказалось, что QEMU может обрабатывать elf-файлы, забирая оттуда всю необходимую для запуска информацию.

И всё бы хорошо, но этот вариант годится только для компилирования исходников с помощью Arm GNU Toolchain, а мне хотелось как и раньше пользоваться FASMARM. И я в итоге разобрался как прикрутить FASMARM к этой цепочке.

Прежде всего в исходном тексте своей программы в самом начале нужно добавить вот такие строки:

Код:

---

format ELF
    section '.text' executable
    public _start
org 0x8000
_start:

---

А для компиляции я создал вот такой батник:

Код:

---

@set file=filename
@set toolchain="c:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\12.3 rel1\bin\arm-none-eabi"

fasmarm %file%.s
%toolchain%-ld.exe -o %file%.elf -Ttext 0x8000 %file%.o

@if exist %file%.o del %file%.o

---

Ну и сразу здесь же напишу, что на выходе вы можете получить не только elf, но и бинарный файл, который можно записать на SD-карту и запустить на реальной Raspberry Pi. Для этого в конец цепочки компиляции нужно добавить ещё одну строку:

Код:

---

%toolchain%-objcopy %file%.elf -O binary %file%.img

---

Собственно, это и есть рабочий рецепт, которым я и начал пользоваться. И на этом можно было бы завершить данное сообщение. Но оказалось, что на деле для запуска скомпилированых программ под эмулятором можно обойтись вообще без всех этих плясок с Arm GNU Toolchain. И всё делается предельно просто!

В процессе изучения другого вопроса, я натолкнулся на ключ QEMU "-d in_asm", который показывает в консоли последние выполненные команды. Я сделал и скомпилироваал простую программу, состоящую из одной строки:

Код:

---

lable: b lable

---

Я запустил её под эмулятором с указанным ключом. И что же я увидел:

https://pic.maxiol.com/images2/16939...4.deadloop.png

Данная команда работает по адресу 0x10000! Это очень странный адрес! 32-х битные приложения запускаются и работают с адреса 0x8000. Для старых ядер адрес запуска был нулевой (0x0000). (Этот адрес можно вернуть, если в системной файле Raspberry Pi config.txt прописать команду kernel_old = 1.) Есть ещё адрес 0x200000 - это адрес запуска 64-х битных бинарников. Но никогда и нигде мне не попадалось упоминание о 0x10000. Я попробовал скомпилировать и запустить первую попавшуюся программу с этого адреса. И она как ни в чём не бывало запустилась под QEMU! Всё оказалось до безобразия просто.

Для запуска под эмулятором вам нужно всего лишь в своём коде прописать org 0x10000! (Собственно, это и есть та самая фраза, которой можно было ограничиться в этом сообщении.)

Теперь вы можете брать примеры Питера Лемона, о которых говорилось выше, менять там ORG, компилировать, и запускать всё под QEMU.

Создал тематическую группу в Telegram. Кому интересна тема программирования на ассемблере под голое железо (bare metal), милости прошу.

https://t.me/bare_asm

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

Собственно рассказал то, что о чём уже писал в этой теме.

https://youtu.be/cSvmv0Iwx5I?si=TMtEVTBMalHD85tM

CityAceE, вторую часть анонсируем, не стесняемся. ;)

creator, вторая часть уже на канале пару дней как. Третья уже на подходе. Я просто не думал, что здесь это кому-то интересно. А если кому-то интересно, то тот на канал подписался.

https://youtu.be/fmvHJoLzar0

https://youtu.be/aoASJ94qSUI

В этом ролике, вооружившись полученными ранее знаниями, мы выведем на экран нашего эмулируемого устройства чёрно-белую картинку в стандартном формате BMP. В процессе познакомимся с ещё одной, даже двумя, интересными командами процессора ARM.

https://youtu.be/sdt0Apxt1SE

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

https://youtu.be/ff6EZshEBhk

Кстати Raspberry Pi5 разгоняется, и программирование на асме дает большие возможности для вычислений и дем, и всяких акселей типа pistorm.

>Дополнительно можно отметить обеспечение возможности разгона плат Raspberry Pi 5 через повышение тактовой частоты с CPU с 2.4 GHz до 3.14 GHz. Изначально прошивка не позволяла повышать частоту выше 3 GHz, но в неофициально выпущенном обновлении прошивки данное ограничение убрано и на плате теперь можно выставлять значения выше 3 GHz. Судя по отзывам пользователей стабильная работа при стресс-тестировании обеспечивается при выставлении частоты 3.14 GHz и использовании активного охлаждения. При более высоких значениях начинают возникать сбои.

https://www.opennet.ru/opennews/art.shtml?num=60798

Цитата:

---

Сообщение от ^m00h^

Кстати Raspberry Pi5 разгоняется, и программирование на асме дает большие возможности для вычислений и дем

---

У меня есть стойкое убеждение, что отказ от любых прокладок в виде операционных систем превращает даже самую слабую Raspberry Pi в мощнейшую платфму. Если там писать в том же стиле, как пишут демы на Спектрум, то я даже представить не могу, чего можно достичь на Raspberry Pi с её-то мощностями и ресурсами.

Например, написать свою демомейкерскую ось на ARM асме с эффектами))), что-то типа Kolibri OS но с заточкой под демосцену, чтобы все было красиво и с 3d эффектами типа Compiz, и только на асме!

В этом ролике мы инициализируем кадровый буфер Raspbberry Pi, заполним его данными, и запустим результат под эмулятором.

https://youtu.be/zjJP3yEWx-E

В этом ролике мы нарисуем надпись "Hello, World!" в кадровом буфере, разберёмся с загрузкой Raspberry Pi и, наконец, запустим нашу программу на реальном железе.

https://youtu.be/MaPtB40IrDg

Приглашаю всех завтра в воскресенье 7 июля в 16.00 по Москве вместе со мной посмотреть новый ролик. Там я немного расскажу про baremetal эмулятор ZX Spectrum, написанный на ассемблере для Raspberry Pi. Найду и починю авторские ошибки и расскажу про инструмент, который я сделал для поиска ошибок эмуляции. Ролик снова получился длинным - 53 минуты, так что можете расценивать его как стрим, там более, что я буду в этот момент в чате премьеры вместе с вами.

https://youtu.be/z5eR7t2AMyo

Кстати, есть Purebasic 6 под платформу. Кто-нить пробовал?