NiosII, C/C++., Локализация данных в пространстве адресов. Опции

[Волощенко]

Всем привет!
В NiosII используется Avalon Memory-Mapped (Avalon-MM) interfaces, как я понимаю, основанный на архитектуре с общим пространством адресов. В это пространство может включаться SRAM, DRAM, Flash, Onchip_Memory и периферия, начальные адреса, которых определены в system.h.
Вопрос такой: Как средствами NiosII C/C++ отображается локализация данных в разных областях памяти? Например, один массив переменных нужно разместить в SRAM, другой массив констант во Flash и т.п., а обращаться к этим данным через указатели.
Работая с компиляторами для микроконтроллеров архитектур 51, 196 и AVR, заметил, что для каждого описаны свои способы локализации, а для NiosII С/С++ подобного описания что-то не нахожу… Может кто подскажет, где это описано или приведет примеры.

[Stewart Little]

Попробуйте поискать в направлении сегменотв памяти:
сегмент кода (.text)
сегмент инициализируемых данных (.rodata)
сегмент неинициализируемых данных (.rwdata)
сегмент стека (.stack) - до кучи

В принципе, это общепринятая концепция для 32-разрядных процессоров.

[Kuzmi4]

2 Волощенко - а не проще ли наваять на асме свою процедрку начального переброса и обращения и использовать их ?

Хотя реализация средствами GNU тоже интересна..

[Волощенко]

Вот, например, в Keil C51 есть такие виды памяти: data, xdata, bdata, sbit, pdata. И есть возможность разместить данные по своему желанию (ниже отрывки кода):
data byte RiT, RoT;
xdata byte Ri[32],Ro[260]; // --- Block for RS-232 communication ---
bdata Flags;
sbit MainLoop = Flags^0; //Flag for Main loop
*((char pdata *)Rx)=*(pEthPcm++);

аналогичная ситуация в IAR для AVR
word wa, wb, wc, wd, w0;
byte FlagTIMER0;
__eeprom byte IEEE_addresse[6];
__flash byte CLC1 []={0x01, 0x64, 0x89, 0x00};


Понятно, что это другой дивизион... Но хотелось бы видеть что-то аналогичное и в NiosII C/C++. Поэтому вопрос остается прежним: кто и как в таких ситуациях поступает (см. первый пост). Ведь данные, иногда, надо размещать по разным адресам.

to Kuzmi4. К асму в крайнем случае перейти можно, но хотелось бы разобраться с C/С++...

[cms]

каждому сегменту памяти типа .text/.data/.code можно выбирать компонент памяти, в котором он размещается. если работаете с NIOSII IDE, то посмотрите на property SystemLibrary - там в комбо-боксах выпадают списки всех сгенеренных в SOPC Builder в компонент памяти.

если работаете скриптами - то там эти проперти прописываются при вызове bsp-билдера в tcl-скрипте

[id_gene]

Почему бы не сделать просто:

Код

#include <system.h>

char *foo_CONST = DDR_BASE;
unsigned int *foo_data = ONCHIP_BASE;

foo_CONST[0] = 0x0;
foo_CONST[3] = 0x3;

foo_data [0] = 0x1234;
foo_data [123] = 0xABCD;

[cms]

Почему бы не сделать просто:

Код

#include <system.h>

char *foo_CONST = DDR_BASE;
unsigned int *foo_data = ONCHIP_BASE;

foo_CONST[0] = 0x0;
foo_CONST[3] = 0x3;

foo_data [0] = 0x1234;
foo_data [123] = 0xABCD;

A а если bsp builder по ONCHIP_BASE разместил код или стек?

[torik]

А что, указать локализацию в свойствах проекта не хватает, не?

[vadimuzzz]

все компоненты системы на базе ниоса memory-mapped, т.е. достаточно знать нужный адрес.
а потом IOWR(address,data) или IORD(address)
если это устройство(любое), то смотрим в файл system.h + файл описания регистров устройства.
если это память, то еще проще: IOWR(address,data) или IORD(address).
насчет разделения памяти на сегменты-это удобно, если есть RO-данные (их во флеш), остальные в RAM.
если флеш - CFI, то вообще сказка, работа с RAM и ROM осуществляется одними и теми же макросами IORD,IOWR.
если EPCS-то посложнее, но ненамного.
если мне не изменяет склероз, то квалификатор типа const в языке C как раз и указывает компилятору,
что переменную надо кинуть в секцию rodata.

[Kuzmi4]

2 vadimuzzz - это я собсно и имелл ввиду.

2 Волощенко - тут на ум пришло - в GCC есть понятие секций - там в WinAVR`е помню можно было атрибутами указать, что писать надо в еепром, например, а потом в линкере если что подредактить - может стоит в эту сторону покопать ??

[Harbour]

Стандартная тема, на форуме сплошь и рядом обсуждается. Вкратце - память проекта состоит из разных "секций", нменованных по умолчанию (.text/.data/.bss) и заданных разработчиком в линкер-файле. Разработчик составляет карту памяти (on-chip-ram/ext-ram/flash), именует секции и определяет в какой области памяти оные будут размещены. Далее в программе указывает (в gcc это делается с помошью attribute section) в какой секции размещать указаные переменные. При генерации прошивки создаются (objcopy) бинарные файлы соответствующие кажной секции. Но это идеальная картина - для корректной работы программы необходимо чтобы данные оказались по нужным адресам в флеше/озу/etc. после ресета. Тут вступает в дело startup-code, который выполняется перед main - обычно подходит тот что предлагается фирмой по умолчанию, но иногда для удобственности можно написать свой - задача этого code именно и состоит в приведении устройств памяти в изначальное состояние так необходимое для работы программы. В embedded вариантах этот код еще может заниматься инициализацией BSP. например заполнение irq table, обнуление static vars, вызов конструкторов (c++) и т.д.
Чем хорош gcc/gas - не нужно парится по изучению 20 линкеров и способов передачи ему параметров из программ - выучил один и пошел пить пиво

[id_gene]

A а если bsp builder по ONCHIP_BASE разместил код или стек?

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

Как располагать функции в нужных секциях написано в Sw developer book в главе Memory Usage/Memory Sections.
Можно ли управлять таким же образом массивами данных?

[Волощенко]

Спасибо всем за ответы, стало понятней.

[Kuzmi4]

2 Волощенко - не забудьте поделится результами - самому интересно

[608]

Да, уточните...

Сообщение отредактировал 608 - Jun 20 2008, 11:52

[Волощенко]

2 Волощенко - не забудьте поделится результами - самому интересно

//Это описание переменных в ssram
alt_u8 mm[16] __attribute__ ((section (".ssram.rwdata")));
// Это часть кода для вывода на консоль
for (y=0;y<10;y++) mm[y]=y;
for (y=0;y<10;y++) {printf(", mm=%04x\n", mm[y]);};
//а программа и все остальное onchip_memory

[Kuzmi4]

Атрибуты спасли ситуацию

2 Волощенко -
Касательно

.ssram.rwdata

Вы этот сегмент как то описывали где то, или просто добавили в систему SSRAM и заюзали атрибут ?

[Волощенко]

Вы этот сегмент как то описывали где то, или просто добавили в систему SSRAM и заюзали атрибут ?

Я работаю с платформой DK-NIOS-2S60N, в ней SSRAM, Flash, DDRAM, а также память в FPGA. С помощью SOPC подключил SSRAM и Flash, надо же как-то их задействовать. Как назначить там переменные, см.предыдущий пост. В свойствах syslib по умолчанию для всех переменных задана onchip_memory что в FPGA, а атрибутами можно в нужном месте переназначать их локализацию.
Подсказка дана id_gene, за что ему большое спасибо, а главная ссылка на Nios II Software Developer's Handbook, глава Memory Usage/Memory Sections.

[Kuzmi4]

Ага, на сколько я понял, то нужно добавить в систему память, а потом уже в коде атрибутами типа

section (".ssram.rwdata")

указать куда ложить в памяти - на сколько я понял хал там сам разберётся..

[yura-w]

Как средствами NiosII C/C++ отображается локализация данных в разных областях памяти

есть пример на сайле альтеры
tcm_vs_cache.c
и Using Nios II Tightly Coupled Memory.pdf к ниму;
там можно посмотреть инициализацию Tightly coupled memory / On-chip / SDRAM
(и вообще интересный примерчик, о производительности)

[Волощенко]

есть пример на сайле альтеры
и Using Nios II Tightly Coupled Memory.pdf

Спасибо за новую информацию!

По поводу главного вопроса топика, как уже писал, обошелся для размещения в ssram так:
alt_u8 RsInp [32] __attribute__ ((section (".ssram.rwdata")));
alt_u8 RsOut [256] __attribute__ ((section (".ssram.rwdata")));
alt_u8 RsT, RsN, RsC, RsK __attribute__ ((section (".ssram.rwdata")));
alt_u8 *RsI, *RsO __attribute__ ((section (".ssram.rwdata")));

Если не добавить атрибутику типа __attribute__ ((section (".ssram.rwdata"))), то компилятор автоматически размещает переменные в onchip_memory..., т.к. в свойствах System Library для всех типов памяти у меня прописано onchip_memory.


Вот еще вопрос: На моей платформе DK-NIOS-2S60N есть и DDRAM, там емкости немеряно... Пока не понял, как к ней подступиться. Похоже надо корку где-то искать, или самому синтезировать, видать, без нее не обойтись. Кто и как разрешил эту проблему? Поделитесь опытом!!!

[vadimuzzz]

Вот еще вопрос: На моей платформе DK-NIOS-2S60N есть и DDRAM, там емкости немеряно... Пока не понял, как к ней подступиться. Похоже надо корку где-то искать, или самому синтезировать, видать, без нее не обойтись. Кто и как разрешил эту проблему? Поделитесь опытом!!!

с месяц назад пробовал на циклон3-стартер-кит. основная проблема была-скомпилировать проект, для DDR нужно
правильные констрейны на I/O навесить, иначе тупо не соберется. лучше всего взять пример с фтп альтеры или
на ниосфоруме пошарить. корку я брал альтеровскую, но видел и примеры с опенкорками. время будет, вкорячу на эту плату линукс

[Kuzmi4]

2 vadimuzzz - будьте так добры, тыканите носом в пример с фтп альтеры ?
А то есть желание вылазить с сдрама, а про подводные камни для ДДР с осотороны плиса не особо знаю...