Имею буфер приема от панели управления (в составе структуры FPI)
uint8_t FP_RBf[2];
Хочу прочитать этот буфер и вызвать функцию по значению первого байта, и значение второго байта передать в функцию, как int32_t.

Однако заметил, что при считывании RBf[1] компилятор использует команду LDRB, а не LDRSB

Т.е. не происходит знакового расширения байта. Как сделать правильно?

Заменил тип в буфере на int8_t. Получилось следующее:

Так оно работает, но непонятки остались... Теперь обе переменные размножили знак.

Не знаток АРМа, но навскидку: во-первых, зачем ручное преобразование типов - ведь

uint32_t KeyNum = FPI.FP_RBf[0];

даст то же самое.

Во-вторых, исходный операнд у вас беззнаковый, т.е. знака там нет в принципе, поэтому расширять нечего и по правилам стандартных преобразований типов компилятор просто честно забивает нулями старшие биты. Когда вы поменяли тип источника на знаковый, то знак появился и опять же по тем же правилам стандартных преобразований С/С++ компилятор должен выполнить расширение знака.

Ну, эта строка написана "по инерции" за компанию, чтобы не отличалась от следующей.
Вот какое решение нашлось, для буфера из uint8_t

Как видите, нашлось что расширять

Да, проходит и такое.
А я уж было "изобрел" конструкцию "с двойным преобразованием"

А, может, так, как я написал, надежнее, правильнее? Все-таки, конкретное указание...

Второе преобразование (int32_t) компилятор сделает сам (причем молча - это вполне штатная ситуация). Так что от наличия или отсутствия (int32_t) в приведении ничего не изменится.

Полностью согласен. Правая часть выражения должна быть приведена к размерности переменной в левой части.
Остался маленький вопросик - преобразование беззнакового байта в знаковый - это просто "подмена представления", не вызывающая у компилятора даже варнинга? Все-таки, например, 255 превращается в -1, и ничего страшного?

С чего компилятору тут ругаться - ведь ему же программистом указано. Предупреждения компилятор выдает, когда имеет место неявное преобразование, которое делается как бы скрытно и поэтому может привести к неожиданному (для программиста) поведению кода. Если программист сам руками указал, что этот объект в данном случае трактовать так и не иначе, то компилятор должен выполнять.

Другое дело, что сишная форма явного преобразования типов этакая "неброская", ее иногда легко пропустить при чтении кода - похожа на аргумент выражения или функции. Поэтому в С++ специально ввели новый синтаксис для явного преобразования типов, который своим безобразным видом сразу привлекает к себе внимание - чтобы в случае чего можно быстро увидеть потенциально опасные места. Ну, и еще разделили единую форму на две различные, отличающиеся степенью опасности: static_cast и reinterpret_cast.