jcmvbkbc

Первая проблема что нужно при скорости 9600 бит/c передача одного бита должна происходить прмерно 1/9600 = 104 микорсекунды. HAL_Delay поддерживает минимальный период 1 милисекунда.

Это говорит о том, что нужно использовать другой метод для организации задержки. Например основанный на таймере со счётчиком.

какой надо выставлять уровень напряжения на пине в простое

Стандартно -- высокий логический. Сколько вольт этому должно соответствовать конкретно -- зависит от того, что вы подключите снаружи. Явно там будет какой-нибудь конвертор или другой микроконтроллер.

uint8_t led_state = 0x03; Данной командой мы завели переменную, которая равна 3

В коде написано 2.

что под этим подразумевается?

2 -- это вот такое 8-битное двоичное число: 00000010. А если 2 заменить на 3, то число станет таким: 00000011. Улавливаешь связь с количеством и номерами включенных светодиодов?

HAL_GPIO_WritePin(GPIOE, led_state << 8, GPIO_PIN_SET); Это я так понимаю мы сначала устанавливаем самый первый светодиод, т.е. 8, но на практике ни так.

Нет, светодиоды на схеме подключены к битам 8..15, а led_state ты выше видел какое. Этой командой мы сдвигаем биты 0..7 led_state в биты 8..15.

led_state = led_state >> 1 | led_state << 7;Эту строку совсем не понимаю.

Это циклический сдвиг вправо на 1. Т.е. биты "выдвигаемые" вправо за пределы led_state появляются слева.
т.е. двоичное число abcdefgh превращается в 0abcdefg | h0000000 = habcdefg.

g++  ...   src/core_cm3.c src/system_stm32f10x.c -o build/main

src/core_cm3.c: Assembler messages:
src/core_cm3.c:447: Error: no such instruction: `mrs %eax,psp'

На какой системе ты выполняешь сборку, на x86? Тогда чтобы получить код для arm тебе нужен не g++, а какой-нибудь arm-linux-gnueabi-g++.

Вопрос номер раз: как такое вообще произошло?

Насколько я понимаю STM32F207xx не поддерживает инструкцию uxtah, потому что это инструкция Thumb2 не реализованная в CortexM3.

Вопрос номер два: как такое фиксить?

Подозреваю, что ключом -march=, вероятно -march=armv6.

С чем связана ошибка «failed execute mi command»?

Скорее всего -- с багом в отладчике.
Попробуй то же самое, но с программой собранной с -O0 или -Og.

P.S. выделение памяти в прерываниях зло и т.д. ага.

Дело говоришь. Вообще какая-либо существенная работа в обработчике прерывания -- зло. Избегай этого по возможности.

Так вот, что бы не проставлять кучу __disable_irq(); __enable_irq();

А никак иначе. Но обычно есть возможность делать не disable/enable а save+disable/restore, т.е. запрещать прерывания, одновременно возвращая текущее состояние запрета и восстанавливать это состояние.

#define SERVO_180 8200
#define SERVO_0 1800
void set_pos(uint8_t pos) {
  uint32_t tmp = (SERVO_180 - SERVO_0) / 180;
  TIM2->CCR2 = SERVO_0 + tmp * pos;
}

Фуфуфу, сначала умножать, потом делить, иначе потеряете в точности и получите большой недобор на больших углах.
Кроме того, сдаётся мне, что эта формула должна выглядеть так:

uint32_t tmp = ((SERVO_180 - SERVO_0) * pos) / 180 + SERVO_0;
  TIM2->CCR2 = tmp;

не?

сервопривод начинает сходить с ума

Вы бы описали, как именно.