Здравствуйте, товарищи.
Подскажите, пожалуйста, новичку такую вещь. Имеется, значит, контроллер LPC1758 с разделяемой встроенной ОЗУ 64 кбайта, и надо каким-то образом задействовать в программе как минимум 48 кбайт для глобального массива. При попытке откомпилить код с массивом такого размера выскакивают две ошибки с кодами L6406E и L6407E, указывающими о нехватке места. Среда разработки - Keil 4.54. В опциях таргета поставил галки напротив IRAM1 и IRAM2, указал адреса старта и размеры (по 32 кбайта). В чем может быть проблема?
Полная версия этой страницы: LPC1758 и RAM
Может, в том, что ему нужна непрерывная область достаточного размера, относящаяся к одному региону памяти (IRAM1 и IRAM2 будут разными регионами, даже если они вплотную примыкают друг к другу).
Цитата(Тапочек @ Sep 27 2012, 23:37) 
...
SII указал причину проблемы. Вы внимательно прочитайте, начиная с первой страницы, описание конироллера (/LPC1759_58_56_54_52_51), где сказано о распределении областей памяти. Далее раздел 7 стоит изучить.
Спасибо, помогло.
Цитата(SII @ Sep 27 2012, 23:47)
IRAM1 и IRAM2 будут разными регионами, даже если они вплотную примыкают друг к другу
Проблема как раз в том, что между двумя областями памяти расположена "дырка".
Если б её не было, можно было б объявить память одним регионом и спокойно использовать целиком. То, что физически эти два банка сидят на разных шинах, ни компилятору, ни программисту не видно. Спасибо фон Нейману
Кстати, вопрос в тему. Если я не пользуюсь DMA, с точки зрения производительности есть разница, в какой именно области памяти лежат данные?
Вопрос именно по LPC17xx с его хитрый структурой шин - основной банк памяти подключен к ядру шинами D-bus, I-bus, "периферийные" (название - из "описательной" части даташита) - по шине system bus, на которой вдобавок вся периферия (через соотв. мосты).
Цитата(esaulenka @ Oct 1 2012, 19:08)
То, что физически эти два банка сидят на разных шинах, ни компилятору, ни программисту не видно.
Станет видно при попытке использовать BITBAND работу с битами :-), которая есть только в AHB-шном блоке.Цитата(esaulenka @ Oct 1 2012, 19:08)
Если я не пользуюсь DMA, с точки зрения производительности есть разница, в какой именно области памяти лежат данные?
Вот до того, чтобы обращать внимание на производительность, я ещё не дошёл.
Люди добрые, есть еще один вопросец. В keil я создаю буфер разумных размеров (контроллер все тот же - LPC1758) и пытаюсь присвоить ему абсолютный адрес таким макаром:
unsigned char buffer[BUF_LEN] __attribute__((at(0x10000000)));
Компилятор выдает ошибку. Если указать адрес банка 0 или 1 аналогично, то все нормально. Чего делать-то?
unsigned char buffer[BUF_LEN] __attribute__((at(0x10000000)));
Компилятор выдает ошибку. Если указать адрес банка 0 или 1 аналогично, то все нормально. Чего делать-то?
Уменьшать BUF_LEN
Пробовал, не помогает. Даже если размер 1 указывать.
Попробуйте создать новый проект.
У меня вот это
выдаёт
uVision V4.20.03.0
У меня вот это
CODE
// main.c
#include <lpc17xx.h>
#define BUF_LEN 30000
unsigned char buffer[BUF_LEN] __attribute__((at(0x10000000)));
int main(void)
{
int i;
for ( i = 0; i < BUF_LEN; i++ )
{
buffer[i] = LPC_UART0->RBR;
}
return 0;
}
#include <lpc17xx.h>
#define BUF_LEN 30000
unsigned char buffer[BUF_LEN] __attribute__((at(0x10000000)));
int main(void)
{
int i;
for ( i = 0; i < BUF_LEN; i++ )
{
buffer[i] = LPC_UART0->RBR;
}
return 0;
}
выдаёт
CODE
Build target 'Target 1'
assembling startup_LPC17xx.s...
compiling main.c...
linking...
Program Size: Code=368 RO-data=400 RW-data=0 ZI-data=30608
"test1758.axf" - 0 Error(s), 0 Warning(s).
assembling startup_LPC17xx.s...
compiling main.c...
linking...
Program Size: Code=368 RO-data=400 RW-data=0 ZI-data=30608
"test1758.axf" - 0 Error(s), 0 Warning(s).
uVision V4.20.03.0
В новом проекте нормульно все, действительно. Что ж тогда со старым делать?
Перенести исходники в новый проект. Старый закопать. Как-то так
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.