Цитата(AlexandrY @ Jan 23 2011, 12:25)
У ARM-ов работающих в турбированном режиме с Flash (это частоты где-то больше 50 МГц) всегда есть модуль предвыборки, его еще акселератором называют. Идет эта предвыборка по границе выровненной 128 бит обычно (16-ть байт).
Все короткие циклы надо делать в пределах этих выровненных 16-и байт. Иначе будет вмешиваться механизм предвыборки.
Либо переносить код в RAM.
Похоже, Вы правы. Но отчасти, по части нижней частоты, при которой перестаёт вмешиваться предвыборка. Вчера экспериментировал:
1. снизил частоту до 36 Мгц, но там всё ещё нужен 1 waitstate для флэшки, и проблема оставалась - время выполнения куска кода DDS менялось. На 24МГц уже не нужны waitstate-ы, но такая тактовая частота уже маловата, теряется смысл использования АРМ-а и стал подумывать не использовать ли замечательный 8051-й от Silabs - они до 50 MIPS выдают.... Глянул бегло в их даташит - у них тоже выше 25МГц вставляются waitstates, и если склероз не изменяет, тоже есть предвыборка, и это насторожило.
2. Перенёс код DDS в RAM - и о чудо - пока работает стабильно - исполняется за детерминированное кол-во тактов. Правда, упала скорость, примерно в 1.3 раза. Насколько я понял, из-за того, что теперь данные и код читаются по одной шине. В связи с этим в по этому пункту 2 вопроса возникли 1) не начнёт ли происходить то же самое со скоростью, если вдруг захочу использовать DMA, к-й пользует ту же шину. 2) Вырастет ли скорость, если при исполнении кода из RAM на частоте 72МГц убрать те 2 waitstate-а, или они используются только при чтении кода из флэш по шине IBUS?
Цитата(ukpyr @ Jan 22 2011, 23:56)
попробуйте сначала писать в ЦАП, потом считать следующий семпл.
Не знаю, на что это может повлиять. ЦАП тактируется 36МГц, при частоте ядра 72МГц, на самом деле использую оба ЦАПа, второй выдаёт инверсный сигнал - потом проще сделать меандр с минимальным джиттером ч-з компаратор, но пишу в теневой регистр данные сразу для обоих, причём в даташите написано, что в этом режиме данные из этого регистра попадают в выходные регистры точно на следующий такт. В моём случае, имхо, не имеет значения, это ведь приведёт лишь к сдвигу фиксированному во времени всех значений на выходе.
Цитата(vptr @ Jan 22 2011, 23:47)
есть мнение что в АРМах (Кортексах) время выпонения команд не детерминировано.
вот цитата:
Архитектура микроконтроллера с ARM-ядром значительно отличается от архитектур традиционных 8-и и 16-и разрядных микроконтроллеров, и прежде всего тем что в ней используется иерархия внутренних шин соединенных межшинными интерфейсами. Шины могут работать на разных частотах, за доступ к шинам могут конкурировать много внутренних модулей микроконтроллера, обмены данными по шинам могут заканчиваться ошибками за которыми следует следить программными средствами. Это приводит к тому, что отсутствует строгий детерминизм времени выполнения инструкций как это присуще простейшим микроконтроллерам. Во многом такое положение связано с высокими частотами на которых работает ARM ядро, на таких частотах уже не способна работать FLASH...
полный текст
http://www.indemsys.ru/knowledge-base-mate...x-overview.htmlэто про STR91x. но тенденция понятна.
Да, очень на то похоже - про недерминированность. Но у меня заворот мозгов от попытки понять, что происходит, когда сначала работает одна прошивка и выполняет мой кусочек кода за 13 тактов, а затем я меняю !! одну цифру в коде инициализации, заливаю новую прошивку, и она работает уже, как повезёт, 13-16 тактов.
Что-то вроде:
u32 f1,f2,tau;
f1 = 380000;
f2 = 420000;
tau = 100; // меняю на 10, или 1000 - и меняется время исполнения. Этот параметр ессно не счётчик цикла, и лишь для инкремента аккумулятора
на это значение
DDS_Proc(f1,f2,tau); // в другом модуле на асм-е, 9 инструкций
Это происходит даже после единственного изменения в исходном коде - изменения начального значения некой переменной в некой процедуре инициализации с одной цифры на другую. Обратил внимание, что при этом ничтожном изменении, содержимое выходного файла прошивки меняется радикально.