[alm_ 0]

Необходимо отмерить задержки в миллисекундах с с точностью до 5%. Очевидно, что при использовании С для различных компиляторов может быть различен. Вывод: необходимо использовать inline-функций на Asm. Но вот вопрос одинаковое ли количество тактов выполняются одни и те же команды для различных семейств (Tini,Classic,Mega) ?

[Rst7 5]

Необходимо отмерить задержки в миллисекундах с с точностью до 5%. Очевидно, что при использовании С для различных компиляторов может быть различен. Вывод: необходимо использовать inline-функций на Asm. Но вот вопрос одинаковое ли количество тактов выполняются одни и те же команды для различных семейств (Tini,Classic,Mega) ?

 

__delay_cycles(сколько тактов) в IAR'е решат ваши проблемы ;)

[IgorKossak 0]

__delay_cycles(сколько тактов) в IAR'е решат ваши проблемы ;)

Но если важна точность, то придётся запрещать прерывания.

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

Возможны варианты только для очень специфических команд (сейчас не вспомню каких). Но в Вашей задаче они явно не будут использоваться.

[beer_warrior 0]

Поправочка, далеко не в специфичных, а во всех ветвлениях.

1 такт если прдолжаем, 2 если прыгаем.

Обусловлено сбросом конвейера команд.

[IgorKossak 0]

Поправочка, далеко не в специфичных, а во всех ветвлениях.

1 такт если прдолжаем, 2 если прыгаем.

Обусловлено сбросом конвейера команд.

Речь была о другом.

одинаковое ли количество тактов выполняются одни и те же команды для различных семейств (Tini,Classic,Mega) ?

[Rst7 5]

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

Возможны варианты только для очень специфических команд (сейчас не вспомню каких). Но в Вашей задаче они явно не будут использоваться.

 

Я знаю ;) Задача не моя ;) Просто я предложил человеку, как возложить на компилятор вопрос подсчета.

[alm_ 0]

спасибо за ответ

но у меня идет одновременная работа с WinAVR и IAR и хотелось бы чего-нибудь универсального

[beer_warrior 0]

Функции на асме, не обязательно инлайн.

Расходы на call/ret известны, количество тактов - одинаково.

Если подходить совсем глобально, вставить препроцессорный макрос высчитывающий количество проходов цикла в зависимости от частоты.

Запретить прерывание внутри.

Но это более пригодно для микросекундных задержек.

Для миллисекундных я например использую 2-й таймер с автоперезагрузкой с циклом в 100мкс, а от него веду софтварные таймеры, в которые вставлены хэндлеры функций. Точность получается весьма пристойная для самых критичных задач.

[VslavX 0]

Если есть аппаратный декрементируемый/инкрементируемый счетчик с фиксированным периодом переполнения (а обычно в AVR один-два таймера настраиваются на генерацию какой-то фиксированной частоты), то можно воспользоваться алгоритмом функции delay(), которая применялась в DOS. В аттаче исходник из BC3.1 и фрагмент из моей программы реализующий тот же алгоритм для AVR (MEGA128).

delay.rar

[defunct 0]

(IgorKossak @ Feb 8 2006, 14:41)

 

Возможны варианты только для очень специфических команд (сейчас не вспомню каких). Но в Вашей задаче они явно не будут использоваться.

Видимо имелись в виду RCALL, CALL, ICALL, EICALL, RET, RETI, а также неявная команда перехода на обработчик прерывания. Время выполения которых зависит от разрядности PC.

[IgorKossak 0]

(IgorKossak @ Feb 8 2006, 14:41)

 

Возможны варианты только для очень специфических команд (сейчас не вспомню каких). Но в Вашей задаче они явно не будут использоваться.

Видимо имелись в виду RCALL, CALL, ICALL, EICALL, RET, RETI, а также неявная команда перехода на обработчик прерывания. Время выполения которых зависит от разрядности PC.

Ради интереса взял даташиты на mega128 и tiny13.

Очень беглое сравнение наборов инструкций показывает, что для ВСЕХ инструкций (имеющихся у обоих МК) времена исполнения совпадают.

[defunct 0]

Видимо имелись в виду RCALL, CALL, ICALL, EICALL, RET, RETI, а также неявная команда перехода на обработчик прерывания. Время выполения которых зависит от разрядности PC.

Ради интереса взял даташиты на mega128 и tiny13.

Очень беглое сравнение наборов инструкций показывает, что для ВСЕХ инструкций (имеющихся у обоих МК) времена исполнения совпадают.

Не могу сказать оригинального имени документа, поскольку он у меня сохранен под удобным для поиска именем (в оглавлении документа написано "AVR Instruction Set" rev. 0856D-AVR-08/02). В нем можно найти различия во времени выполнения приведенных выше команд, для МК с PC - 16bit и меньше и для MK с PC - 22bit.

[IgorKossak 0]

... MK с PC - 22bit.

Я это тоже видел, но к счастью таких нет среди тех, которые фигурировали в вопросе у автора темы.

[defunct 0]

Я это тоже видел, но к счастью таких нет среди тех, которые фигурировали в вопросе у автора темы.

Отчего же так? В вопросе фигурирували чуть ли не все существующие МК с AVR ядром. Как минимум в одном из указанных в вопросе семейств(mega) есть предствитель 22bit PC (ATMega2560/1).

Согласен с Вами в том, что автору вопроса пока не доведется работать с МК с 22bit PC, и что можно считать, что все одноименные команды AVR tiny/classic/mega выполняются за одинаковое число тактов.

 

Может говоря о специфических командах имелись в виду "специфические МК" с широким PC? :)

 

ps: не ставлю целью Вам докучать, просто самому стало интересно, и если действительно есть такие специфические команды, то неплохо бы их знать..

[Halfback 0]

__delay_cycles(сколько тактов) в IAR'е решат ваши проблемы ;)

а в CAVR что решит проблемы?

использовал ф-цию delay_ms(10) дык вместо формирования меандра с Ти=10мс почему то Ти=2,5мс, т.е. приблизительно в 4 раза быстрее. Кварц. генератор = 2Мгц, МЦУ = Мега88.

ЧТо посоветуете? Писать новую функцию, запихивать в нее nop-ы путём подбора с осциллографом? Задача выдавать импульсы с погрешностью хотя бы 1мс - и с delay_ms такой облом. При помощи счетчиков не хотелось бы заморачиваться.

Изменено 17 января, 2009 пользователем Halfback