https://github.com/libopencm3/libopencm3

ИМХО хорошая альтернатива стандартной библиотеке от ST и не только.

У меня есть пара проектов, с UART-ом на 2-3 мегабита, без DMA оно как-то не очень весело, тем более что процу есть чем в это время заниматься.

Проблема не понятна... Оно прям так нужно, ошибки UART? Там, где оно реально может сбоить, все решается протоколом верхнего уровня.

Если нужен контроль ошибок на таких скоростях (хотя, я лично не понимаю, что такого может успеть сделать мелкоконтроллер, чтобы отдать это на 2-3мегабита — разве что тупо читать данные с чего-то и по DMA же их в буфер отправки помещать), то советую вместо UART'а CAN использовать. Там оно все как-то "автоматически" получается.

Подавляющее большинство трансиверов CAN рассчитаны на скоростя до 1Мбит и лишь некоторые до 2МБит/сек.

Можно, но не удобно, т.к. слишком много работы по переводу проекта под неё.

Есть пара минусов, из-за которых я проголосую против libopencm3: меньшая распространенность по сравнению с spl и hal, и отсутствие поддержки ее со стороны ST (да впрочем со стороны NXP та же ситуация). Очень много исходников уже написано на базе spl и очень много будет написано на hal. Так, например FreeRTOS+TCP, FreeRTOS+FAT приводит пример порта именно под hal, в файловой системе yaffs порт под spl, под lwip по первым ссылкам в гугле найдете массу примеров и под spl и под hal. А если просто заглянуть в исходники местных разработчиков, какая частота появления там spl, hal, и какая частота libopencm3. Относительная распространенность spl и hal облегчает миграцию исходников между различными разработчиками и проектами. Это, кривая конечно, но унификация. Какой смысл переписывать то, что уже написано на spl и hal под libopencm3? Ошибки и неоптимальности в spl и hal? Ну так не лучше ли бороться с ними?

Правильней было бы так сказать: ни в коем случае не использовать ни неподдерживаемый спл, ни "калокуб", ни даже opencm3. Все они ужасны!
Есть CMSIS. Его и использовать. Часть вещей можно на макросах оформить. Но ни в коем случае не пихать жирные функции. Я ужасался, когда читал исходники spl, не меньше был в шоке, читая исходники opencm3: там, где элементарно на трех-четырех 32-битных записях регистров можно настроить конфигурацию, в библиотеке выполняется чуть ли не на полтора порядка больше операций! Какой смысл платить жирнотой и убожеством кода за скорость разработки? Это уже ардуйня какая-то получается, когда основной целью является во что бы то ни стало заставить некий датчик работать. Пусть даже десятикратным "запасом" вычислительных мощностей, стократным раздуванием размера прошивки и превращением простой задачи в тормознутый конвейер из-за того, что все, что должно было работать аппаратно, выполняется ногодрыгом — ведь так "проще", чем даташит почитать!
Для файловых систем я бы поискал реализацию ext2: какой смысл пихать на флешку жирный vfat, который при этом жутко ограничен?
Для lwip никаких калокубов не нужно.
Насчет ртоси поспорил бы. Не вижу смысла в использовании фриртоси в подавляющем большинстве проектов. 99.9% прошивок влегкую обойдутся без ртоси — на простом КА.

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

И что в этом хорошего? Да и смысл? Обычно карточку потом на компьютере считывают — здесь как раз ext2 лучше, т.к. поддерживается всем, чем угодно.

Обычно на том компьютере (не вашем, разумеется) стоит Windows, которая о ext2 знать ничего не знает.

А я и говорю, что проще HAL портировать на комповую платформу, чтобы текст записи в регистры выдавал