Easyelectronics.ru

Частота cpu= 41 780 000 Hz.

В сети нашел следующий код:


где def_msec - количество тактов в миллисекунде. В моем случае 41 780.

Только на деле этот код создает задержку примерно в 3.6 ms.

Как создать задержку в 1 мс (примерно), без таймеров и подбора наугад?

1. таймер
2. посмотреть дизассемблированное естество и помнить, что переход это не один такт. вот это теоретически даёт три такта и два такта при выходе из цикла


твой код в теории даёт 4 такта изза проверки и пять тактов на последнем витке

товарищи, НИКОГДА(!!!), запомните, НИКОГДА не делайте точных задержек на арме программно, а тем более на си!
это вам не авр, и посчитать такты тут намного сложнее, слишком много факторов. и вроде как даже симуляторы в иаре и кейле считают неправильно. если уж и надо, то только подбирать коэффициент, на конкретном контроллере, конкретном компиляторе с конкретным реж.оптимизации, и под конкретную частоту (т.к. не всегда этот коэф. будет пропорционален частоте).

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

Подели на калькуляторе и не гадай. Проверь в симуляторе.

2smalcom: Спасибо. Хоть какая то определенность.

2Ink: Кончай флудить. Мне с самого начала нужно была задержка примерно в 1 мс.

В DLIB есть функции типа __delay_cycles(..), они считают именно циклы процессора. Ну и плюс несложные расчеты.

я в п.с. зафлудил что ли? о господи, извините меня флудераста. только пост до п.с. прочитайте ВНИМАТЕЛЬНО, если хотите понимать суть вещей. а то условные такты придумали, симуляторы... УЧИТЕСЬ ЧИТАТЬ.

Ink, у вас месячные, что ли? :))) Всем вполне понятно, что спросил топикстартер, и чего он хочет.

Самый простой и надежный вариант - использовать стандартные библиотечные функции. Можно то же самое написать в несколько строк на инлайновом ассемблере, чтобы не зависеть от причуд оптимизатора. Можно сделать и на С, проверив отладчиком, сколько тактов занимает один цикл. Но в последнем случае надо быть осторожным, при разных настройках оптимизации цикл может транслироваться по разному.

просто вы упоротые, ребята. вы не можете прочитать уже вот несколько раз, что даже по ассемблерным командам вы не скажете за сколько тактов они выполняются. и симулятор это НЕ ДЕЛАЕТ правильно!

С асмом арма я еще не знаком.
Стандартной библиотечной функции реализующей задержку в gcc не наблюдаю. Ее наверное обматерили непонятным словом.
Навскидку посчитал примерное количество тактов и на него поделил свое коэффициент. Вышла примерно миллисекунда.

И еще раз мне не нужна прецизионная задержка.
Также не интересует реализации где погрешность 200-300%. Это уже не задержка а какая то хрень.

Любой способ с подсчетом тактов даст вполне приемлемую для вас точность. Погрешность 200%-300% - это просто потому, что вы считали количество циклов, а не количество тактов.

Если хотите, можно применить более сложный метод, но это немного увеличит код. Сначала запускаете таймер, который будет работать на частоте процессора. Запоминаете его значение, запускаете свой цикл с одной итерацией, снимаете значение таймера еще раз, и вычитаете из него запомненное значение. Это даст вам длительность работы самой процедуры калибровки. Потом делаете то же самое, но с каким-то удобным для вычислений количеством итераций, несколько десятков тысяч, например. Из полученного значения вычитаете длительность процедуры, и получаете опорное значение для вычисления коэффицента. А потом будете просто умножать милисекунды на коэффицент, и запускать цикл. Можно даже еще точнее, если сделать не две, а три итерации, вычислив сначала длительность процедуры снятия значений с таймера, это даст вам возможность оценить длительность работы самой процедуры задержки, и вычитать его при запуске.

Это можно проделывать при запуске и при каждом изменении тактовой частоты процессора. А таймер потом свободен для чего угодно.

Имейте в виду, что частота внутренних RC осцилляторов прилично плавает, и рассчитывать на точность более 1% можно только при тактировании кварцем. Но это касается всех способов вычисления временных промежутков, в том числе и связанных с таймерами.

ИМХО любую задержку надо стараться делать ассемблерной вставкой...
Наподобие "запретить прерывания, цикл с вычитанием, выход из цикла с разрешением прерываний"...

WildCat, а как Вы думаете на ARM Ваш код будет одинаково выполняться из разных мест (ПЗУ,ОЗУ)? А аппаратные ускорители которые присутствуют во многих моделях?
ИМХО:
Ink ответил абсолютно правильно

Если ассемблерная вставка помечена как volatile, то этот код не будет оптимизирован.
О каких аппаратных ускорителях идет речь? Неужто в arm7tdmi есть ускоритель который сможет выполнить команду за 0,5 такта вместо 1го ?

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

2Ink: приведи пример, где одна и та же ассемблерная команда при идентичных условиях выполняется за разное количество тактов.

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

совершено согласен с a9d... Зачем изобретаем велосипед?
Согласен что не на всех мк один и тотже код будет занимать одинаковое количество тактов но как сказал a9d при одних и тех же условиях количество тактов будет постояным... Поетому 1 раз пощитали отношение частоты и количество тактов на процедуру задержки для конкретного мк и всё...

вот такой пример: армы от nxp, и армы от atmel. или код в озу, и код во флеш на тех же армах, особенно на atmel.
извини, я как SWG разжевывать не буду, и тем более не буду сейчас рыть доки, чтобы выкусить из них фразы, подтверждающие это, чтобы кому-то что-то доказать. это проверенный факт. я и так 4 уже раза сказал вам одно и то же, не хотите - забейте, потом может сами столкнетесь.

это верный подход, но они хотели вычислить, а не подбирать;) в смысле формулу узнать, я так понял.

угу. а точнее кол-во тактов на процедуру при конкретной частоте, потому что от частоты-то оно может зависеть не линейно.

ink, вы лезете в бутылку там, где это совершенно не нужно, вас потому и гоняют по всему форуму :)))

На самом деле никакого противоречия и повода для споров тут нет, проблема вообще не стоит выеденного яйца. Если хочется, вполне можно рассчитать, с приемлемой (+-10%) точностью, только надо учитывать особенности конкретной архитектуры, условия выполнения (Flash, RAM), и задержку при обращении к Flash, которая как правило зависит от частоты. Если не хочется считать, можно сделать простую калибровку, точность будет сильно выше, сравнима с точностью работы прерывания таймера.

Тут вот что надо заметить. Затраты времени, труда и умственных усилий при расчете коэффицента задержки вручную будут скорее всего выше, чем при написании процедуры калибровки (которая проста, как сапог). А времени выполнения и аппаратных ресурсов на эту процедуру уйдет настолько мало, что этим просто можно пренебречь, во всяком случае если речь идет о ARM.

Если же у вас постоянно плавает частота, в зависимости от каких-то условий, то периодическая перекалибровка (по источнику, частота которого остается неизменной, например по часовому кварцу) вообще практически единственный вариант.

2Ink: Может докажешь свои знания?

Полистал даташиты обоих семейств контроллеров. Где находится информация о том, что одна и таже инструкция выполняется за разное количество тактов на этих контроллерах?

a9d, отвечу за Ink (надеюсь извинит) полистай раздел "МАМ". Думаю вопросы пропадут.

О том, что ядро и память работают в армах на разных частотах я знаю. Подобное написано везде.

Аппаратная задержка это дикремент регистра и проверка его на равенство нулю. Разве подобные команды будут на разных контроллерах отрабатывать за разное количество тактов?
Ведь данные хранятся в регистрах.

Первая итерация и выход из цикла нам погрешность разве не добавит? Или Вы считаете, что можно пренебречь?
>>Ведь данные хранятся в регистрах.
а ARM из памяти ни когда и не умел работать. Загрузка в регистры-> расчет -> выгрузка в память

2Виталич: Почитайте внимательно. Требуется задержка примерно в 1 мс. Погрешность допустима.