...мне кажется вы себе усложняете жизнь, почему бы это просто на C не написать?

Тем не менее, написали кусок на ASM и это нормально!

Читать не стал, поскольку см. ниже...

Это не имеет никакого значения, поскольку у тех, котоые "во что горазд" и форматы/линкеры соответственно несовместимые, посему так или иначе библиотеку придется пересобирать и править исходники. Править всегда однотипные места в ASM исходниках, почитав абзац-другой в документации на конкретный компилятор много проще, чем разбираться с разнообразнейшими ASM вставками и последствиями их применения, для того-же конкретного компилятора.

"А я тогда кто?" © анекдот


На ум приходит только:

Хотя для этого просто нужно воспользоваться соответствующей прагмой жестко задающий нужный( высокий ) уровень оптимизации для кода/куска кода.
Кроме того, а причем это к "библиотеке"-то? Если это действительно библиотека, то как соберете сами, так и будет.

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


Идея интересная, но в gcc с прагмами туго, а вообще надо покурить документацию.


Измерения нужны для калибровке RC генератора. Алгоритм калибровки из атмеловского даташита, асм частично позамствован тоже оттуда
Один и тот же сишный код даёт разный дизасм от разных компиляторов. Gcc даёт код исполняемый за 11 тактов, iar за 7 (результаты при максимальной оптимизации по размеру). Про различную оптимизацию смотри мой предыдущий пост.

Вы к этому c Inline ASM просто рветесь всеми способами, а не избегаете

Это входит в джентельменский набор любого компилятора.

Оооооо!

Ага. Таки я телепат )) Я так и думал.

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

Посему я делаю так (это код, который поддерживает тактовую частоту равной 8 МГц)



Вот это решение правильно со всех сторон - и асма нет, и постоянно подстраивает.

По крайней мере с первого раза не скомпилировалась только одна вставка.
Из ассемблерныйх файлов пришлось править абсолютно все. Объявление переменных, ссылки, дефайны, регистровые пары для передачи параметров и т.д.
Так что всё о чём мы здесь разглагольствуем это аргументы, факты говорят о другом.


вот уж не факт. см. документацию на gcc
gcc


бывает...



Спасибо, думаю в дальнейшем пригодится. А вы пробовали измерять на интервалах меньше секунды? И на каком минимально интервале обеспечивается приемлемая точность калибровки(достаточная для обмена по уарту)? Дело в том что у меня есть тип девайсов которые работают намного меньше секунды, остальное время находятся в power save.

Документация и GCC вещи плохо пересекающиеся Поиск по тому-же gcc.gnu.org
http://www.google.com/search?client=opera&...-8&oe=utf-8

The `#pragma GCC optimize' pragma is not implemented in GCC versions earlier than 4.4.
На сайте текущая версия 4.3.2
Но это уже про gcc, а не про iar

Пожалуйста. Но, видимо, главная моя мысль в Ваш мозг пока не проникла. Она заключается в следующем - надо сравнивать значения 2х аппаратных таймеров, а не одного программного и одного аппаратного. Именно в этом корень Ваших проблем, а не в том, как разработчики разных компиляторов смотрят на идеологию написания програм на языке Си.



Тут надо смотреть, на каком интервале ошибка, вносимая программными задержками при чтении данных с таймера станет меньше, ну скажем, 0.2% (в худшем случае). Но ответить на этот вопрос сможете только Вы сами, зная программно-аппаратную архитектуру Вашей разработки.

Это Вы как определили? Опять телепатическими способностями


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

Я не могу. Я же сказал, что

Это были мысли вслух

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

Ну Вы же сами себе и ответили... , вот и усредняйте по 256 секундам например,
те смена OSCCAL не чаще чем 1 раз за 256 секунд, для уплывания по температуре это
более чем достаточно...
А для начальной настройки сделайте функции которые вызываются с отключенными остальными
прерываниями.