-
- Короче... Особо буйные могут успокоиться, хлебнуть галоперидольчику
и скинуть смирительную рубаху. Бага нет! "Нестандартный язык" от
ARM все предусмотрел еще в 4 версии. Просто для v5 похоже сменились
"умолчания" для ключа компилятора "--pointer_alignment=xxx". Ну или
можно описать структуру вот так: Гyдвин(3109 знак., 25.07.2020 20:08)
- Спасибо за раскопки. - VLLV(25.07.2020 21:13)
- Ну и еще один штрих: Запущал я это дело в MDK v5.25 legacy - без Software Packs. Для Cortex-M. > - Гyдвин(25.07.2020 21:12, ссылка)
- Для особо одарённых написано: Code size might increase
significantly when compiling for processors without hardware
support for unaligned access. Вместо того, чтоб исправить говнокод
в одном месте ты угандошил всю программу. Зато "работает". - fk0(25.07.2020 20:18)
- Ключевая фраза "without hardware support for unaligned access". У
меня точно не такой уже 10 лет. Я задал один вопрос - "как
лечить?". Нашел ответ. Ваши помои не пригодились. За сим и
откланиваюсь... - Гyдвин(25.07.2020 20:39)
- Если ты хочешь получать чёткие ответы на вопросы, то можешь обратиться в Keil Elektronik GmbH (теперь ARM Limited) и покупателю их продукции они ответят в лучшем виде (но продукты ты украл, так что могут и послать). А здесь тебе отвечать на твои вопросы никто не должен, более того, это вообще мало кому интересно. Ты вынес вопрос на публичное обсуждение -- для чего и существует форум, телеконференция, а не для решения твоих проблем. И ещё я бы тебе не советовал хамить мало fk0(52 знак., 25.07.2020 21:05)
- Ключевая фраза "without hardware support for unaligned access". У
меня точно не такой уже 10 лет. Я задал один вопрос - "как
лечить?". Нашел ответ. Ваши помои не пригодились. За сим и
откланиваюсь... - Гyдвин(25.07.2020 20:39)
- Заебись конЬструкция - Êîëè÷åñòâî êîìáàéíîâ äëÿ îäíîâðåìåííîé âûãðóçêè :)) - MBedder(25.07.2020 20:16)
- Непереводимая игра слов(с) при копировании из редактора Keil в
местный редактор ;) - Гyдвин(25.07.2020 20:41)
- General же бил себя пяткой в грудь - забудьте, мол, про кракозябры,
я их всех чохом заборол волшебным UTFом :)) - MBedder(25.07.2020 20:44)
- Тут проблема немного запутанней: В Keil v5 есть проблемы с русским языком (исходники, перенесенные из более старых версий). Типа по-умолчению utf8, если установить ANSI кодировку, то кракозябры в кириллице. Надо менять DLL, сам шрифт... И вот из этой мешанины оно и копируется "как всегда" :) - Гyдвин(25.07.2020 21:00)
- General же бил себя пяткой в грудь - забудьте, мол, про кракозябры,
я их всех чохом заборол волшебным UTFом :)) - MBedder(25.07.2020 20:44)
- Непереводимая игра слов(с) при копировании из редактора Keil в
местный редактор ;) - Гyдвин(25.07.2020 20:41)
- У вас на плате никаких передатчиков нету? С GSM модемом на борту и процем STM32L151 тоже на hard fault нарвались, и плата в 4 слоя была хорошо экранирована внутренними слоями, пока антенну на 90 градусов не развернул, hard fault не проходил. Программисты в шоке. - Visitor(25.07.2020 16:32)
- Короче, все печально. Поспрашивал коллегу, который занимается
частью проекта, в котором остались упакованные структуры. В IAR
точно также. Это не ошибка. Это сознательная диверсия. Некуда
ехать, приехали. - VLLV(24.07.2020 12:44)
- Сдается мне, что это связано с появлением более "жирных" кортексов.
Вот и натягивают сову на глобус... - Гyдвин(24.07.2020 13:00)
- Вариативный баг либы? На одних ядра работает, на других нет? А они
не рискуют получить подсвечником по хитрому рыжему... - Evgeny_CD(25.07.2020 02:16)
- Нет, просто говнокод. - fk0(25.07.2020 02:25)
- Вариативный баг либы? На одних ядра работает, на других нет? А они
не рискуют получить подсвечником по хитрому рыжему... - Evgeny_CD(25.07.2020 02:16)
- Повторенье мать ученья: - fk0(24.07.2020 12:49, ссылка)
- Сдается мне, что это связано с появлением более "жирных" кортексов.
Вот и натягивают сову на глобус... - Гyдвин(24.07.2020 13:00)
- Функция memcpy не должна требовать выравнивания. Не морочь мозги,
покажи исходник на C. - fk0(23.07.2020 17:20)
- Дык и я о том. Падает в библиотечной функции memcpy(). Ее в Keil
(ARMCC) нет в исходниках - бинарная либа. Видимо косяк... Для ARM7
и пр. есть волшебные заклинания в командной строке компилятора,
предназнаеченные для memcpy(). В моем случае ни хрена не поиогли. - Гyдвин(23.07.2020 17:37)
- Кстати попробуй через DECONST-макро адреса передать, чтоб тип стереть. Может компилятор из типа выводит, что он выравненный, и дальше пошло поехало. Оптимизация. fk0(46 знак., 23.07.2020 18:13)
- A с чего ты решил, что падает из-за невыравненности? Обработчик
hard fault написал, который тебе чётко причину и адрес
распечатывает? (а так делал). Может у тебя на входе косячные
адреса. - fk0(23.07.2020 18:11)
- Нормальные адреса (это первое глянул). Вот такой вот грязный хак
прекрасно работает: Гyдвин(156 знак., 23.07.2020 18:24)
- А такой работает? И второй вопрос - что происходит, если вместо
memcpy написать __aeabi_memcpy? йцyкeн(308 знак., 24.07.2020 12:46)
- __aeabi_memcpy((char*)&IH.conag,(void*)&buffer[32],(4+2+7)); прекрасно работает... - Гyдвин(24.07.2020 12:52)
- У тебя длина упакованной IH 16, причем последний элемент U32, а гребёшь ты 13. То, что с техникой могут быть чудеса - верю, но с логикой, КМК, что-то не то. - Vit(23.07.2020 20:56)
- Ты напиши какие адреса. И что с DECONST? Помогает? А тип какой -- я
тебе говорил, приведи исходник. Заколебали загадками с секретными
исходниками и секретными схемами. Стыдно -- тогда не спрашивай
вообще. - fk0(23.07.2020 18:38)
- Какие там нах секретные исходники? Все уже привел здесь... DECONST сработал - генерится правильный вызов, соответственно не вылетает: Гyдвин(363 знак., 23.07.2020 19:00)
- А такой работает? И второй вопрос - что происходит, если вместо
memcpy написать __aeabi_memcpy? йцyкeн(308 знак., 24.07.2020 12:46)
- Нормальные адреса (это первое глянул). Вот такой вот грязный хак
прекрасно работает: Гyдвин(156 знак., 23.07.2020 18:24)
- Дык и я о том. Падает в библиотечной функции memcpy(). Ее в Keil
(ARMCC) нет в исходниках - бинарная либа. Видимо косяк... Для ARM7
и пр. есть волшебные заклинания в командной строке компилятора,
предназнаеченные для memcpy(). В моем случае ни хрена не поиогли. - Гyдвин(23.07.2020 17:37)
- Хм... Дело обстоит еще интереснее - если прошагать отладчиком в
окне дизассемблера, эта __aeabi_memcpy4() отрабатывает без
hardfault. LPC1768 есличо... - Гyдвин(23.07.2020 16:03)
- IH.conag и buffer имеют тип char? - BlackMorda(23.07.2020 16:06)
- ВОТ!!! Гyдвин(1055 знак., 23.07.2020 19:10)
- Лично я не догоняю смысл одновременного использования #pragma
pack(1) и __align(4) применительно к struct {} Zoro(615 знак., 25.07.2020 16:19)
- Уже писал здесь: __align(4) просто воткнул в попытках вычислить откуда ноги растут... - Гyдвин(25.07.2020 16:26)
- ВОТ: SciFi(352 знак., 24.07.2020 10:28, ссылка)
- Приведение указателя к типу (uint8_t*) должно помочь? - VLLV(24.07.2020 10:42)
- По всем канонам должно (при #pragma pack(1)). Но пожоже компиляторостроители поимели другое видение в моем случае. - Гyдвин(24.07.2020 10:52)
- Это вряд ли. Да и написали бы, если бы так можно было. - SciFi(24.07.2020 10:47)
- Приведение указателя к типу (uint8_t*) должно помочь? - VLLV(24.07.2020 10:42)
- Aioeeeaaoiioaaie ieeooaaiieeo iaaiie! fk0(2534 знак., 23.07.2020 21:52, ссылка)
- в man memcpy написано что она принимает аргументы типа void* 3m(875 знак., 24.07.2020 08:41)
- А теперь представь, что "проверка адреса" выехала в compile time (чтоб как раз не тратить на неё время, о чём ты пишешь) и всё становится логично. Адреса в момент компиляции может и неизвестны, но их атрибуты (выравнивание) берутся из типов и известны. - fk0(24.07.2020 11:32)
- C " ВСЕГДА" не согласен (от того и пострадамши :) Выравниваю для
контроллеров, в которых это требуется - для того же MSP430. Для
ARM7TDMI тоже бы учел. Но тут, млять, Cortex M3, аффтары которого с
момента появления били себя пяткой в грудь, что поддерживается
побайтный доступ, и x86 c Паскалем на другом конце. И до каких то
пор это было без извратов - есть стандарт для memcpy() и приведения
указателей. В том же Keil v5, если использовать библиотеку
"microLIB", все пучком - Гyдвин(27 знак., 24.07.2020 09:01)
- Ещё раз -- ты работаешь не с контроллером "Cortex M3", а с некой
абстрактной моделью вычислительной машины заданной стандартом
языка. И в этой модели про невыравненный доступ сказано --
поведение неопределено. Более того, на твоём кортексе M3 оно тоже
вызывает улёт в hard fault. Поддержка побайтного доступа требует
совершенно других машинных команд (и работать всё будет в 4 раза
медленее). - fk0(24.07.2020 11:34)
- Вот и буду продолжать компилить версией 4.54 от 12 года, в которой хоть и "работать всё будет в 4 раза медленее", используя соответствующие команды, но без лишних выебонов в библиотеках. И более ранняя версия MDK ARM тоже работала корректно - правильная "абстрактная модель вычислительной машины заданная стандартом языка" (проект был запущен лет 10 назад)... - Гyдвин(24.07.2020 12:02)
- ВСЕГДА - потому что те же структуры могут переехать на другой
процессор например с M3 на M0. На M0 будет больно. - 3m(24.07.2020 10:34)
- Не переедут - зуб даю ;) В проекте 12..15 тыс. строк кода намертво
срощенного с периферией LPC17... - Гyдвин(24.07.2020 10:44)
- Звучит как профессиональные грабли.... - Evgeny_CD(24.07.2020 11:49)
- Нет, любительские... - fk0(24.07.2020 11:57)
- Звучит как профессиональные грабли.... - Evgeny_CD(24.07.2020 11:49)
- Не переедут - зуб даю ;) В проекте 12..15 тыс. строк кода намертво
срощенного с периферией LPC17... - Гyдвин(24.07.2020 10:44)
- Ещё раз -- ты работаешь не с контроллером "Cortex M3", а с некой
абстрактной моделью вычислительной машины заданной стандартом
языка. И в этой модели про невыравненный доступ сказано --
поведение неопределено. Более того, на твоём кортексе M3 оно тоже
вызывает улёт в hard fault. Поддержка побайтного доступа требует
совершенно других машинных команд (и работать всё будет в 4 раза
медленее). - fk0(24.07.2020 11:34)
- Это особенность ARM-архитектуры. При чтении/записи 32х-разрядного числа игнорируются младшие два бита адреса. Архитектура x86 без проблем может читать/писать по любому адресу. - Ale3000(24.07.2020 08:35)
- Все-таки остается одна неясность: il-2(361 знак., 24.07.2020 08:00 - 08:05)
- ИМХО, когда начинаются pragma pack и align, погромизд сам
расписался в том, что он будет во всём виноват, и стандарт не
помощник. - SciFi(24.07.2020 08:53)
- Align там не от балды - buffer[] используется для USB хоста - там
должен быть выровненный адрес для аппаратного DMA в LPC17. Align
для структуры - просто мои опыты в попытке разобраться где собака
порылась - в испытанном годами коде его нет. К pragma pack(1) тоже
нет претензий - он в моем коде для Cortex живет десяток лет и
делает свое дело - упаковывает структуру "без дырок". Для того и
добавлен в Keil. Но вот новый "шибко грамотный" компилятор, увидев
int32 в структуре и Гyдвин(243 знак., 24.07.2020 09:45)
- По какому стандарту? В ISO, ГОСТ и ANSI нет таких слов даже. - fk0(24.07.2020 11:36)
- Align там не от балды - buffer[] используется для USB хоста - там
должен быть выровненный адрес для аппаратного DMA в LPC17. Align
для структуры - просто мои опыты в попытке разобраться где собака
порылась - в испытанном годами коде его нет. К pragma pack(1) тоже
нет претензий - он в моем коде для Cortex живет десяток лет и
делает свое дело - упаковывает структуру "без дырок". Для того и
добавлен в Keil. Но вот новый "шибко грамотный" компилятор, увидев
int32 в структуре и Гyдвин(243 знак., 24.07.2020 09:45)
- Обычно функции, которая принимает в качестве параметра указатель void * (как в memcpy) можно передать указатель любого типа. Значит - (void *) гарантированно не выравненный. - il-2(24.07.2020 08:03)
- ИМХО, когда начинаются pragma pack и align, погромизд сам
расписался в том, что он будет во всём виноват, и стандарт не
помощник. - SciFi(24.07.2020 08:53)
- Речи правильные толкаешь :) Но компилятор, которому явно привели
тип указателя, но он "вызывает оптимизированную функцию которая
быстро копирует 32-битными словами" не имеет права на жизнь ;) - Гyдвин(23.07.2020 22:13)
- Почему "явное приведение типа указателя" считается каким-то
значимым аргументом? Всё равно перед вызовом memcpy эти указатели
неявно приведутся к void*. С тем же успехом можно в спортлото
написать. - SciFi(24.07.2020 09:57)
- Я тоже так считал и считаю :) Но из библиотеки вызывается другая
функция в memcpy() (см. первый пост), которую я совсем не просил.
Оттого и нежданчик... - Гyдвин(24.07.2020 10:09)
- А оптимизация как-то влияет? - VLLV(24.07.2020 11:57)
- нет. - Гyдвин(24.07.2020 12:03)
- А оптимизация как-то влияет? - VLLV(24.07.2020 11:57)
- Я тоже так считал и считаю :) Но из библиотеки вызывается другая
функция в memcpy() (см. первый пост), которую я совсем не просил.
Оттого и нежданчик... - Гyдвин(24.07.2020 10:09)
- gcc "чудный и замечательный" компилятор Zoro(183 знак., 24.07.2020 00:39)
- Проблема в том, что у тебя в программе _нет_ такого типа (U32, но
только "упакованный"). Если его руками создать, как в примере по
ссылке (внутри IY) -- то оно даже будет как надо работать.
Упакованные структуры это очень неполноценное и нестандартная
надстройка над C/C++. Не продуманная. Костыль. Её неспроста нет в
стандарте. Она "недоделанная" и не совсместима с моделью памяти и
системой типов C/C++. Стандартными (для C++, не для C) средствами
можно изголиться и сделать fk0(552 знак., 23.07.2020 22:28)
- Нет уж... Тысячи строк кода, драйверы, куски стороннего кода (та же
FatFs) и пр. как то не способствуют выворачиванию всего наизнанку.
А по этому топику: Cortex M3 (LPC17) имеет аппаратную побайтную
адресацию, посему фтопку компилер, взомнивший себя шибко
грамотным... Более ранняя версия работала "как в мудрых книгах
написано" - привели указатель к void* или char*, вызывается
предсказуемая библиотечная функция побайтного копирования (и все
остальные из string.h). И Гyдвин(118 знак., 23.07.2020 23:39)
- Говнокода. И не такие уж и тысячи. Практически всё что завелось не
на x86 такого говнокода не содержит. Потому, что и MIPS, и ARM --
это аппаратное исключение при невыравненном обращении и дальше либо
фиксация ошибки, либо программная эмуляция команды с невыравненным
чтением-записью (очень не быстро...) И даже на современном x86
словить исключение при невыравненном обращении -- запросто
(векторные инструкции). Ещё раз, повторю, упакованные структуры --
НЕ СТАНДАРТНАЯ ХЕРНЯ. fk0(3121 знак., 24.07.2020 01:19, ссылка)
- Все же тут похоже на глюк компилятора. PACKED это такой же
модификатор структуры как volatile или const которые должны
распространяться на все члены структуры. Соответственно, когда
делается &a.b на выходе должен получаться указатель с
соответствующим модификатором. А тут модификатор PACKED потерялся,
остальное последствия. Но я не большой знаток. - AlexBi(24.07.2020 09:53)
- А какой тип будут иметь по-твоему тогда члены структуры? Если в
структуры положить структуры и их тоже сделать packed -- получится.
А если в структуре уже лежит обычный int? Явно ж записано, что
такое-то поле -- int и с ним могут что-то делать и нельзя неявно
подменить тип -- работать перестанет (программист может начать
где-то сравнивать типы, например). Сама идея упакованных структур
-- не продуманная, в ней есть логические противоречия. - fk0(24.07.2020 11:46)
- В данном случае члены структуры должны становиться packed. А как,
по-твоему, работает (должно работать) volatile структура? Будут ее
члены каждый раз перечитываться? Указатель на члена структуры будет
volatile? AlexBi(405 знак., 24.07.2020 13:50)
- С чего ты решил, что они кому-то что-то должны? Где это написано? Тип поля, если это не вновь определяемая на месте структура, уже определён ранее и измениться никак не может (иначе это другой, новый тип должен быть). А выравнивание и размер -- это атрибуты, свойства, типа. Поэтому если ты в упакованную структуру положишь ранее определённый тип, то он сохранит свои свойства. Структура останется с "дырками" для выравнивания, обычный int сохранится с alignas(4). Что мы и fk0(263 знак., 24.07.2020 14:34, ссылка)
- В данном случае члены структуры должны становиться packed. А как,
по-твоему, работает (должно работать) volatile структура? Будут ее
члены каждый раз перечитываться? Указатель на члена структуры будет
volatile? AlexBi(405 знак., 24.07.2020 13:50)
- В студии не хватает кода. Там запросто может быть два определения
структуры -- с packed и без. - SciFi(24.07.2020 09:59)
- Вот суть: Гyдвин(1541 знак., 24.07.2020 10:24)
- А если собрать демо пример чисто в одном файле ? Zoro(333 знак., 25.07.2020 16:42)
- Интересно, а как работает банальное чтение невыравненного U32 из структуры? - VLLV(24.07.2020 12:02)
- Косяк -- это твой говнокод. Даже комментарии на русском языке не
осилил. А поведение результат работы оптимизатора, который считает,
что тип int (U32 -- самодельные типы -- 100% говнокод) никак не
может лежать по невыравненному адресу. Ты можешь в структуру
положить другие packed структуры и тогда оно заработает нормально. - fk0(24.07.2020 11:50)
- Комментарии - твои проблемы, да и не важны они в этой теме. До v5
оптимизатор ARMCC считал, что все пучком касаемо Cortex M3 - все
может лежать там, куда положили. И делал то, что указали конкретно.
"Самодельные типы" "придуманы" не мной, а самим Keil. Так шта без
эмоций... Гyдвин(1329 знак., 24.07.2020 12:21)
- Пиши дальше на нестандартных языках и собирай нестандартные
грабли... - fk0(24.07.2020 12:27)
- Кхе-кхе... Кто-то говорил, что граблей нет. - VLLV(24.07.2020 12:47)
- Нормальный, кросс-платформенный код, написанный на стандартизированном подмножестве языка, таких проблем не имеет и работает на любой платформе сразу. - fk0(24.07.2020 12:53)
- Дык и спитч был как раз о "нестандартном" языке от ARM и его
библиотеках (RTL, например), о куче написанного кода, прекрасно
работавшего с ранними компиляторами, о конкретном чипе Cortex M3 -
LPC17 ;) А свою напыщенность можешь затолкать себе в жопу вместе с
апплобом. Меня - ЛЮБИТЕЛЯ оно нисколько не колышет :) - Гyдвин(24.07.2020 12:40)
- Спиши код у SciFi: - fk0(24.07.2020 12:51, ссылка)
- Кхе-кхе... Кто-то говорил, что граблей нет. - VLLV(24.07.2020 12:47)
- Пиши дальше на нестандартных языках и собирай нестандартные
грабли... - fk0(24.07.2020 12:27)
- нет "самодельных типов", они все восходят к оригинальным. uint32_t
ничем не отличается от U32 - VLLV(24.07.2020 12:00)
- Вот я смотрю на твой код и как я пойму, что U32 это unsigned int на ARM? А что я буду делать на 16-битной машине (где U32 будет излишне неэффективен). Смысл использования стандартных типов и функций в том, что не надо каждый раз гадать -- а это это такое (может у тебя там написано, мол typedef unsigned short U32), текст читается любым программистом. А вот зачем придумывать нестандартные "алиасы" к стандартным типам и функциям, чтоб человек со стороны прочитать не мог? - fk0(24.07.2020 12:11)
- Комментарии - твои проблемы, да и не важны они в этой теме. До v5
оптимизатор ARMCC считал, что все пучком касаемо Cortex M3 - все
может лежать там, куда положили. И делал то, что указали конкретно.
"Самодельные типы" "придуманы" не мной, а самим Keil. Так шта без
эмоций... Гyдвин(1329 знак., 24.07.2020 12:21)
- Вот суть: Гyдвин(1541 знак., 24.07.2020 10:24)
- А какой тип будут иметь по-твоему тогда члены структуры? Если в
структуры положить структуры и их тоже сделать packed -- получится.
А если в структуре уже лежит обычный int? Явно ж записано, что
такое-то поле -- int и с ним могут что-то делать и нельзя неявно
подменить тип -- работать перестанет (программист может начать
где-то сравнивать типы, например). Сама идея упакованных структур
-- не продуманная, в ней есть логические противоречия. - fk0(24.07.2020 11:46)
- Все же тут похоже на глюк компилятора. PACKED это такой же
модификатор структуры как volatile или const которые должны
распространяться на все члены структуры. Соответственно, когда
делается &a.b на выходе должен получаться указатель с
соответствующим модификатором. А тут модификатор PACKED потерялся,
остальное последствия. Но я не большой знаток. - AlexBi(24.07.2020 09:53)
- Говнокода. И не такие уж и тысячи. Практически всё что завелось не
на x86 такого говнокода не содержит. Потому, что и MIPS, и ARM --
это аппаратное исключение при невыравненном обращении и дальше либо
фиксация ошибки, либо программная эмуляция команды с невыравненным
чтением-записью (очень не быстро...) И даже на современном x86
словить исключение при невыравненном обращении -- запросто
(векторные инструкции). Ещё раз, повторю, упакованные структуры --
НЕ СТАНДАРТНАЯ ХЕРНЯ. fk0(3121 знак., 24.07.2020 01:19, ссылка)
- Нет уж... Тысячи строк кода, драйверы, куски стороннего кода (та же
FatFs) и пр. как то не способствуют выворачиванию всего наизнанку.
А по этому топику: Cortex M3 (LPC17) имеет аппаратную побайтную
адресацию, посему фтопку компилер, взомнивший себя шибко
грамотным... Более ранняя версия работала "как в мудрых книгах
написано" - привели указатель к void* или char*, вызывается
предсказуемая библиотечная функция побайтного копирования (и все
остальные из string.h). И Гyдвин(118 знак., 23.07.2020 23:39)
- Почему "явное приведение типа указателя" считается каким-то
значимым аргументом? Всё равно перед вызовом memcpy эти указатели
неявно приведутся к void*. С тем же успехом можно в спортлото
написать. - SciFi(24.07.2020 09:57)
- тут знаю одно - атрибуты packed и volatile при пропускании через формальные параметры функции завсегда теряются, но по ходу успевают цепляться яйцами:) Vit(147 знак., 23.07.2020 22:12)
- Да и ты сделал #pragma pack, но нихера не вернул обратно (через pragma push/pop -- смотри у меня пример по ссылке). В итоге у тебя вся программа "упакованная" и глючная. Хуже того, в зависимости от порядка включения хедеров одни и те же структуры в разных модулях могли оказаться упакованные или нет. Кровь, кешки, фарш! - fk0(23.07.2020 21:55)
- в man memcpy написано что она принимает аргументы типа void* 3m(875 знак., 24.07.2020 08:41)
- Лично я не догоняю смысл одновременного использования #pragma
pack(1) и __align(4) применительно к struct {} Zoro(615 знак., 25.07.2020 16:19)
- Нужно весь тип структуры смотреть - пакед, не пакед, что впереди,
размерность. - VLLV(23.07.2020 16:29)
- Да вроде как memcpy() обязана побайтно копировать, имея на входе 2
указателя... Кстати, вместо (void *) пробовал (char *). Тут дело в
чем то другом - если эту __aeabi_memcpy4() пройти пошагово в
отладчике, все пучком - не вылетает... чЮдеса... - Гyдвин(23.07.2020 16:37)
- 1. Вроде как зависит от реализации, а в реализации могут быть косяки. 2. При пошаговом выполнении в прерывания не заходит. - VLLV(23.07.2020 16:47)
- замечал много раз в отладчике по шагам даже явные косяки и не попадаешь в hardfault ! а в работе залетает - Aleksey_75(23.07.2020 16:41)
- Да вроде как memcpy() обязана побайтно копировать, имея на входе 2
указателя... Кстати, вместо (void *) пробовал (char *). Тут дело в
чем то другом - если эту __aeabi_memcpy4() пройти пошагово в
отладчике, все пучком - не вылетает... чЮдеса... - Гyдвин(23.07.2020 16:37)
- ВОТ!!! Гyдвин(1055 знак., 23.07.2020 19:10)
- IH.conag и buffer имеют тип char? - BlackMorda(23.07.2020 16:06)
- Короче... Особо буйные могут успокоиться, хлебнуть галоперидольчику
и скинуть смирительную рубаху. Бага нет! "Нестандартный язык" от
ARM все предусмотрел еще в 4 версии. Просто для v5 похоже сменились
"умолчания" для ключа компилятора "--pointer_alignment=xxx". Ну или
можно описать структуру вот так: Гyдвин(3109 знак., 25.07.2020 20:08)