AVR-GCC: указатель для адресного пространства более 64К, как?!?! Опции

[ARV]

возможно ли каким-то образом заставить AVR-GCC сделать указатель, в котором будет не 16 бит, а больше - 24 или 32?
подмена типа меня не устраивает, т.к. хочется, чтобы компилятор верно вычислял смещения адресов полей в структурах:
pgm_read_byte_far(ptr->field5) - как обявить ptr, если допустим, он должен быть равен 0x10027?!

[ReAl]

Единственное, что остаётся - стараться всё такое разместить в нижних 64К. Расчистить место можно, заталкивая строки в секцию, которая линковаться будет после кода и со строками работать через этот самый макрос и *_PF-функции. Тоже невесело, но зато для структур полегче будет.

[demiurg_spb]

Единственное, что остаётся - стараться всё такое разместить в нижних 64К.

Так это и так происходит по умолчаню, ИМХО.
Пока данные+вектрора+стартап+трамплины не превысили 64К всё должно быть пучком:-)

to ARV:
что это у Вас за проект такой где это условие не выполняется?

[ARV]

Так это и так происходит по умолчаню, ИМХО.
Пока данные+вектрора+стартап+трамплины не превысили 64К всё должно быть пучком:-)

to ARV:
что это у Вас за проект такой где это условие не выполняется?

честно говоря, пока я смутно представляю, чем можно занять 256 килобайт FALSH в atmega2560, кроме как какими-то данными. предположим, я там собрался хранить картинки для вывода на дисплей. да, пока картинок 2 или 3 компилятор всунет их в верхние адреса и никаких проблем нет. но когда картинок станет 100 или каждая картинка будет по 10К - тогда как прикажете поступать? кроме картинок, который в сути своей чаще есть просто линейный массив, есть еще данные, структура которых подразумевает относительную адресацию - тот же MIDI или S3M (MOD) файл.

иронию на счет ограниченности и "есть контроллры" понял, ликую всесте с вами.