Немного торможу.
Ф-я принимает адрес массива.
Надо передать адрес.



это я изначально указатель разыменовываю и работаю со значением по полю структуры.
А как адрес передать этой p.data? А если еще и смещение надо передать +16, например?

?

Вот так:



Адрес привести к нужному типу данных и обратиться к этому адресу через новый указатель (uint16_t - тут для примера):

или так (если работаете на C++ и ваш компилятор это поддерживает):


Понимаю, это - редкостная дичь :D
Как избежать? Да, сразу правильно строить нужные структуры данных (в т.ч. вложенные), пользуясь struct и union, минимально используя указатели.

Тоже так хотел, но уже сомневаться начал, т.к. ругается компилер.

Вот вызываю ф-ю и передаю параметры:



А сама ф-я принимающая:


Т.е. должен просто принять указатель на массив.

Кстати, правильно, что ругается, т.к. p_req->write.p_data- это уже и есть указатель и указатель на указатель- глупо.

Все правильно ругается компилятор - вы пытаетесь ему сунуть адрес указателя (указатель на указатель), а нужно дать лишь сам указатель.
Причем его стоит привести к такому типу, который ожидает получить ваша функция. Ведь вы не указали тут содержимое структуры "write", поэтому, как обычно - играем в экстрасенсов
Вот так сделайте:



Такие ошибки легко искать разбивая операции на промежуточные путем создания временных переменных.
Так хотя бы можно разобраться на каком этапе преобразований возникает ошибка.

Это структура write. Она структура в структуре

Если "const" действительно закомментирован, то тогда должно работать даже так:

const- это я и закомментил.
Не работает. Ругается уже на линковщике.
Может я не так смещение делаю?

Задача в ф-ю шифрования по 16 байт подавать.



Ругань что не хватает места (125 ошибок)

Вы по ходу путаете компилятор и линковщик. Приведенные выше были ошибки компилятора.
А ошибки линковщика - это уже совсем другая история...


Что-то мне подсказывает, что передавать в одну и ту же функцию в качестве указателя источника и получателя данных одну и ту же область - это очень подозрительно и может привести к этому:
Особенно, если вы понятия не имеете, как работает внутри эта самая функция.

Из прошлого сообщения была ругань компилятора. Сейчас ругается так:


Линковщик?

Дело в том, что на прошлом SDK я такой финт проделывал(с передачей в ф-ю эту источника и выходного массива, куда писать данные одного массива)- все работало. Т.е. ф-я работоспособна в таком виде.

Да, линковщик. Об этом явно говорит буковка "L" перед кодом ошибки.
Кстати, этот код ошибки можно вбить в строку поиска гугля и там найти подробности
В данном случае у выбранного контроллера тупо не хватает места под данные или код.


Профи найдет источник проблемы, комментируя целые куски кода, пытаясь локализовать виновника.
Дилетант будет ссылаться на то, что "ведь раньше все работало"...

Не будьте дилетантом, ищите. Ведь кроме вас никто в вашем коде не разберется

По ходу банально места уже нет, не может линковщик огромный кусок кода впихнуть в маленькую память контроллера

Да понятно) Спасибо за помощь. Отпишусь тут - что получилось в результате.



По мне, так странно. Я же не прошу его впихивать весь блок. Я прошу его по 16 байт заменить один кусок кода другим.

я про то, что компилятор накомпилил такой объём кода, что линковщик хватается за голову и говорит, что в секции ANY, в выделенном ей пространстве, не хватает места, чтобы этот код туда запихать

И как выйти из положения можно? Увеличить чего-нибудь? Или просто сам код написан так, что рекурсия получилось и вызывается как матрешка друг за другом?

Или вы ожидаете, что за Вас тут будут делать Вашу работу?

Да причём тут рекурсия? У контроллера банально исчерпалось место во флеш-памяти
Оптимизировать код, изменить уровень оптимизации кода, менять контроллер на более "жирный"

Вы были правы. Достаточно было увеличить память под прошивку, чтобы впихнуть новый файл aes.c и проблема линковщика ушла.
Все заработало.
Всем спасибо за консультации.

Просто поменяли цифры в настройках проекта или все-таки еще и заменили чип на более емкий?

я так понимаю, что изначально неверно были выставлены размеры памяти устройства в проекте. Ибо как же можно впихнуть в реальный камень то, что в него не влезет физически?

Скорее - изначально был выбран неправильный камень.

очень просто - ничего не прошивать в него, т.к. речь шла лишь про сборку проекта

у чипа nRF52 512 флеша. Камень, соответственно, тот же остался. Но проект бутлоадера (его пилю) был ограничен стартом адреса и размером. Его и увеличил. Я вклячил файл aes.c туда и он банально не влазил в отведенную область.
Просто не сталкивался с таким, поэтому потерялся. Сейчас все работает. Всем еще раз спасибо.

Судя по названию фукнции у вас Tiny AES128. Его не сложно ужать в размерах, свернув развернутый цикл по блокам, за примерно 3% падение производительности.

Кстати, здесь Zltigo выкладывал AES128 под 32-разрядные процессоры. У меня вышло ужать это всё в ~4КБ + 256 байт оперативки. Итого бут с сериалом получался вполне себе в две страницы в 8КБ (всего)

А смысл так много?. У меня аеs+ecdsa+ecdh упихнуты в 2.5. Причем по замерам на армах все эти высокоуровневые раскрутки циклов дают считанные %.

Прошу прощения, я вас обманул, попутал по памяти с гостовым вариантом.

Не покажете?

У меня AES decrypt занимает килобайт. (+ таблички в ОЗУ). Полный вариант (encrypt + decrypt) - полтора. Таблички поместить во флеш - ещё пол-кило (но у загрузчика ОЗУ и так с избытком).

Код чужой, с минимальными допиливаниями.

https://github.com/kokke/tiny-AES-c
https://github.com/kmackay/micro-ecc

Естественно в EC скомпилирована версия со статическим связыванием только с одной кривой. Режим блочного шифрования - сделан руками, а не в библиотеке, ну он может добавляет еще сотню байт. У меня тоже только расшифровывание. Ключи компиляции - ничего необычного, на оптимизацию следующее: -flto -Os -mcpu=cortex-m0 -mthumb

0xA50 или 2640 байт кода