CodeVisionAVR 2.60

[Арктур]

Насколько помню, обошлось без них. Иначе бы не написал об этом.
МК ещё сортировать и редактировать успевал этот текст, поступавший по RS-232.
Вывод в несколько рядов.

[Godzilla82]

Насколько помню, обошлось без них. Иначе бы не написал об этом.

Если грамотно подойти к вопросу, думаю, и на CV такое можно сделать без проблем.

P.S. Только тема совсем не о том.

[SasaVitebsk]

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

Я, например, не возражаю. Я, правда, возражаю против того, что он лучший.
С другой стороны, для конкретного пользователя, лучшим является тот инструмент, которым он умеет пользоваться. В принципе хорошо, что вы глубоко копаете. Всё остальное придёт.
Но с одним, я никак не соглашусь. Если вы сами говорите, что применение volatile не ухудшит качество компилируемого кода, то совершенно непонятно, почему вы рекомендуете не его не писать? Наоборот необходимо писать. Как минимум приучаться.

[Godzilla82]

Я, например, не возражаю. Я, правда, возражаю против того, что он лучший.

Я никогда не говорил, что CV лучший

Но с одним, я никак не соглашусь. Если вы сами говорите, что применение volatile не ухудшит качество компилируемого кода, то совершенно непонятно, почему вы рекомендуете не его не писать?

Я наоборот говорю, что в CV может ухудшить (при наличии свободных регистров). А если не писать - у переменной есть шанс оказаться в регистре.

[tempora]

CV - обычный себе компилятор

Тут важно ответить на вопрос - компилятор чего этот ваш CV? Впрочем, даже если согласиться на написание программ не на языке Си, а на некоем его CV-диалекте, даже если согласиться с потерей надёжной связи с миром Си-библиотек, всё равно останется одна проблема - глюки. Причём, ладно бы они повторялись из версии в версию, так нет же - одни уходят, другие появляются. Не раз уже всё и обсуждалось, и взвешивалось - нет никаких причин ограничивать себя до узких рамок CV и AVR, кроме одной - интеллектуальное бессилие.

Ассемблер - сколько не пытался, не могу на нём мыслить.

Ой, йооо...

[Godzilla82]

нет никаких причин...

Пукнули в очередной раз и довольны. Надеюсь вам полегчало

[SasaVitebsk]

... даже если согласиться на написание программ не на языке Си, а на некоем его CV-диалекте ...

Раз уж Вы затронули. Я смотрю на это шире.
Вам всё время предлагаются какие-то шаблоны. И Вы вольны выбирать использовать их или нет. Более того, часто мы начинаем свои какие-то шаблоны создавать и в рамках их работать.
Приведу пример. IAR AVR позволяет обращаться к битам порта. Для этого созданы макросы. Причём эти макросы общие для разных процессоров. Честно говоря, как по мне, они совсем неудобные.
Только что работал с MSP430, в стандартных библиотеках просматривается подход TI. Тоже энтузиазма у меня не вызывает.
Наиболее красивый подход, абсолютно в рамках языка, предлагается в CMSIS.
Я не вижу причин почему бы этот подход не перенести на AVR, к примеру. Да и вообще, почему бы его не узаконить.

Скажем упрощённое описание порта выглядело бы так, в хидере...

typedef struct
{
  __IO uint8_t  PINA;
  __IO uint8_t  DDRA;
  __IO uint8_t  PORTA;
} GPIO_TypeDef;
...
#define GPIOA_BASE            (0x0800)
...
#define GPIOA               ((GPIO_TypeDef *) GPIOA_BASE)

Ну и обращение к нему типо GPIOA-›PORTA =
Также можно и биты расписать именно в рамках языка
можно так, к примеру.

typedef struct
{
   uint8_t  
     b0 : 1,
     b1 : 1,
     b2 : 1,
     b3 : 1,
     b4 : 1,
     b5 : 1,
     b6 : 1,
     b7 : 1;
} bit_t;

typedef struct
{
  __IO bit_t PINA;
  __IO bit_t DDRA;
  __IO bit_t PORTA;
} GPIO_TypeDef;
...
#define GPIOA_BASE            (0x0800)
...
#define GPIOA               ((GPIO_TypeDef *) GPIOA_BASE)

Ну и обращайтесь к битам GPIOA-›PORTA.b3 = TRUE;
Причём это скомпилируется любым компилятором - CV, IAR, GCC.
Возьмём таймер:

typedef struct
{
   uint8_t  
     FOC0A  : 1,
     WGM00 : 1,
     COM0A : 2,
     WGM01 : 1,
     CS0     : 3;
} tccr0a_t;

#define _TCCR0A               (*(tccr0a_t*) 0x24)

Обращение _TCCR0A.CS0 = 3; // clk/64

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

[makser1]

Тестировал я компиляторы IAR MikroC CVAVR на выполнении FFT, так CVAVR самый медленный и большой оказался.
cvavr 3832b-7880ms
mikroc 3620b-5400ms
IAR 3398b-1200ms
Я на нем тоже начинал изучать МК. И проекты не слабые писал.
Но теперь только ARM+GCC

[tempora]

Я не вижу причин почему бы этот подход не перенести на AVR, к примеру.

Если это мне, то поздновато - я так уже лет *дцать и делаю.

Я смотрю на это шире. Вам всё время предлагаются какие-то шаблоны. И Вы вольны выбирать использовать их или нет.

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

Пукнули в очередной раз и довольны.

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

[Godzilla82]

Любезный, вы об этих материях лучше не рассуждайте

Я вам не любезный, это раз. А во вторых - оставьте свои желчные рассуждения при себе.