Перейти к содержанию
    

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

возможно ли каким-то образом заставить AVR-GCC сделать указатель, в котором будет не 16 бит, а больше - 24 или 32?

подмена типа меня не устраивает, т.к. хочется, чтобы компилятор верно вычислял смещения адресов полей в структурах:

pgm_read_byte_far(ptr->field5) - как обявить ptr, если допустим, он должен быть равен 0x10027?!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

возможно ли каким-то образом заставить AVR-GCC сделать указатель, в котором будет не 16 бит, а больше - 24 или 32?

 

В настоящее время нельзя.

 

Анатолий.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Есть такой макрос для взятия адреса, может быть Вам будет чем-то полезен.

/* GET_FAR_ADDRESS() macro
*
*   This macro facilitates the obtention of a 32 bit "far" pointer (only 24 bits
*   used) to data even passed the 64KB limit for the 16 bit ordinary pointer. It
*   is similar to the '&' operator, with some limitations.
*
*   Comments:
*
*   - The overhead is minimal and it's mainly due to the 32 bit size operation.
*
*   - 24 bit sizes guarantees the code compatibility for use in future devices.
*
*   - hh8() is an undocumented feature but seems to give the third significant byte
*     of a 32 bit data and accepts symbols, complementing the functionality of hi8()
*     and lo8(). There is not an equivalent assembler function to get the high
*     significant byte.
*
*   - 'var' has to be resolved at linking time as an existing symbol, i.e, a simple
*     type variable name, an array name (not an indexed element of the array, if the
*     index is a constant the compiler does not complain but fails to get the address
*     if optimization is enabled), a struct name or a struct field name, a function
*     identifier, a linker defined identifier,...
*
*   - The natural place for this macro should be the header avr/pgmspace.h and the
*     name... pgm_get_far_address?
*
*   - The returned value is the identifier's VMA (virtual memory address) determined
*     by the linker and falls in the corresponding memory region. The AVR Harvard
*     architecture requires non overlapping VMA areas for the multiple address spaces
*     in the processor: Flash ROM, RAM, and EEPROM. Typical offset for this are
*     0x00000000, 0x00800xx0, and 0x00810000 respectively, derived from the linker
*     script used and linker options. The value returned can be seen then as a
*     universal pointer.
*
*/


#ifndef _FAR_ADDRESS_H_
#define _FAR_ADDRESS_H_

#define GET_FAR_ADDRESS(var)                          \
({                                                    \
   uint_farptr_t tmp;                                \
                                                     \
   __asm__ __volatile__(                             \
                                                     \
           "ldi    %A0, lo8(%1)"           "\n\t"    \
           "ldi    %B0, hi8(%1)"           "\n\t"    \
           "ldi    %C0, hh8(%1)"           "\n\t"    \
           "clr    %D0"                    "\n\t"    \
       :                                             \
           "=d" (tmp)                                \
       :                                             \
           "p"  (&(var))                             \
   );                                                \
   tmp;                                              \
})

#endif

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

все эти макросы и т.п. мне известны, но это совсем не то. что я хочу. я хочу писать программу, как пишут нормальные люди - пример выше я приводил. и чтобы эту программу компилятор правильно обрабатывал, т.е. умел инкрементировать указатели в области адресов за 64К. уже сказали мне, что это невозможно... увы :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

все эти макросы и т.п. мне известны, но это совсем не то. что я хочу. я хочу писать программу, как пишут нормальные люди...

Субботний оффтоп:

Разделяю. Жаль, в некоторые микроконтроллеры недокладывают бит разрядности. Хорошо что появились микроконтроллеры, в которых разрядность адресов из коробки 32 бита и практически все виды памяти находятся в одном адресном пространстве - вот это для людей =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Единственное, что остаётся - стараться всё такое разместить в нижних 64К.
Так это и так происходит по умолчаню, ИМХО.

Пока данные+вектрора+стартап+трамплины не превысили 64К всё должно быть пучком:-)

 

to ARV:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Имелось ввиду "всё такое (где структуры/поля) оставить в нижних, а строки и, возможно, тупые таблицы, пресонально разместить в верхних, раз уж всё вместе внизу не помещается"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так это и так происходит по умолчаню, ИМХО.

Пока данные+вектрора+стартап+трамплины не превысили 64К всё должно быть пучком:-)

 

to ARV:

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

строки и, возможно, тупые таблицы, пресонально разместить в верхних, раз уж всё вместе внизу не помещается"
Прекрасный вариант.

Я склоняюсь к мысли, что в контексте AVR проблема с ограничением в 64К слов - надуманная.

И если совсем нет никакого желания соскочить с AVR, то выкрутится всегда можно.

Тут уж, как говорится, любишь кататься - люби и катайся! :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В IAR решили эту проблему, там указатели для мег с >128к памятью 3-х байтовые.

Программист эту проблему не ощущает. Но только когда пытается указатели на ОЗУ к указателям на флэш кастовать :biggrin:

 

А в avr-gcc вроде есть какая-то секция, что-то вроде trampoline, куда могут вести указатели на функции, расположенные в верхней половине 256кб, в этой секции находится таблица, а уже в этой таблице находятся реальные адреса функций...

И спомощью линкера, что-то подобное можно организовать. И это должно как-то помочь с двубайтовым ограничением на указатель.

Сам никогда не пробовал, но помойму на avr фриках что-то читал об этом. Разве не должно помочь?

 

Хотелось бы в иделае, всё адресное пространство флэши использовать под код, а то для больших мег применение gcc не имеет смысла.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В IAR решили эту проблему, там указатели для мег с >128к памятью 3-х байтовые.
наверное все-таки >64К

Программист эту проблему не ощущает. Но только когда пытается указатели на ОЗУ к указателям на флэш кастовать :biggrin:

 

Хотелось бы в иделае, всё адресное пространство флэши использовать под код, а то для больших мег применение gcc не имеет смысла.
с кодом-то как раз проблем нет, проблема начинается, когда приспичит бОльшую часть флеши под данные использовать...

 

P.S. Вот вчера сделал проектик, в котором в atmega2560 хранятся 20 штук 2,2 килобайтных кусочка разных массивов. вышло в аккурат 48 килобайт вместе с кодом. теперь думаю - явно заказчик захочет не 20, а 40 или еще больше блоков данных впихнуть (аппетит, он, же такой...) - и что тогда? отказаться от красивых Сишных записей и вместо работы с указателями работать с long-адресами? впору думать о каком-то особом классе С++...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

наверное все-таки >64К

Нет.. Имено >128к, ибо измеряю память в байтах :biggrin: Килопопугаи не устраивают, так как меняются от архитектуры к архитектуре.

 

Программист эту проблему не ощущает. Но только когда пытается указатели на ОЗУ к указателям на флэш кастовать biggrin.gif

Соблюдайте copyright. :maniac:

 

И именно с кодом беда, особенно когда активно используешь указатели на функции. В итоге при попытке вызвать функцию по указателю, расположенную в верхних 128килобайт, программа улетает чёрт знает куда.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

наверное все-таки >64К
64К слов = 128КБ (flash имеет по словную адресацию)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В IAR AVR для указателей на дальние области были квалификаторы far (24 бита) и huge (32 бита). Нет ли чего подобного в GCC?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...