local register variable, в определённом регистре Опции

[xelax]

Коллеги,

у меня есть код, который собирается с помощью avr-gcc, необходимо сделать чтобы он теперь собирался и с помощью IAR.

Возникли проблемы с ассемблерными вставками, а в частности я не понимаю, как мне разместить локальную переменную в фиксированном регистре внутри функции.
Вот как это у меня реализованно на gcc. Есть какие нибудь идеи как сделать аналогично на iar.

Код

static uint16_t halMeasurement(void)
{
register volatile uint16_t cnt asm ("r24") = 0;
...
...
...
return cnt;
}

В документации нашёл только как подобное сделать с глобальными переменными, но это не то.

[Dog Pawlowa]

Есть какие нибудь идеи как сделать аналогично на iar.

Идеи есть - забить на ассемблер
IAR пошевелится и наоптимизирует лучше чем GCC + asm

[xelax]

Идеи есть - забить на ассемблер
IAR пошевелится и наоптимизирует лучше чем GCC + asm

Эт конечно понятно, но мне необходимо знать точно сколько тактов заимает сия процедура, а на С её размер будет менятся в зависимости от версии компилятора.

[Rst7]

Возникли проблемы с ассемблерными вставками

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

[xelax]

Что-то как-то грустно это всё... IAR немалых денех стоит, а функционал компилятора слабоват...
Попробую задать этот вопрос в иаровский support...

[MrYuran]

//размещаем в свободных регистрах ввода/вывода
__no_init volatile ckps_flags f1@0x22;

не моё, так что без комментариев
насчёт локальности тоже не знаю... а вдруг прокатит?

[Rst7]

IAR немалых денех стоит, а функционал компилятора слабоват...

Не знаю. Крутоват наезд, как по мне. Лично я считаю, что асмовские вставки гнуся - это лишнее. На Си же пишем, а не на помеси рязанского с французким. С точки зрения красоты лучше, когда чистый асмовский код живет отдельной жизнью в отдельных файлах.

А если надо какую-то специфическую комманду исполнить поперек сишного кода - так все в intrinsics'ах есть, всякие __watchdog_reset() и т.д.

[zltigo]

С точки зрения красоты лучше, когда чистый асмовский код живет отдельной жизнью в отдельных файлах.

Абсолютно поддерживаю и читабельность, и портируемость, и невыкручивание рук оптимизатору. Использование ASM вставок, при наличии продуманной системы intrinsics, больше тянет на мелкое пижонство, нежели на действительно полезный механизм.

[xelax]

Отлично, определились.
Я мелкий пижон, который пишет кривой код.

А помимо флуда есть что-то по существу?

[Rst7]

А помимо флуда есть что-то по существу?

Вам же ответили:

перепишите нужные процедуры на чистом асме

Кроме того, хорошо бы знать задачу более глобально. Покажите всю функцию.

[tag]

static uint16_t halMeasurement(void)
{
register volatile uint16_t cnt asm ("r24") = 0;
...
...
...
return cnt;
}
[/code]

В документации нашёл только как подобное сделать с глобальными переменными, но это не то.

...попробуйте вот так

Код

static uint16_t halMeasurement(void)
{
  static __regvar __no_init uint16_t cnt @ 14;
  ...
  ...
  ...
  return cnt;
}

будут использоваться регистры R14,R15

[xelax]

...попробуйте вот так

Код

static uint16_t halMeasurement(void)
{
  static __regvar __no_init uint16_t cnt @ 14;
  ...
  ...
  ...
  return cnt;
}

будут использоваться регистры R14,R15

Это понятно, примерно такое я нашёл в мануале на компилятор. Но проблема в том, что это static переменная, а меня интересует именно локальная. Так что такой вариант не прокатит.
К стати иаровский support тоже предложил переписать код на асме, так как оптимизатор может по своему такие вещи наоптимизировать.
Видимо прийдётся переписать на чистом асме как все нормальные ПАЦЦАНЫ , но остаюсь при своём мнении, что за такую кучу баблосов(причём за каждое рабочее место) могли бы сделать более широкую функциональность.

[zltigo]

...но остаюсь при своём мнении

Вы бы показали какую функцию хочется "заоптимизировать", а то я тоже "остаюсь при своем мнении"

[xelax]

Вы бы показали какую функцию хочется "заоптимизировать", а то я тоже "остаюсь при своем мнении"

Ну во первых я нигде и словом не обмолвился что хочу что-то оптимизировать.
Более того, считаю свои познаниями в ассемблере ниже среднего уровня и стараюсь писать код только на С.
Код который я был ВЫНУЖДЕН написать на асмовских вставках производит измерение тактовый частоты микроконтроллера, с помощью асинхронного осциллятора на часовом кварце. И поэтому мне необходимо знать сколько тактов длиться одно измерение.
Также у меня требования к коду, это работоспособность оного на любом уровне оптимизации компилятора. А теперь добавилось требование это работоспособность под IAR.
А по сему чтобы не зависеть от опций компилятора при сборке библиотеки (а моим конечным продуктом является не конечное работоспособное устройство, а библиотека с набором функций) я сделал вставки на асме.
Не стал делать функции на чистом асме по одной простой причине. Для avr нет никакого стандарта передачи параметров в функцию и обратно подобно thumb-interwork для arm. И поэтому каждый производитель asm компилятора бузует свои правила кто во что горазд. А асмовская вставка в сишный код позволяет невилировать это разнообразия-безобразия за счёт С компилятора. Так что всё таки это не пижонство , а суровые будни программиста.

Вот моя функция целиком

Код

/******************************************************************************
Calculates number of cycles during EXTERNAL_TICKS period.
Parameters:
  none
Returns:
  number of the cycles.
******************************************************************************/
static uint16_t halMeasurement(void)
{
  register volatile uint16_t cnt asm ("r24") = 0;

  ASM (
     "push r21              \n\t"

     "lds  r21, 0x00B6      \n\t" /* ASSR |= (1 << AS2) */
     "ori  r21, 0x80        \n\t" /* ASSR |= (1 << AS2) */
     "sts  0x00B6, r21      \n\t" /* ASSR |= (1 << AS2) */

     "ldi  r21, 0x01        \n\t" /* TCCR2B = 1 << CS20 */
     "sts  0x00B1, r21      \n\t" /* TCCR2B = 1 << CS20 */

     "pop  r21              \n\t"
  );

  cnt = 0;
  ATOMIC_SECTION_ENTER

#if EXTERNAL_TICKS == 100
  ASM (
     ".set  EXTERNAL_TICKS, 0x64  \n\t"
     "push r21                    \n\t"

     "ldi  r21, 0                 \n\t" /* TCNT2 = 0 */
     "sts  0x00B2, r21            \n\t" /* TCNT2 = 0 */

   "__l0:                         \n\t"
     "lds  r21, 0x00B6            \n\t"
     "andi r21, 0x1B              \n\t"
     "brne  __l0                  \n\t"  /* while (ASSR & 0x1B); */


   "__l1:                         \n\t"
     "adiw r24, 0x01              \n\t"  /* cnt ++ (2 cycle) */
     "lds  r21, 0x00B2            \n\t"  /* read TCNT2 */
     "subi r21, EXTERNAL_TICKS    \n\t"  /* TCNT2 - EXTERNAL_TICKS */
     "brmi __l1                   \n\t"  /* if TCNT2 > EXTERNAL_TICKS then exit */

     "pop r21                     \n\t"
  );

  ATOMIC_SECTION_LEAVE
  return cnt;
}
#else
  #error " EXTERNAL_TICKS must be 100 "
#endif

Первую асмовскую вставку можно было бы и не деалть, а оставить код на С, но её я написал для тренировки . А вот без второй я думаю обойтись нельзя.

[Rst7]

Код который я был ВЫНУЖДЕН написать на асмовских вставках производит измерение тактовый частоты микроконтроллера, с помощью асинхронного осциллятора на часовом кварце.

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

[tag]

Первую асмовскую вставку можно было бы и не деалть, а оставить код на С, но её я написал для тренировки . А вот без второй я думаю обойтись нельзя.

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

[zltigo]

Более того, считаю свои познаниями в ассемблере ниже среднего уровня и стараюсь писать код только на С.

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

Код который я был ВЫНУЖДЕН написать на....

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

Не стал делать функции на чистом асме по одной простой причине. Для avr нет никакого стандарта передачи параметров в функцию и обратно подобно thumb-interwork для arm. И поэтому каждый производитель asm компилятора бузует свои правила кто во что горазд.

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

Так что всё таки это не пижонство , а суровые будни программиста.

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

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

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

Также у меня требования к коду, это работоспособность оного на любом уровне оптимизации компилятора

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

[xelax]

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

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

Хотя для этого просто нужно воспользоваться соответствующей прагмой жестко задающий нужный( высокий ) уровень оптимизации для кода/куска кода.

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

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

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

[zltigo]

Вот этого я стремлюсь избежать всеми способами.

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

но в gcc с прагмами туго...

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

...продавать...

Оооооо!

[Rst7]

Измерения нужны для калибровке RC генератора. Алгоритм калибровки из атмеловского даташита, асм частично позамствован тоже оттуда

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

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

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

Код

#pragma vector=TIMER2_OVF_vect
__interrupt void INT_PLL(void)
{
  unsigned int i=TCNT1;
  TCNT1=0;
  if (i<7813)
    OSCCAL++; //Увеличиваем тактовую частоту
  else
    OSCCAL--; //Уменьшаем тактовую частоту
  SECOND_PULSE=1;
}

void InitPLL(void)
{
  TCCR1B=5; //Прескаллер 1:1024, за одну секунду - 7812.5 тактов => сравнение с 7813
  TCCR2B=5; //Прескаллер 1:128 - раз в секунду
  ASSR=1<<AS2;
  TIMSK2=1<<TOIE2;
}

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

[xelax]

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

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

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

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

Оооооо!

бывает...

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

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

[zltigo]

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

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

[xelax]

Документация и 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

[Rst7]

Спасибо, думаю в дальнейшем пригодится.

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

И на каком минимально интервале обеспечивается приемлемая точность калибровки

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

[xelax]

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

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

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

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

[Rst7]

А как собственно вы можете гарантировать такую задержку

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

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

[xelax]

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

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

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

[singlskv]

На больших интервалах это примерно усредняется, а на малых как повезёт получается?

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