Синтаксис языка С в AVR Studio 5

[ut1wpr]

Если совсем заморачиваться стандартами Си - можно и подохнуть.

Живу пока. Уже 63 года, не подох.

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

Это не возможности компилятора, сударь, это способности программиста написать удобные и нужные ему макросы-дефайны.
И если он не забудет их определения включит в расшареный проект - буду только рад поучится чужому умению.
Удивляет другое.
Почему понаписывав в своих хидерах этих самых дефайнов авторы не удосуживаются приложить их к паблишинг?

PS: вы сами часто встречали сорцы, которые проглотит любой компилятор? о.О

Видимо, мне везло больше. Или попадались
сорсы, написанные грамотными программистами. Во всяком случае я понимаю практически все, что хотел сказать автор той или иной программы.
И трудностей в портировании у меня не возникало. И не только внутри одной платформы, но и при переносе проектов с PIC на AVR и наоборот.
Но это к теме топика не имеет отношение, потому и откланиваюсь с извинениями за легкий оффтоп.

[Мастер Ломастер]

В avr-gcc вместо (1<<PB2), например, можно использовать _BV(PB2).
Т.е. пример выше будет выглядеть так:

Код: Выделить всё

PORTB &= ~( _BV(PB2) | _BV(PB3) | _BV(PB6) );

И опять получим код, который будет понимать только ГСС. Это тот же макрос, только встроенный в Гнусь.

это не встроенный в гнусь макрос, а обычный макрос, описанный в одном из хидеров. никакого отступления от стандартов нет и быть не может. тем более что если совсем станет плохо, ввести определение #define _BV(x) (1 << (x)) совсем не сложно. в отличие от PORTB.1 макрос _BV() будет понимать ЛЮБОЙ компилятор Си. совершенно любой.

[ut1wpr]

И опять получим код, который будет понимать только ГСС. Это тот же макрос, только встроенный в Гнусь.

это не встроенный в гнусь макрос, а обычный макрос, описанный в одном из хидеров. никакого отступления от стандартов нет и быть не может. тем более что если совсем станет плохо, ввести определение #define _BV(x) (1 << (x)) совсем не сложно. в отличие от PORTB.1 макрос _BV() будет понимать ЛЮБОЙ компилятор Си. совершенно любой.

"Описанный в одном из хидеров" и есть "встроенный" в GCC, т.к. этого хидера нет в составе других компиляторов. Следовательно, ни один компилятор, кроме GCC без подключения этого хидера не будет ничего знать про этот дефайн. Я же постом выше написал, что подключив нужные хидеры, любой компилятор распознает любые дефайны, если они написаны ПО СТАНДАРТУ ANSI C. Ну не может Си работать вне его стандарта!
Утверждение, что _BV() будет обработан любым компилятором (я не увидел фразы "с подключением специфического хидера, в котором декларирован этот макрос), это утверждение неверно. Подтверждение ниже:

.

PS
"#define _BV(x) (1 << (x))" - а где здесь указание порта? PB3 тоже специфичное описание, не попадающее под стандарты, ему также нужен свой дефайн.
Вам надо универсальный дефайн? Так будет лучше:

Код: Выделить всё

#define SETBIT(DEST, BIT) = {DEST |= (1<<BIT);}
#define CLRBIT(DEST,BIT) = {DEST &= ~(1<<BIT);}

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

[coredumped]

И чем же тут GCC ушел от стандарта? Правильно Мастер Ломастер все написал. Просто нужно сравнивать разные реализации libc, а не компиляторы. А во всем виноваты IDE - отбили они у программеров способность думать Посмотрите хоть раз внутрь Makefile и разберитесь, зачем оно там все написано - и многое станет понятно.
PS: Гуглить советую по словам "AVR LIBC"

[Leo_vrn]

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

Если писать всё в режиме совместимости с ANSI C, то уж, извините, на Ассемблере писать будет проще и быстрее (а заодно и кода меньше в прошивке, причём много более оптимизированного).


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

[Мастер Ломастер]

В моём понятии это и есть синтаксис языка.

не подменяйте одно понятие другим. синтаксис языка - это словарь, букварь, а вовсе не "Евгений Онегин" или "Гамлет". синтаксис определен стандартом, а вот макросы, хидеры и специфические функции - это уже варианты применения этого синтаксиса.

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

а вы читали-то документацию для avr-libc, которая идет вместе с WinAVR в комплекте?! там все отлично описано, подробно. есть и более-менее приличный перевод с комментариями

ПО СТАНДАРТУ ANSI C. Ну не может Си работать вне его стандарта!

может, и еще как может! например, всеми любимый CVAVR отлично работает, плюя на стандарт PORTB.1 не определено нигде, ни в каком стандарте языка Си, С++ и даже C#

Подтверждение ниже:

уважаемый, вы меня огорчили страшно! вы сами-то думали, когда писали пример, подтверждающий что-то по-вашему важное?! интересно, какой компилятор не возмутится, если вы напишите

Код: Выделить всё

1 << 2;

просто так, без макросов?
а что касается PB1 и т.п. - это де-факто стандартные наименования битов для работы с определенными регистрами микроконтроллеров AVR, которые сам производитель придумал, и было бы странным, если эти "авторские" наименования не поддерживались бы компилятром для AVR. другое дело, где именно (т.е. в каком хидере) они определены - ну так это уже нюансы

Вам надо универсальный дефайн? Так будет лучше:

Код: Выделить всё

#define SETBIT(DEST, BIT) = {DEST |= (1<<BIT);}
#define CLRBIT(DEST,BIT) = {DEST &= ~(1<<BIT);}

вы будете смеяться, но аналоги этих "универсальных" макросов уже реализованы в avr-libc но к стандартам это не имеет никакого отношения! кстати, уважаемый, вы и тут маленько оплошали: знак равенства вообще не нужен, BIT в скобочки взять надо бы в теле макроса, а фигурные скобочки как бы ни к чему...

[IfoR]

интересно, какой компилятор не возмутится, если вы напишите

Код: Выделить всё

1 << 2;

просто так, без макросов?

Будь бы я компилятором, то не возмутился бы ни разу. Просто не рассматривал бы это выражение.

[Мастер Ломастер]

интересно, какой компилятор не возмутится, если вы напишите

Код: Выделить всё

1 << 2;

просто так, без макросов?

Будь бы я компилятором, то не возмутился бы ни разу. Просто не рассматривал бы это выражение.

думаю, что вы не смогли бы обойтись без варнинга

[ut1wpr]

уважаемый, вы и тут маленько оплошали: знак равенства вообще не нужен, BIT в скобочки взять надо бы в теле макроса, а фигурные скобочки как бы ни к чему...

Ну, за "уважаемого" отдельное спасибо.
Я никогда не отрицал возможности оплошания. Не вижу в этом ничего страшного. Просто я высказывал свое мнение по стилю написания программ на Си. Я ж не виноват, что этим кому-то не угодил. Спор бессмысленный, т.к. ни я ни вы свой стиль не измените. Для чего тогда эта псевдо-дискуссия?
Напоследок, насчет "фигурных скобочек". Эта тема давно обсуждалась в других местах. Можно и не писать. Но такая форма иногда позволяет избежать ошибки в виде пропуска точки с запятой в конце оператора при записи нескольких операторов в одной строке или включении этого макроса в другой. Запись без них потребует более строгого отслеживания необходимости завершения оператора. В одном не могу не согласиться, встроенные фишки в компилятор (glibc или другие модули) действительно облегчают написание программ. Но не переносимость.
Ну, а по поводу "заглядывания" в Makefile - стараюсь в них заглядывать как можно реже. Не из-за безграмотности, из-за лени. За свою бытность я их столько понаписывал... Я хоть и пенсионер, но продолжаю работать системным админом, поднимавшим, поверьте, не один десяток Фрюш и прочих никсов, пересобравшим тьму программ, модулей, ядер систем. А там не только Makefile, там и Configure писать приходилось свой, и еще чего. Страшно вспомнить. Так долго люди не живут...
За сим откланиваюсь, извините.