Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Скопировать часть массива в переменную 64 бита
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
IgorAVR2
Пытаюсь скопировать в переменную 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 индексом прокатывает.
Что делаю не так?
_pv
memcpy(&write_key, &rx_buffer[5], 8);
Jenya7
а так?
Код
*((uint64_t *)write_key)) = *((uint64_t *)(rx_buffer+5)));
vadon
Цитата
Понимаю что что связанно с адресацией но что именно?


unaligned access

Используйте memcpy
IgorAVR2
Цитата(Jenya7 @ Apr 10 2018, 07:59) *
а так?
Код
*((uint64_t *)write_key)) = *((uint64_t *)(rx_buffer+5)));

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


Да, memcopy то я туда и поставил, только memcopy побайтно копирует, а хотелось по словам.
aaarrr
Цитата(IgorAVR2 @ Apr 10 2018, 12:57) *
Да, memcopy то я туда и поставил, только memcopy побайтно копирует, а хотелось по словам.

memcpy копирует не побайтно, а оптимально с учетом выравнивания. Довольно сложная процедура.
jcxz
Цитата(Jenya7 @ Apr 10 2018, 07:59) *
а так?
Код
*((uint64_t *)write_key)) = *((uint64_t *)(rx_buffer+5)));

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

Цитата(IgorAVR2 @ Apr 10 2018, 12:57) *
Так тоже не прокатило. Туда же в ошибку и улетает.

Для IAR (а может и других компиляторов):
Код
typedef unsigned long long u64;
typedef __packed u64 u64p8;
*(u64p8 *)&write_key = *(u64p8 *)&rx_buffer[5];
...и уже сам компилятор решит какие команды использовать.
Kabdim
А можно просто выровнять буфер если считываемые слова выравнены относительно друг друга. Если нет, делайте memcpy - так правильней всего и компилятор оптимизирует вызовы обычно.
jcxz
Цитата(Kabdim @ Apr 10 2018, 14:27) *
А можно просто выровнять буфер если считываемые слова выравнены относительно друг друга. Если нет, делайте memcpy - так правильней всего и компилятор оптимизирует вызовы обычно.

В случае с __packed u64 если в buildtime известно, что ((uint)(rx_buffer+5) & 3) == 0, то компилятор для чтения сгенерит одну команду LDRD (если она есть в данном ядре, ну или две LDR). А про memcpy() я совсем не уверен, что получится так же оптимально.
IgorAVR2
Цитата(jcxz @ Apr 10 2018, 14:00) *
Код
typedef unsigned long long u64;
typedef __packed u64 u64p8;
*(u64p8 *)&write_key = *(u64p8 *)&rx_buffer[5];
...и уже сам компилятор решит какие команды использовать.


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

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

Пока писал вопрос уже ответили - и я вот сомневаюсь насчёт memcpy.
Kabdim
Зря не верите, все современные компиляторы насколько я знаю оптимизируют это в релизбилде. Другое дело что они не всегда по коду могут сказать что ((uint)(rx_buffer+5) & 3) == 0. Но в этом случае ни один, ни второй метод не будут соптимизирован.
Можно сделать аля:
Код
uint64_t inner_buffer[x];
uint8_t *rx_buffer = static_cast<uint8_t*>(&inner_buffer[0]) + 3;

И продолжать жечь в духе первого поста. Только возможно еще и с индексами, а не с адресной арифметикой.
jcxz
Цитата(IgorAVR2 @ Apr 10 2018, 14:43) *
так как переменные не выровнены в памяти, то он всё рано будет копировать побайтно.

Нет, если компилятор на этапе сборки кода будет знать, что ((uint)(rx_buffer+5) & 3) == 0, то он использует LDRD или пару LDR. Если нет, но ((uint)(rx_buffer+5) & 1) == 0, то он может использовать LDRH,LDR,LDRH. Если на этапе сборки кода значение rx_buffer неизвестно, то будет использовать побайтный доступ.
IgorAVR2
Понял, спасибо!
IgorAVR2
Вычитал в в аналогичном топике, что оказывается STM32f4 об этом думать не нужно. Вот и у меня видимо до этого так раньше работало в других проектах.
https://electronix.ru/forum/lofiversion/ind...hp/t140216.html
jcxz
Цитата(IgorAVR2 @ Apr 10 2018, 17:02) *
Вычитал в в аналогичном топике, что оказывается STM32f4 об этом думать не нужно. Вот и у меня видимо до этого так раньше работало в других проектах.

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

PS: Да и учиться нужно не по "топикам" где могут нести какую угодно чушь, а по мануалам на ядро. Там всё разжёвано.
IgorAVR2
Да, всё правильно в моём случае сейчас переменная 64 бита и она для процессора тоже не родная.
Да, я в той теме всё ваши советы прочитал. А если учится только по мануалам, то можно учиться всю жизнь - некогда, работать надо!
Спасибо вам за помощь!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.