Jump to content

    
Sign in to follow this  
ARV

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

Recommended Posts

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

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

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

Share this post


Link to post
Share on other sites
возможно ли каким-то образом заставить AVR-GCC сделать указатель, в котором будет не 16 бит, а больше - 24 или 32?

 

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

 

Анатолий.

Share this post


Link to post
Share on other sites

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

/* 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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
все эти макросы и т.п. мне известны, но это совсем не то. что я хочу. я хочу писать программу, как пишут нормальные люди...

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

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

Share this post


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

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

 

to ARV:

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Так это и так происходит по умолчаню, ИМХО.

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

 

to ARV:

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

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

 

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

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

 

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

Share this post


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

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
наверное все-таки >64К

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this