Здравствуйте.

Есть библиотека, которая использует структуру с настройками TableSets и массу функций возвращающих адрес на строки таким образом:
char *addr=TableSets.XXX.yyy;
return addr;

Задача: перенести TableSets во внешнюю FLASH-память не переписывая библиотеку (поэтому offsetof использовать не получится).
Для обращения к внешней памяти надо знать смещение элемента в структуре относительно нулевого адреса.

Т.е. надо как-то определить структуру TableSets по нулевому адресу и в тоже время не размещать ее в ОЗУ МК.
Подскажите, пожалуйста, возможно ли это как-то сделать?
Спасибо.

з.ы. ОЗУ МК также начинается с нулевого адреса.

Как то так?

Именно это и делает offsetof(). Чем именно она не подходит?

Можно убрать из нее приведение типа:


А вообще более правильно это делать как eeprom в avr-gcc организована - выделен регион где-то далеко в несуществующих адресах, в него засунута секция, в эту секцию размещаете свои данные, а в самой программе старшие несуществующие биты адреса просто выпадают за разрядную сетку указателя.

Это можно легко сделать используя возможности МК с интерфейсом SPIFI. Например LPC17xx или LPC43xx.

не надо

desh, не подошло, в библиотеке часто юзают передачу адреса из настроек в функции Func(&TableSets.XXX.yyy)

offset использует запись TableSets->XXX;, а в библиотеке используется TableSets.XXX;...

jcxz, почему не надо, как тогда прочитать одно значение, а не всю структуру?

------------------------------
Добавлено:
Похоже нашел как реализовать задуманное, не особо красиво, но все же:
Определяю структуру настроек по адресу обозначенной в Memory map МК как Reserved: __no_init TABLE_SETS_STRUCT TableSets @ 0x1100;
А смещение буду вычислять путем вычитания из переданного библиотекой адреса данное значение 0x1100.

"Не надо" касалось совета про SPIFI - в том случае больше делать ничего не надо.
А насчёт остального - тут уже 1000 раз говорилось: Хотите получить ответ, постарайтесь внятно изложить задачу, так чтобы не только Вам было ясно, но и читающим, тем кто не видит Ваших исходников.
Что следует из этой фразы "перенести TableSets во внешнюю FLASH-память не переписывая библиотеку"? Абсолютно ничего не ясно о чём вообще вопрос...
По последнему Вашему сообщению и применив телепатические способности можно предположить, что у Вас имеется некий набор ПО, который изнутри себя вызывает функционал чтения FLASH через API-вызовы типа ReadFlash(void *dst, void const *src, uint len). И это API изначально читало данные из внутренней флешь, находящейся в адресном пространстве МК, а теперь Вы хотите, не меняя кода всего ПО, использующего эти API-вызовы, поменять только службу этого API, заменив чтение из внутренней флешь, на чтение внешней.
Так или не так?
Если так, то да - вариант решения о котором Вы написали в последнем посте - это одно из решений задачи.
Чтобы предложить другие решения, читающим нужно знать: как именно существующее ПО вызывает API-функции? Опять -же - здесь телепатов нет - Ваш код видите только Вы.
Если то ПО написано корректно, то думаю оптимальнее будет использовать другой способ, как тут уже советовали - через offsetof().
Да хотя-бы просто переопределив API-функции макросами.

Как-то очень с трудом и отдаленно я кажется понял, чего хочет автор вопроса - его библиотека возвращает указатели на поля прибитой гвоздями к внутренней памяти струкутры. Он хочет обмануть библиотеку и использовать эти указатели как адреса для доступа к внешней памяти.
Alt.F4: Определите в скрипте линкера или в его командной строке символ TableSets равный нулю, а в программе напишите extern struct_type TableSets;

jcxz, Сергей Борщ, мы можем понимать друг друга без слов!
Глубоко извиняюсь, что не смог в первом посте правильно описать задачу...

jcxz, грубо говоря, как Вы и написали, ПО читает настройки через вызов ReadSet08(dst, &TableSets.XXX.yyy) и именно из-за такой передачи адреса я не могу заюзать offsetof()...

Сергей Борщ, круто, то что надо!!! Спасибо!