ARM, RISC-V контроллеры

У тебя проблема уже есть, несмотря на то, что "не нужно". Причём до тебя похоже не доходит, что проблема куда шире... (чем не работающий memcpy). 

Это вообще какая-то проблема -- неспособность к абстрактному мышлению. teap0t недавно же ссылочку интересную давал:

http://caxapa.ru/1013710/

https://web.archive.org/web/20180515032438/https://www.psychology-online.net/articles/doc-613.html

Какая разница вообще что тебе там (не)требуется в частном случае? Невозможно вообще мыслить в рамках отдельных частных случаев -- тогда мышление сводится к знанию и оперированию ограниченным набором фактов. Нужно уметь вводить новые абстракции, по возможности наиболее *простые*, имеющие минимальный необходимый набор свойств, связей с фактами. И из этих *простых* кубиков можно строить уже более сложные конструкции, в частности компьютерные программы. А если кубик изначально имеет не 6 граней, а сложную форму и два десятка граней -- составить эти кубики вместе уже сложно, если вообще возможно. Это именно твой случай кубик из нестандартных типов с одной стороны не стыкуется с другими общепринятыми кубиками.

Зачем тебе знать, что у тебя программа будет работать в кубе, на STM32, с LPC17 и с компилятором определённой версии? Пока эти знания тебе только проблем добавляют. Программа состоит из каких-то простых кубиков с ограниченными функциями (классов, структур, функций) и каждый отдельный кубик будет попросту _проще_ не обладай он этими знаниями. Тебе нужна ровно одна понятная и выученная наизусть абстракция (модель ЭВМ используемая в языке C/C++) для создания большинства кубиков, и только некоторые из них (работающие с аппаратурой) должны обладать каким-то конкретным знанием.

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

Обнаруженная тобой проблема есть во всех случаях, когда значение из упакованной структуры передаётся по ссылке или указателю. Скажешь опять, что мол тебе именно здесь и сейчас не нужно? И уже завтра попросту забудешь и будешь жаловаться на плохой Keil глючащий с оптимизацией. Универсальные решения тем и хороши, что работают всегда, а не только сегодня и здесь. Потому, что у них как раз минимум ненужных зависимостей, ненужных ограничений и свойств. Они несмотря на кажущуюся внутреннюю сложность (а когда ты кубик вставляешь в остальную конструкцию его внутреннее устройство тебя волновать не должно -- важны лишь внешние свойства) оказываются _проще_ в использовании, у них меньше число граней, условно говоря, и проще внешняя форма. Из них проще построить то, что не развалится.