ARV 0 22 октября, 2010 Опубликовано 22 октября, 2010 · Жалоба возможно ли каким-то образом заставить AVR-GCC сделать указатель, в котором будет не 16 бит, а больше - 24 или 32? подмена типа меня не устраивает, т.к. хочется, чтобы компилятор верно вычислял смещения адресов полей в структурах: pgm_read_byte_far(ptr->field5) - как обявить ptr, если допустим, он должен быть равен 0x10027?! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aesok 0 22 октября, 2010 Опубликовано 22 октября, 2010 · Жалоба возможно ли каким-то образом заставить AVR-GCC сделать указатель, в котором будет не 16 бит, а больше - 24 или 32? В настоящее время нельзя. Анатолий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 23 октября, 2010 Опубликовано 23 октября, 2010 · Жалоба Есть такой макрос для взятия адреса, может быть Вам будет чем-то полезен. /* 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 23 октября, 2010 Опубликовано 23 октября, 2010 · Жалоба все эти макросы и т.п. мне известны, но это совсем не то. что я хочу. я хочу писать программу, как пишут нормальные люди - пример выше я приводил. и чтобы эту программу компилятор правильно обрабатывал, т.е. умел инкрементировать указатели в области адресов за 64К. уже сказали мне, что это невозможно... увы :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 23 октября, 2010 Опубликовано 23 октября, 2010 · Жалоба Единственное, что остаётся - стараться всё такое разместить в нижних 64К. Расчистить место можно, заталкивая строки в секцию, которая линковаться будет после кода и со строками работать через этот самый макрос и *_PF-функции. Тоже невесело, но зато для структур полегче будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 октября, 2010 Опубликовано 23 октября, 2010 · Жалоба все эти макросы и т.п. мне известны, но это совсем не то. что я хочу. я хочу писать программу, как пишут нормальные люди... Субботний оффтоп: Разделяю. Жаль, в некоторые микроконтроллеры недокладывают бит разрядности. Хорошо что появились микроконтроллеры, в которых разрядность адресов из коробки 32 бита и практически все виды памяти находятся в одном адресном пространстве - вот это для людей =) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 24 октября, 2010 Опубликовано 24 октября, 2010 · Жалоба Единственное, что остаётся - стараться всё такое разместить в нижних 64К.Так это и так происходит по умолчаню, ИМХО. Пока данные+вектрора+стартап+трамплины не превысили 64К всё должно быть пучком:-) to ARV: что это у Вас за проект такой где это условие не выполняется? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 24 октября, 2010 Опубликовано 24 октября, 2010 · Жалоба Имелось ввиду "всё такое (где структуры/поля) оставить в нижних, а строки и, возможно, тупые таблицы, пресонально разместить в верхних, раз уж всё вместе внизу не помещается" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 24 октября, 2010 Опубликовано 24 октября, 2010 · Жалоба Так это и так происходит по умолчаню, ИМХО. Пока данные+вектрора+стартап+трамплины не превысили 64К всё должно быть пучком:-) to ARV: что это у Вас за проект такой где это условие не выполняется? честно говоря, пока я смутно представляю, чем можно занять 256 килобайт FALSH в atmega2560, кроме как какими-то данными. предположим, я там собрался хранить картинки для вывода на дисплей. да, пока картинок 2 или 3 компилятор всунет их в верхние адреса и никаких проблем нет. но когда картинок станет 100 или каждая картинка будет по 10К - тогда как прикажете поступать? кроме картинок, который в сути своей чаще есть просто линейный массив, есть еще данные, структура которых подразумевает относительную адресацию - тот же MIDI или S3M (MOD) файл. иронию на счет ограниченности и "есть контроллры" понял, ликую всесте с вами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 25 октября, 2010 Опубликовано 25 октября, 2010 · Жалоба строки и, возможно, тупые таблицы, пресонально разместить в верхних, раз уж всё вместе внизу не помещается"Прекрасный вариант. Я склоняюсь к мысли, что в контексте AVR проблема с ограничением в 64К слов - надуманная. И если совсем нет никакого желания соскочить с AVR, то выкрутится всегда можно. Тут уж, как говорится, любишь кататься - люби и катайся! :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xelax 0 25 октября, 2010 Опубликовано 25 октября, 2010 · Жалоба В IAR решили эту проблему, там указатели для мег с >128к памятью 3-х байтовые. Программист эту проблему не ощущает. Но только когда пытается указатели на ОЗУ к указателям на флэш кастовать А в avr-gcc вроде есть какая-то секция, что-то вроде trampoline, куда могут вести указатели на функции, расположенные в верхней половине 256кб, в этой секции находится таблица, а уже в этой таблице находятся реальные адреса функций... И спомощью линкера, что-то подобное можно организовать. И это должно как-то помочь с двубайтовым ограничением на указатель. Сам никогда не пробовал, но помойму на avr фриках что-то читал об этом. Разве не должно помочь? Хотелось бы в иделае, всё адресное пространство флэши использовать под код, а то для больших мег применение gcc не имеет смысла. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 26 октября, 2010 Опубликовано 26 октября, 2010 · Жалоба В IAR решили эту проблему, там указатели для мег с >128к памятью 3-х байтовые.наверное все-таки >64К Программист эту проблему не ощущает. Но только когда пытается указатели на ОЗУ к указателям на флэш кастовать Хотелось бы в иделае, всё адресное пространство флэши использовать под код, а то для больших мег применение gcc не имеет смысла.с кодом-то как раз проблем нет, проблема начинается, когда приспичит бОльшую часть флеши под данные использовать... P.S. Вот вчера сделал проектик, в котором в atmega2560 хранятся 20 штук 2,2 килобайтных кусочка разных массивов. вышло в аккурат 48 килобайт вместе с кодом. теперь думаю - явно заказчик захочет не 20, а 40 или еще больше блоков данных впихнуть (аппетит, он, же такой...) - и что тогда? отказаться от красивых Сишных записей и вместо работы с указателями работать с long-адресами? впору думать о каком-то особом классе С++... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xelax 0 26 октября, 2010 Опубликовано 26 октября, 2010 · Жалоба наверное все-таки >64К Нет.. Имено >128к, ибо измеряю память в байтах Килопопугаи не устраивают, так как меняются от архитектуры к архитектуре. Программист эту проблему не ощущает. Но только когда пытается указатели на ОЗУ к указателям на флэш кастовать biggrin.gif Соблюдайте copyright. :maniac: И именно с кодом беда, особенно когда активно используешь указатели на функции. В итоге при попытке вызвать функцию по указателю, расположенную в верхних 128килобайт, программа улетает чёрт знает куда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 26 октября, 2010 Опубликовано 26 октября, 2010 · Жалоба наверное все-таки >64К64К слов = 128КБ (flash имеет по словную адресацию) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 26 октября, 2010 Опубликовано 26 октября, 2010 · Жалоба В IAR AVR для указателей на дальние области были квалификаторы far (24 бита) и huge (32 бита). Нет ли чего подобного в GCC? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться