реклама на сайте
подробности

 
 
> LPC, время доступа к внутренней RAM
toweroff
сообщение Jan 15 2013, 15:18
Сообщение #1


Гуру
******

Группа: Свой
Сообщений: 2 957
Регистрация: 19-09-06
Из: Москва
Пользователь №: 20 514



Добрый день всем!
Что-то в даташите не найду сабжа. Понятно, что в DC разделе, но не вижу...
Где обычно NXP такие вещи указывает?
Мне б примерно, от CCLK отталкиваясь, посмотреть, сколько NOP займет

Там пляски с бубном какие-то... без оптимизации внешний девайс прекрасно работает на внешней шине асинхронной, с O3 & Time свистопляска какая-то sad.gif
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
kovigor
сообщение Jan 15 2013, 15:43
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 5 273
Регистрация: 30-03-10
Пользователь №: 56 295



Цитата(toweroff @ Jan 15 2013, 18:18) *
без оптимизации внешний девайс прекрасно работает на внешней шине асинхронной, с O3 & Time свистопляска какая-то sad.gif

Было такое, на LPC и с Кейлом. Почти наверняка дело не в скорости доступа к ОЗУ, а в оптимизации. Запретите компилятору оптимизировать, например, процедуры, формирующие временные диаграммы на шине. Для этого перед не допускающим оптимизации кодом напишите:

Код
#pragma O0

потом, если нужно, снова включите оптимизацию:

Код
#pragma O3

Например:

Код
//установка бита GPNVM[0..2].
//В случае успеха возвращает "0", в случае ошибки возвращает "1"
unsigned int set_gpnvm_bit(unsigned int gpnvm_bit_to_set)
{
#pragma O0
unsigned int i;

*AT91C_EFC_FCR = (0x5a000000 | (gpnvm_bit_to_set << 8) | 0x0b);
i = 0;
while ((i & 0x00000001) == 0) i = (*AT91C_EFC_FSR);
//Проверяем, не было ли ошибки (для этой команды
//возможна только одна ошибка: "Bad command")
if (i & 0x00000002) return 1; else return 0;
#pragma O3
}


А еще гляньте осциллографом временные диаграммы на шине ...
Go to the top of the page
 
+Quote Post
toweroff
сообщение Jan 15 2013, 17:41
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 2 957
Регистрация: 19-09-06
Из: Москва
Пользователь №: 20 514



Цитата(kovigor @ Jan 15 2013, 19:43) *
Было такое, на LPC и с Кейлом. Почти наверняка дело не в скорости доступа к ОЗУ, а в оптимизации.

так в оптимизации и дело sm.gif
Нет, у меня никак программно функции задержки не делаются. Там, похоже, дело в том, что девайсу нужно "отдохнуть" около 70нс после доступа. Если код не оптимизировать, то оно как раз и получалось. Как только перекинул функции в RAMFUNC (они будут обслуживать бутлоадер), так и начались пляски
Вот теперь сижу и NOP вставляю, но все равно как-то мутно sad.gif

Возможно, дело связано с компилятором, он неверно воспринимает описание доступа к памяти (как вариант)
У меня сидит внешняя 32-разрядная SRAM на CS4, на CS0 сидит девайс

Я передаю указатель как (void*), а в функциях чтения/записи в девайс присваиваю его указателю на (volatile unsigned int*)
Интересно, но часть команд, котрые обращаются к внутренней SRAM, отрабатываются. Как только лезу к внешней - начинаются проблемы с девайсом уже, он не передает то, что в него пишется. Сейчас проверю осциллом, что там происходит, но часть команд отрабатывается, часть - нет, особенно, когда уже начинаю гнать блоки по 50-100 КБ
Однако, если просто гонять туда-сюда данные от девайса и к нему, все в порядке с любой оптимизацией
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 26th June 2025 - 01:48
Рейтинг@Mail.ru


Страница сгенерированна за 0.01397 секунд с 7
ELECTRONIX ©2004-2016