Пытаюсь скопировать в переменную uint_64t восемь байт из массива с определённого его индекса. Конструкция такая:
((uint64_t*)&write_key)[0]=(((uint64_t*)(rx_buffer+5))[0]);

write_key - переменная 64 бита.
rx_buffer - байтовый массив.

В строчке пытаюсь копировать с 5 элемента и программа вылетает в Hard Fault.
Если копировать с 0 или 4 элемента то всё ок. Понимаю что что связанно с адресацией но что именно?
Микроконтронтроллер STM32f0, среда IAR. На PC эта же строчка с 5 индексом прокатывает.
Что делаю не так?

memcpy(&write_key, &rx_buffer[5], 8);

а так?

unaligned access

Используйте memcpy

Так тоже не прокатило. Туда же в ошибку и улетает.


Да, memcopy то я туда и поставил, только memcopy побайтно копирует, а хотелось по словам.

memcpy копирует не побайтно, а оптимально с учетом выравнивания. Довольно сложная процедура.

Прежде чем что-то советовать надо научиться читать и понимать то, что пишут. Чтобы не писать ерунду.
Из контекста исходного сообщения автора видно, что write_key - это не указатель, а переменная в которую нужно записать. Это во-первых. А во-вторых - читайте про невыровненный доступ в Cortex-M.


Для IAR (а может и других компиляторов):
...и уже сам компилятор решит какие команды использовать.

А можно просто выровнять буфер если считываемые слова выравнены относительно друг друга. Если нет, делайте memcpy - так правильней всего и компилятор оптимизирует вызовы обычно.

В случае с __packed u64 если в buildtime известно, что ((uint)(rx_buffer+5) & 3) == 0, то компилятор для чтения сгенерит одну команду LDRD (если она есть в данном ядре, ну или две LDR). А про memcpy() я совсем не уверен, что получится так же оптимально.

Да, спасибо. Ваш способ подошёл. Но я так понимаю, что так как переменные не выровнены в памяти, то он всё рано будет копировать побайтно.

А если делать через memcpy, как советует Kabdim, то компилятор разве не будет побайтно копировать?

Пока писал вопрос уже ответили - и я вот сомневаюсь насчёт memcpy.

Зря не верите, все современные компиляторы насколько я знаю оптимизируют это в релизбилде. Другое дело что они не всегда по коду могут сказать что ((uint)(rx_buffer+5) & 3) == 0. Но в этом случае ни один, ни второй метод не будут соптимизирован.
Можно сделать аля:

И продолжать жечь в духе первого поста. Только возможно еще и с индексами, а не с адресной арифметикой.

Нет, если компилятор на этапе сборки кода будет знать, что ((uint)(rx_buffer+5) & 3) == 0, то он использует LDRD или пару LDR. Если нет, но ((uint)(rx_buffer+5) & 1) == 0, то он может использовать LDRH,LDR,LDRH. Если на этапе сборки кода значение rx_buffer неизвестно, то будет использовать побайтный доступ.

Понял, спасибо!

Вычитал в в аналогичном топике, что оказывается STM32f4 об этом думать не нужно. Вот и у меня видимо до этого так раньше работало в других проектах.
https://electronix.ru/forum/lofiversion/ind...hp/t140216.html

Нет, не поэтому. Не нужно для операций LDR/STR - только они поддерживают невыровненный доступ на M3/M4. А если Вы пишете тип u64, то для работы с таким типом компилятор может применить LDRD/STRD, а эти команды не поддерживают невыровненный доступ даже в M4.
Хотя может какой-то конкретный, не очень оптимизирующий компилятор, вместо одной LDRD, может применить пару LDR, тогда прокатит.
Но чтобы не гадать, хорошим тоном является явное указание невыровненности переменной (__packed), тогда компилятор сам решит как нужно работать с данной переменной на данном ядре. И не будет сюрпризов при переносе кода на другое ядро.

PS: Да и учиться нужно не по "топикам" где могут нести какую угодно чушь, а по мануалам на ядро. Там всё разжёвано.

Да, всё правильно в моём случае сейчас переменная 64 бита и она для процессора тоже не родная.
Да, я в той теме всё ваши советы прочитал. А если учится только по мануалам, то можно учиться всю жизнь - некогда, работать надо!
Спасибо вам за помощь!