WinAVR-20080610, делимся впечатлениями Опции

[haker_fox]

Скачал. Установил.
Приятно удивил результат.
Проект скомпилированный на WinAVR-20070525 занимает 6452 байт. Работает. Проект скомпилированный новым компиляторм занимает 5396 байт. Полностью не работает. Детальный анализ пока не проводил. Серьезных багов не видел.
makefile используется один и тот же, только пути разные подставляются для вызова разных версий утилит.
Самое интересное, что при очистке проекта

Код

make clean

вылетает такая ошибка

Код

0 [main] rm 3292 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
111988 [main] rm 3292 open_stackdumpfile: Dumping stack trace to rm.exe.stackdump
make.exe: *** [clean] Error -1073741819

Компилирует на первый взгляд нормально, но при заливке кода в МК ничего не работает.
Вот...

P.S.
Версия WinAVR-20071221 полет нормальный. Только очистка вылетает с такой же ошибкой.

Свои makefile прикрепляю на всякий случай. Они абсолютно одинаковы, за исключением путей к утилитам пакетов WinAVR.

Прикрепленные файлы

 makefiles.zip ( 5.81 килобайт ) Кол-во скачиваний: 115

 

[733259]

По сравнению с 3.4.6 по прежнему проигрывает.

ЗЫ Залил одну прошивку, все работает.

Сообщение отредактировал 733259 - Jun 24 2008, 07:59

[kurtis]

.....
Самое интересное, что при очистке проекта

Код

make clean

вылетает такая ошибка
.....

У меня та же самая проблема, но только я поставил WinAVR-20071221, а до этого стоял(и продолжает стоять) WinAVR-20070525. Причем в том же месте где лежит makefile создается еще rm.exe.stackdump. Так что видимо проблема не в новом релизе

[haker_fox]

По сравнению с 3.4.6 по прежнему проигрывает.

ЗЫ Залил одну прошивку, все работает.

Хм. В чем же дело у меня? Видимо придется листинги смотреть, но времени пока нет. Проект хоть не горит, но делать надо...

У меня та же самая проблема, но только я поставил WinAVR-20071221, а до этого стоял(и продолжает стоять) WinAVR-20070525. Причем в том же месте где лежит makefile создается еще rm.exe.stackdump. Так что видимо проблема не в новом релизе

Странно,что проблема не устраняется уже полгода. Может быть такая ошибка возникает, если стоят предыдущие версии? Но вроде не должно...

[viakon]

Полностью не работает.

Разобраться бы почему. У меня тоже проекты все на winavr-20070525 писаны, при переходе на новые версии начинаются глюки. Есть подозрение , что дело в оптимизации.

Сообщение отредактировал viakon - Jun 25 2008, 03:54

[haker_fox]

Разобраться бы почему. У меня тоже проекты все на winavr-20070525 писаны, при переходе на новые версии начинаются глюки. Есть подозрение , что дело в оптимизации.

А у Вас с какой версии проблемы начинаются? С 20071221?
А почему оптимизация?

[733259]

ИМХО это уже не раз обсуждалось, в четверке новые методы оптимизации, в том числе - "GCC can now do a form of partial dead code elimination (PDCE) that allows code motion of expressions to the paths where the result of the expression is actually needed. This is not always a win, so the pass has been limited to only consider profitable cases."
Выкидывает код, может где volatile не хватает, может глюки.

ИМХО на четверку для AVR вооще нет смысла переходить, прошивка всегда больше, скорость меньше.
Был бы рад узнать, что не так.

[haker_fox]

ИМХО это уже не раз обсуждалось, в четверке новые методы оптимизации, в том числе - "GCC can now do a form of partial dead code elimination (PDCE) that allows code motion of expressions to the paths where the result of the expression is actually needed. This is not always a win, so the pass has been limited to only consider profitable cases."
Выкидывает код, может где volatile не хватает, может глюки.

ИМХО на четверку для AVR вооще нет смысла переходить, прошивка всегда больше, скорость меньше.
Был бы рад узнать, что не так.

Сейчас проверил, что даже при отключенной оптимизации не работает код.
На данный момент стабильно работают версии WinAVR-20070525, WinAVR-20071221. Последняя генерит код байт на 300 меньше.
Программа, написанная мной, активно использует классы, наследование и т.д. Может быть это является камнем предкновения? Обычный Си код не проверял.

[733259]

Эти 20070525, 20071221 никакой инфы о компилере не несут, avr-gcc -v

[haker_fox]

Код

>c:\winAVR-20070525\bin\avr-gcc --version
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


>c:\winAVR-20071221\bin\avr-gcc --version
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


>c:\winAVR-20080610\bin\avr-gcc --version
avr-gcc (WinAVR 20080610) 4.3.0
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[viakon]

А пользую только С никаких С++, так что дело вряд ли в этом. ставил я апрельскую версию этого года, один проект частично заработал когда на переменные volatile поставил, но полностью это не помогло. Склоняюсь, что дело в оптимизаторе, надо понять что ему не нравится. Разбираться некогда, вернул старую версию.

Сообщение отредактировал viakon - Jun 25 2008, 05:34

[haker_fox]

ИМХО это уже не раз обсуждалось, в четверке новые методы оптимизации

Прошу пролщения, а о какой четверке идет речь? Эти три версии все 4.x.x
Четверки во второй цифре версии вообще нет.
PS
Могу полностью выложить свой проект. Коммерческой тайны пока не представляет, но очень громоздок. Может быть это поможет улучшить компилятор или мои мозги)
Проект заточен для управления движком. Но его достаточно зашить в МК. При сбросе в UART на скорости 19200 выведется строка

Код

[Motor Controller "FREESTYLE-1", v. 0.01]

Еслит компилировать новой версией, то сразу при сбросе выводится вот прмерно такой мусор

Код

’¤2±Щ?a¤a?a
А’¬;±a?aИaРaА"—ю
”Г-A5NE?”
                                          

                                           ”C-
                                              ”‘‘y‘o‘_‘O‘?‘/‘ѕ•’’¶’$/”?”O”
_”o”””Ÿ”Ї”?”i”y”?”П”I·Ю·
a’a”¦П‘?‘y‘i‘?‘Ї‘Ÿ‘‘y‘o‘_‘O‘?‘/‘ѕ•’’¶’$/”?”O”_”o”””Ÿ”Ї”?”i”y”?”П”I·Ю·ˆ‘†
?ˆ”†ˆ‘‡?ˆ”‡ˆ‘?ˆ”
a’a”?П‘?‘y‘i‘?‘Ї‘Ÿ‘‘y‘o‘_‘O‘?‘/‘

[aesok]

А пользую только С никаких С++, так что дело вряд ли в этом. ставил я апрельскую версию этого года, один проект частично заработал когда на переменные volatile поставил, но полностью это не помогло. Склоняюсь, что дело в оптимизаторе, надо понять что ему не нравится. Разбираться некогда, вернул старую версию.

Все сборки WinAVR 2008 года (с avr-gcc 4.3) до майской могут не сохранять используемые регистры в обработчиках прерываний.

Анатолий.

[viakon]

интересно, и уменя проблемы c UART были. Работал c GPRS модемом и все команды ответы выводились на консоль. С новой версией при инициализации с какойто команды начинал валиться мусор. А часть проходила нормально.

Все сборки WinAVR 2008 года (с avr-gcc 4.3) до майской могут не сохранять используемые регистры в обработчиках прерываний.

Анатолий.

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

Сообщение отредактировал viakon - Jun 25 2008, 05:45

[aesok]

Читал про это. Пробовал я и майскую, тоже самое

Пожалуйста покажие проблемный код.

Анатолий.

Сообщение отредактировал aesok - Jun 25 2008, 05:46

[viakon]

попробую выгрызть, но не на этой неделе точно.

[haker_fox]

интересно, и уменя проблемы c UART были. Работал c GPRS модемом и все команды ответы выводились на консоль. С новой версией при инициализации с какойто команды начинал валиться мусор. А часть проходила нормально.
Читал про это. Пробовал я и майскую, тоже самое
Недогадался попробовать оптимизацию выключить.

C UART просто более наглядно наверное + прерывания используются. Если без них, то может проблем и не будет. Хотя кроме юартовских есть несколько других прерываний.
Вот еще что интересно, разительно отличаются секции data по размеру.

Код

20071221
   text       data        bss        dec        hex    filename
   6312          0        152       6464       1940    mcontrol.out

20080610
   text       data        bss        dec        hex    filename
   5918        452        152       6522       197a    mcontrol.out

[733259]

Прошу пролщения, а о какой четверке идет речь? Эти три версии все 4.x.x
Четверки во второй цифре версии вообще нет.

Виноват, не слежу за 200xxxxx.
Обычно сравниваю с 3.4.6 и вижу только недостатки и сырость.
Речь конечно шла о первой цифре.

[kurtis]

Попробовал скомпилировать проект в сабжевой версии WinAVR, но использовал утилиты(rm, cp, mkdir и тд...) из версии 20070525. На железе проект запустился, размер кода возрос, а на ЖКИ вместо обычных букв - абракадабра и размер используемого ОЗУ возрос где-то на 1к При изменении уровня оптимизации абракадабра на ЖКИ меняется. Известно что железо полностью исправно и программа на 99% рабочая!!!В чем проблема незнаю, нету желания разбираться....

[haker_fox]

Видимо все-таки сыроват этот новый WinAVR...
У меня тоже пока нет желания разбираться, да и опыта анализа ассемблерных листингов нет(

[viakon]

Новый проект откомпилил на SUBJ работает. Только он на 100 байт больше оказался чем 20070525

[solosh]

Новый проект откомпилил на SUBJ работает. Только он на 100 байт больше оказался чем 20070525

Попробуйте ключик --param inline-call-cost, если вам важен размер. Например, "--param inline-call-cost=0"

см. http://electronix.ru/forum/index.php?s=&am...st&p=393595

[haker_fox]

Новый проект откомпилил на SUBJ работает. Только он на 100 байт больше оказался чем 20070525

А что изменилось по сравнению с Вашим старым проектом?

[kurtis]

Заметил что компилятор все символьные строки запихнул в ОЗУ, хотя они объявлены как prog_char, и из-за этого и фигня на ЖКИ влезла...в более ранних версиях GCC (4.2.2) такого небыло.

[aesok]

Заметил что компилятор все символьные строки запихнул в ОЗУ, хотя они объявлены как prog_char, и из-за этого и фигня на ЖКИ влезла...в более ранних версиях GCC (4.2.2) такого небыло.

Тестовый пример пожалуйста приведите.

Анатолий.

[Hmm]

Когда-то, некоторое время, вел проекты параллельно в iar и winavr. Когда доверие к winavr утвердилось - остановился. После 20070527 обновляться перестал (некогда, работа однако). Выбрав свободный часок опробовал версию 2008 года (~май). Проект собрался без ошибок и предупреждений, но в изделии не заработал. Причем по железу все боле менее, а с матем. расчетами проблемы. Разбираться не стал (работа однако).

[viakon]

Заметил что компилятор все символьные строки запихнул в ОЗУ

У меня все нормально, лежат во флеш.

Подпрограмма вызываемая 1 раз подставлена инлайн соответственно получилось 2 копии. Из-за этого и длина больше. попробую ключик
--param inline-call-cost

[aesok]

Подпрограмма вызываемая 1 раз подставлена инлайн соответственно получилось 2 копии. Из-за этого и длина больше. попробую ключик
--param inline-call-cost

Лучше объявите эту функцию как static.

Анатолий.

Сообщение отредактировал aesok - Jun 30 2008, 09:21

[Сергей Борщ]

Лучше объявите эту функцию как static.

или --ffunction-sections, -Wl,--gc-sections. Ведь часто исходник кочует из проекта в проект, в каком-то используются одни функции, в каком-то другие, или написали функцию, попользовали ее в другом файле, потом в процессе эволюции необходимость в функции пропала. Если линкер может выкинуть неиспользуемый код - пусть он это делает.

[aesok]

про --gc-sections где-то читал что могут быть проблеммы с отладкой. вечером поищю где про это написано.

Анатолий.

[Сергей Борщ]

про --gc-sections где-то читал что могут быть проблеммы с отладкой. вечером поищю где про это написано.

В некоторых версиях он выдавал warning "могут быть проблемы с отладкой на некоторых targets". Пока на такие проблемы не натыкался (внутрисхемной отладкой не пользуюсь), а уточнений - на каких именно targets и какие именно проблемы могут быть - не попадалось.

[Chak]

Здравствуйте уважаемые форумчане!

У меня проблемка нарисовалась с поддержкой ядер AVR с размером памяти 256к. При обращении к библиотечным функциям с переменным числом параметров (например fprint) компилятор встраивает вызовы к встроенным макросам пролог/эпилог (__prologue_saves__ / __epilogue_restores__ - если быть точным) из библиотеки libgcc.a. Беда в том, что данные для этих макросов, которые готовятся на этапе вызова функций, совершенно не учитывают размера памяти больше чем 128к (64к слов), то есть, инициализируются регистры Z (ZH,ZL), а в макросах используеться инструкция EIJMP, для полноценной работы которой надо еще установить регистр EIND.
Вот и получается, что если библиотечные функции с переменным числов параметров располагаються в адресах выше чем 128к, то вся програма перестает работать.

Решение проблемы - или исправлять libgcc.a (что для меня слишком сложно - я программирующий апаратчик) или заставить линкер располагать эти функции в нижних адресах (а как это сделать я не смог разобраться)...

Может кто подскажет другой вариант?

Я перепробовал все версии WinAVR начиная с 20070122, привожу фрагменты листинга (при компиляции нету ни ошибок ни предупреждений):

Вот одна из библиотечных функций:

00020896 <fprintf_P>:

20896: a0 e0 ldi r26, 0x00 ; 0
20898: b0 e0 ldi r27, 0x00 ; 0
// здесь загружается адрес возврата
// из __prologue_saves__ - это должен быть
// адрес инструкции "ldd r16, Y+8" - 0х0208а2
// а у нас только 0х0451 х 2 = 0х08а2,
// а старшая часть адреса 0х02 нигде не фиксируется!!
2089a: e1 e5 ldi r30, 0x51 ; 81
2089c: f4 e0 ldi r31, 0x04 ; 4
2089e: 0d 94 d9 0c jmp 0x219b2 ; 0x219b2 <__prologue_saves__+0x1c>
208a2: 08 85 ldd r16, Y+8 ; 0x08
208a4: 19 85 ldd r17, Y+9 ; 0x09

а вот злополучная __prologue_saves__ :

00021996 <__prologue_saves__>:
21996: 2f 92 push r2
...
219b4: 1f 93 push r17
219b6: cf 93 push r28
219b8: df 93 push r29
219ba: cd b7 in r28, 0x3d ; 61
219bc: de b7 in r29, 0x3e ; 62
219be: ca 1b sub r28, r26
219c0: db 0b sbc r29, r27
219c2: 0f b6 in r0, 0x3f ; 63
219c4: f8 94 cli
219c6: de bf out 0x3e, r29 ; 62
219c8: 0f be out 0x3f, r0 ; 63
219ca: cd bf out 0x3d, r28 ; 61
219cc: 19 94 eijmp // естественно после этой инструкции мы "улетаем"
// по адресу 0х0008а2 (проверено в отладчике)!

Help!

[aesok]

Help!

Хм... посылали Эрику патч для решения этой проблемы но почему-то он его не
добавил... Ждите следующую версию WinAVR. А пока исключите из проекта функции
которые используют __prologue_saves__ / __epilogue_restores__ и выкинете
ключик -mcall-prologues если вы его использовали.

Можете еще поискать кого нибудь кто сможет вам собрать avr-libc внеся
изменения в файл avr-libc/devtools/gen-avr-lib-tree.sh:

-СFLAGS_SPACE="-mcall-prologues -Os"
+CFLAGS_SPACE="-Os"

Правда устанавливать avr-libc нужно будет ручками... хотя будет достаточно
заменить *.a файлы в директори /avr/lib/avr6/.

Анатолий.

Сообщение отредактировал aesok - Jun 30 2008, 19:06

[Chak]

К Анатолию

Спасибо за информацию о скором выходе нового WinAVR - буду ждать.

А пока выкручусь через "левое ухо" - выкинуть функции использующие пролог/эпилог я пока не готов - ведь им надо или писать или искать замену (слишком много дел), я скомпилировал проект в версии 20070122 с библиотеками libc версии 1.6.1 и ключом -Os. Получилось 128866 байт (в версии 20080610 - 143844). Таким образом проблема решилась - но проект постоянно растет и если патчи не будут учтены в новой версии WinAVR - беда!

А может есть способ заставить линкер собирать сначала библиотечные функциии (из libc.a libm.a libgcc.a) а потом остальные модули?

Сообщение отредактировал Chak - Jul 1 2008, 06:45

[kurtis]

Тестовый пример пожалуйста приведите.

Анатолий.

Есть строка вида (к примеру)

Код

const prog_char glob_menu_str[3][14]=
{
    "Строка 1",
    "Строка 2",
    "Строка 3",
};

После компилирования получаю Project.elf
далее делаю avr.nm -n Project.elf > file.txt
и поиском ищу glob_menu_str....

в версии gcc 4.2.2 и более ранних получаю

Код

00000326 t glob_menu_str

т.е. если судить по символу t то оно легло в секцию с кодом

но когда я использую gcc 4.3.0 то получаю такую вот картину

Код

00800591 d _ZL13glob_menu_str

оно легло во внешнее озу

Далее в коде используется strlen_P, strncpy_P, pgm_read_byte и тд, т.е. думается что мы работаем с переменными расположенными в секции кода...
З.Ы. При использовании GCC 4.2.2 (и более ранних) проект полностью рабочий!!!

[aesok]

Есть строка вида (к примеру)

Код

const prog_char glob_menu_str[3][14]=
{
    "Строка 1",
    "Строка 2",
    "Строка 3",
};

Прочтите [TUT] [C] GCC and the PROGMEM Attribute , PART II - More advanced uses of PROGMEM.

Анатлий.

[kurtis]

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

Может я неправильно задал вопрос....Есть кусок кода

Код

const char MenuItem1[] PROGMEM = "Menu Item 1";
int main()
{
    unsigned int a;
    a = pgm_read_word(&MenuItem1[4]);
    mTest1  = a;
.............
return 0;
}

строку MenuItem1 GCC 4.2.2 ложит во flash, а GCC 4.3.0 ложит в ram!!! Как сделать, чтоб GCC 4.3.0 входящий в состав WinAVR-20080610, клал строку во flash (как это делала более ранняя версия)???

[_Pasha]

строку MenuItem1 GCC 4.2.2 ложит во flash, а GCC 4.3.0 ложит в ram!!! Как сделать, чтоб GCC 4.3.0 входящий в состав WinAVR-20080610, клал строку во flash (как это делала более ранняя версия)???

Или Вы запутались или одно из двух. В приведенном коде у Вас фигурировало константное выражение. Ессно мона его расположить где удобнее оптимайзеру

[kurtis]

Но если пойти по приведенной aesok ссылке, то там некий товарищь, именно таким вот методом

Код

const char MenuItem1[] PROGMEM = "Menu Item 1";

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

[mdmitry]

Но если пойти по приведенной aesok ссылке, то там некий товарищь, именно таким вот методом

Код

const char MenuItem1[] PROGMEM = "Menu Item 1";

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

Полный код примера из описания avr-libc:

Код

#include <avr/pgmspace.h>

const char foo[] PROGMEM = "Foo";
const char bar[] PROGMEM = "Bar";

PGM_P array[2] PROGMEM = {
    foo,
    bar
};

int main (void)
{
    char buf[32];
    PGM_P p;
    int i;

    memcpy_P(&p, &array[i], sizeof(PGM_P));
    strcpy_P(buf, p);
    return 0;
}

Это для WinAVR-20071221. Для новых версий не смотрел.

aesok скорее всего указывал на массив строк

Код

PGM_P array

, а не на определения строк.

[kurtis]

Заменил все prog_char на char имя_строки[] PROGMEM и без изменения кода функций вывода, все вдруг чудесно заработало...
Собсно, а что случилось с prog_char в новых версиях???
почему выражения

Код

const   prog_char   Punkt1[]   =   {"Строка"};

и

Код

const   char   Punkt1[]   PROGMEM   =   {"Строка"};

не равносильны???
Вроде это одно и тоже....

[aesok]

почему выражения

Код

const   prog_char   Punkt1[]   =   {"Строка"};

и

Код

const   char   Punkt1[]   PROGMEM   =   {"Строка"};

не равносильны???
Вроде это одно и тоже....

В первом случае указатель Punkt1 ссылается на const char с атрибутом "progmem", то есть на константную строку расположенную в памяти программ.

Во втором указатель Punkt1 с атрибутом "progmem" ссылается на const char, то есть Punkt1 расположен в памяти программ, а константная строка в RAM.

Для общего развития:

Код

const Pointers

The keyword const for pointers can appear before the type, after the type, or in both places. The following are legal declarations:

const int * ptr1;       /* A pointer to a constant integer:
                             the value pointed to cannot be changed  */
int * const ptr2;       /* A constant pointer to integer:
                             the integer can be changed, but ptr2
                             cannot point to anything else           */
const int * const ptr3; /* A constant pointer to a constant integer:
                             neither the value pointed to
                             nor the pointer itself can be changed   */

Declaring an object to be const means that the this pointer is a pointer to a const object. A const this pointer can by used only with const member functions.

Анатолий.

Сообщение отредактировал aesok - Jul 1 2008, 17:08

[kurtis]

Анатолий, спасибо за ответы, очень помогло!!!=)

Я пытаюсь разобраться, но все-равно есть некоторые вопросы...

есть массив строк

Код

const char glob_menu_str[8][14] PROGMEM =
{
    "1.Строка1",
    "1.Строка1",
    ......
};

далее где-то в коде вызывается функция вывода на ЖКИ (на самом деле это функция копирования значения из памяти в массив данных, который затем уже будет куда-то выводится, не обязательно на ЖКИ)

Код

LCD_abc1(glob_menu_str[glob_counter],1);

ну и собственно сам код этой функции

Код

void LCD_abc1(const char * [b]_str[/b], uint8_t _pos)
{
    uint8_t i = _pos;
    //size_t _strlen;
    uint8_t _strlen;
    uint8_t lcd_temp[32];
    _strlen=strlen_P([b]_str[/b]);
    
    if(_strlen>(32-_pos)) _strlen=32-_pos;

    strncpy_P((char*)(&lcd_temp),[b]_str[/b],_strlen+1);

    while(i<32)
    {
        if(lcd_temp[i-_pos]==0x00)
            break;
        LCD_str[i] = pgm_read_byte(&LCD_simb[lcd_temp[i-_pos]]);
        ++i;
    }
//LCD_str[i] - Временные массив, где хранится текущий "экран"
//LCD_simb - Таблица символов для ЖКИ
}

Вроде все красиво, все в железе работает, но компилятор ругается

warning: only initialized variables can be placed into program memory area

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

Код

const char glob_menu_str[8][14] PROGMEM =

Непонятно почему возникает такое предупреждение, скомпилировал код в более ранних версиях WinAVR - компилятор такого предупреждения не выдает...

[haker_fox]

Во втором указатель Punkt1 с атрибутом "progmem" ссылается на const char, то есть Punkt1 расположен в памяти программ, а константная строка в RAM.
Анатолий.

Как я понял, этот вариант работает в WinAVR2008....
Но ведь таким образом расходуется драгоценная RAM.

[777777]

Поставил сабж. Размер обоих проектов увеличился ровно на 32 байта каждый. Работоспособность не изменилась. Глупые строки вида
lds r24, 0x013A
lds r25, 0x013B
mov r18, r24
mov r19, r25
- остались. В чем отличие и кому нужны 32 байта - так и не понял.

[aesok]

Глупые строки вида
lds r24, 0x013A
lds r25, 0x013B
mov r18, r24
mov r19, r25
- остались.

Исходники компилятора находятся здесь: http://gcc.gnu.org/. Сделать компилятор менее глупым в ваших силах.

В чем отличие и кому нужны 32 байта - так и не понял.

На этом форуме было несколько рекомендаций как заставить avr-gcc 4.3 гененрировать более компактный код, поищите. (--param inline-call-cost, атрибут OS_main...)

Анатолий.

[777777]

Исходники компилятора находятся здесь: http://gcc.gnu.org/. Сделать компилятор менее глупым в ваших силах.

А поточнее можно ссылочку? Может и правда стоит попробовать... Когда-то давно с энтузиазмом дорабатывал компилятор Small-C для процессора 8080, он у меня стал полностью соответствовать стандарту, не понимал только элипсисы (...) Там даже оптимизатор был неслабый. Прада, он был pure-C...

На этом форуме было несколько рекомендаций как заставить avr-gcc 4.3 гененрировать более компактный код, поищите. (--param inline-call-cost, атрибут OS_main...)

param inline-call-cost есть, а OS_main - это что? Надо сказать, документация у WinAVR весьма неудачно сделана, все разбросано по каким-то закоулкам.

[MrYuran]

Надо сказать, документация у WinAVR весьма неудачно сделана, все разбросано по каким-то закоулкам.

А мне наоборот, очень понравилась, хотя бы тем, что она вообще есть

[kaf]

А мне наоборот, очень понравилась, хотя бы тем, что она вообще есть

c WinAvr идет документация по avr-libc, а остальную документацию нужно искать, как сказали выше, на http://gcc.gnu.org и на http://sources.redhat.com/binutils/

Сообщение отредактировал kaf - Jul 18 2008, 12:28

[MrYuran]

Ну уж не знаю, что тогда считать документацией...
Щас специально глянул - в папке WinAVR лежит папочка DOC (32 метра) - это чё - не документация?

ну вы ребята зажрались...

[aesok]

а OS_main - это что?

Код

This patch add "OS_main" and 'OS_task' attributes in GCC .... Function with
"OS_main" and 'OS_task' attributes do not save any "call-saved" registers.

1. "OS_main" attribute  used when there IS guarantee that interrupts are
disabled at that time when function is called. For example "main" function in
avr-libc. If this function has local variables that a prologue will look so:
  in r28, 0x3d; 61
  in r29, 0x3e; 62
  sbiw r28, 0x08; 8
  out 0x3e, r29; 62
  out 0x3d, r28; 61

No save/clear/restore "I" flag.

2. "OS_task" attribute  used when there is NO guarantee that interrupts are
disabled at that time when function is called. For example task functions
multi-threading operating systems. In this case save/clear/restore "I" flag is
need for changing SP register. Prologue (if this function has local variables)
will look so:

  in r28, 0x3d; 61
  in r29, 0x3e; 62
  sbiw r28, 0x08; 8
  in r0, 0x3f; 63
  cli
  out 0x3e, r29; 62
  out 0x3f, r0; 63
  out 0x3d, r28; 61

[Антон Малыгин]

У меня вот такой вопрос. поставил тут сегодня AVR Studio v4.14 build 589 затем установил WinAVR-20071221.
Далее создаю новый проект в AVR GCC на микроконтроллере ATmega16.
Далее нажимаю компиляцию и приехали называется.
При компиляции выдаётся два сообщения

Код

Build started 30.7.2008 at 14:30:11
make: Makefile: No such file or directory
make: *** No rule to make target `Makefile'.  Stop.
Build failed with 2 errors and 0 warnings...

Я как понимаю не может создать Mafefile только вот почему.
Люди добрые помогите обойти проблему.

[mdmitry]

Мало информации: как создаете проект, какими средствами? Если без средств студии, то одни проблемы (рабочая директория и директория запуска make, корректность самого makefile и др). Со студией не работал, она сама что-то плодит (не понравилось), надо разбираться что за файлы наплодила и какие в них настройки.
Возможно, студиа не знает об установленном winavr.
Сначало надо установить winavr, а затем студию. Она сама подцепит winavr.

[MrYuran]

Сначало надо установить winavr, а затем студию. Она сама подцепит winavr.

что-то сомневаюсь. Надёжнее ручками подцепить. Да и собственно, цеплять-то особо нечего. Разве что указать пути к системным хедерам и библиотекам. Скорее всего надо разбираться с настройками проекта в студии. Здесь помочь ничем не могу.

[Антон Малыгин]

Самое интересное что дома попробывал сейчас немного по другому.
Установил в начале WinAVR-20080610 затем устанвил AVR Studio 4.14 build589
и всё заработало...хм интресно...завтра на работе попробую такую же комбинцию.

В общем тут немного поэксперементировал и пришёл к выводу.
Если создаёшь проект то в пути до проекта не ДОЛЖНО БЫТЬ РУССКИХ БУКВ
Например (C:\Documents and Settings\Admin\Мои документы\test)
Иначе Makefail не создастся...Для его создание необходимо исключить русские символы в пути до проекта....

Сообщение отредактировал Антон Малыгин - Jul 30 2008, 18:30

[haker_fox]

Самое интересное что дома попробывал сейчас немного по другому.
Установил в начале WinAVR-20080610 затем устанвил AVR Studio 4.14 build589
и всё заработало...хм интресно...завтра на работе попробую такую же комбинцию.

Наверно студия при установки смотрит, установлен ли WinAVR, и если да - то она готова для работы с ним. В противном случае начинаются проблемы.

В общем тут немного поэксперементировал и пришёл к выводу.
Если создаёшь проект то в пути до проекта не ДОЛЖНО БЫТЬ РУССКИХ БУКВ
Например (C:\Documents and Settings\Admin\Мои документы\test)
Иначе Makefail не создастся...Для его создание необходимо исключить русские символы в пути до проекта....

Это верно. При разработке программ под что угодно, в путях не должно быть русских имен. Я даже имена каталогов и файлов стараюсь не делать длинее 8 символов. Хотя здесь проблем не возникало никогда.

[kaf]

Наверно студия при установки смотрит, установлен ли WinAVR, и если да - то она готова для работы с ним. В противном случае начинаются проблемы.

Если сама не нешла, то достаточно прописать в плагине пути до make и gcc

[_Pasha]

Если создаёшь проект то в пути до проекта не ДОЛЖНО БЫТЬ РУССКИХ БУКВ

Я даже больше скажу : если Вы "случайно" сделали лог. диск командой типа SUBST z: c:\design, и расположили там проект, то вся веселая АВР-студия висла (наверное и сейчас виснет) намертво, и развесить ее можно было только удалив диск z:

[mdmitry]

2 MrYuran и haker_fox
как я понимаю, студия именно смотрит наличие установленного winavr и цепляется к нему. Полностью согласен,что русские буквы и пробелы в именах путь к потенциальным (и не только) несовместимости и ошибкам.
Надежнее конечно руками все прописать, а еще надежнее самому сделать makefile. Я сам студио не использую, не нравится, когда за меня makefile автоматически делается и из кусков к тому же. У меня eclipse+winavr. Для симулирования иногда студия запускается на проект, собранный make.

[LEAS]

Сам я пользуюсь WinAVR+AVRStudio+иногда Proteus. Но уже посматриваю на что-нибудь, где все в одном флаконе. И является именно IDE, а не набором разных программ, написанных разными авторами. Если кто-нибудь бывал на собрании кооператива(или смотрел фильм "Гараж"), то мы понимаем друг-друга. Пусть даже прийдется искать к этому вечно "хрюки". У меня установлен WinAVR-20060421, и не потому что я не в курсе выхода новых версий-просто я привык к "особенностям" этой. Плюс в более новых версиях в Протеусе не видно переменных, расположенных в Static RAM с выводом некорректного расположения адреса этой памяти. На это накладываются чудеса версий AVRStudio(в каком то сочетании WinAVR и AVRStudio попытка отладки Си кода в студии приводила к 100% вылету последней). Новая версия студии прекрасно отлаживает extcoff и виснет на ELF . RM.exe в указанной мною версии 20060421 (и еще какаято утилита) находятся в другой директории, какие-то файлы дублируются. Затолкав в протеус не вижу фрагмента кода, хотя в LSS файле все есть. Все это отнимает время. Человек должен ездить на машине, а не копаться в ней,это только у нас принято. Не скажу, что это совсем плохо, дает знания, но если для написания программы нужно начать с ремонта блока питания компа-это как-то не совсем. Я не против данного продукта, тем более в бесплатности есть большой плюс для написания коммерческих вещей.
Для Антон Малыгин: возможно у вас что-то с путями доступа к файлам проекта или несоответствие названий. Попробуйте создать makefile вручную или с помощью утилиты из комплекта WinAVR. В студии определите Use external makefile, при составлении в ручную не забудьте все файлы проекта с расш "С" указать(вариант, созданный утилитой makefile):
# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c C1820Timer.c WireDriver.c
Удачи.

[haker_fox]

2 MrYuran и haker_fox
как я понимаю, студия именно смотрит наличие установленного winavr и цепляется к нему. Полностью согласен,что русские буквы и пробелы в именах путь к потенциальным (и не только) несовместимости и ошибкам.
Надежнее конечно руками все прописать, а еще надежнее самому сделать makefile. Я сам студио не использую, не нравится, когда за меня makefile автоматически делается и из кусков к тому же. У меня eclipse+winavr. Для симулирования иногда студия запускается на проект, собранный make.

Я тоже студию не использую для своих нужд. Работаю со связкой GCC (для разных арихтектур) + CodeBlocks. Makefile пишу сам по шаблонам. Отладка через консоль и подобные вещи.

[namelos]

Доброе время суток, уважаемые.
Возникла проблема при переходе с WinAVR-20070525 на WinAVR-20080512. При компиляции появляется предупреждение, что атрибут PROGMEM проигнорирован.

../menu.h:17: warning: ignoring attributes applied to 'struct <anonymous>' after definition

на код

Код

typedef struct
{
  //const char* ptr_item;// pointer to item name
  const char item_name[20];// string
  ptr_function select_function; // function pointer at enter/escape
  uint8_t ent_f; // ID menu item to enter
  uint8_t esc_f; // ID menu item to escape
}Menu PROGMEM;

Из-за этого память данных раздувается с 50 байт то 850.
В чем может быть проблема?
Заранее спасибо

[kurtis]

Попробуйте так

Код

typedef struct
{
  //const char* ptr_item;// pointer to item name
  const char item_name[20];// string
  ptr_function select_function; // function pointer at enter/escape
  uint8_t ent_f; // ID menu item to enter
  uint8_t esc_f; // ID menu item to escape
}Menu;

Menu Menu_Item PROGMEM;

[namelos]

kurtis, спасибо большое , помогло.

[Tracer]

Вот нарвался на странность
Прописываю свой тип данных - структуру. Об'являюуказатели на этот тип.

Код

typedef struct
    {
     uint8_t status;                //Status
     uint8_t R_index;                //Read index
     uint8_t W_index;                //Write index
     uint8_t buffer[MAXBUFFER];
    }RINGBUFFER;


volatile RINGBUFFER *Rx,*Tx;

Компилирую (без оптимизации)- все ОК, НО!!!!!!!! В Студии вижу полную "лажу" Мало того, что компилятор разместил экземпляры типа структуры в регистрах Так еще и они (эти два экземпляра) - одно и тоже - т.е при записи в Rx->buffer пишется также и в Tx->buffer - извечный вопрос. ЧТО ДЕЛАТЬ? :о)

PS Может тупо "дать по рукам" компилятору и поставить

Код

volatile RINGBUFFER *Rx,*Tx __attribute__ ((section (".data")));

?

Сообщение отредактировал Tracer - Sep 11 2008, 19:22

[aesok]

Вот нарвался на странность

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

Анатолий.

[Tracer]

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

Анатолий.

Спасибо, ЭТО Я ТУПЛЮ. Действительно объявил указатели и БОЛЬШЕ НИЧЕГО.
Пошел учить матчасть :о)


Все поправил
Объявляю теперь так

Код

volatile RINGBUFFER Rx,Tx;

Все встало на места и находится там где надо

Еще один вопрос
Есть функция

Код

void rb_flush(RINGBUFFER *rb)
{
cli();
rb->R_index=0;
rb->W_index=0;
rb->status=EMPTYBUFFER;
sei();
}

Вызываю ее так

Код

void main(void)
{
...
rb_flush(&Rx);
...
}

Компилятор ругается - но не сильно А всетаки, что ему не нравится?

Код

../rb.c:63: warning: passing argument 1 of 'rb_flush' discards qualifiers from pointer target type
../rb.c:64: warning: passing argument 1 of 'rb_flush' discards qualifiers from pointer target type

[Сергей Борщ]

Компилятор ругается - но не сильно А всетаки, что ему не нравится?

void rb_flush(volatile RINGBUFFER *rb)
Но вы хорошенько подумайте, нужен ли вам volatile для всего буфера? Возможно, достаточно объявить с volatile только индексы и статус?

[Tracer]

void rb_flush(volatile RINGBUFFER *rb)
Но вы хорошенько подумайте, нужен ли вам volatile для всего буфера? Возможно, достаточно объявить с volatile только индексы и статус?

1. БОЛЬШОЕ спасибо.
2. Подумаю, Но без volatile в дизасемблере просто "окровения от GCC". Я такой код хрен бы писал какой он генерит. Но может я еще не достиг нужных высот для понимания Великой идеи :0)

Сообщение отредактировал Tracer - Sep 11 2008, 21:13

[Непомнящий Евген...]

2. Подумаю, Но без volatile в дизасемблере просто "окровения от GCC". Я такой код хрен бы писал какой он генерит. Но может я еще не достиг нужных высот для понимания Великой идеи :0)

Вы хотите сказать, что корректный С-код компилируется в неверную программу? Можете привести полный пример?

[Tracer]

Вы хотите сказать, что корректный С-код компилируется в неверную программу? Можете привести полный пример?

Проверил В этой версии все ОК.

В версии WinAVR 20071221 переменная ms_delay хранилась в регистре при прервании пушалась - изменялась-попалась - т.е ничего не менялось. Вот в этом примере.

Код

#include <stdint.h>
#include <avr/interrupt.h>

uint16_t ms_delay=0;

ISR(TIMER0_OVF_vect)
{
    if(ms_delay)ms_delay--;

}

void my_delay(uint16_t msd)
{
    ms_delay=msd;
    while(ms_delay){}
}

void main(void)
{
    cli();
    TCCR0=0x03;
    TCNT0=0x83;
    TIMSK=0x01;
    sei();
    DDRB =0xff;
    while(1)
               {
     PORTB=0xff;
     my_delay(1000);
     PORTB=0x00;
     my_delay(1000);
    }

При объявлении ее volatile все заработало.
Я с тех пор глобальные переменные - объявляю типа volatile.

Сообщение отредактировал Tracer - Sep 12 2008, 19:04

[aesok]

Я с тех пор глобальные переменные - объявляю типа volatile.

avr-libc-user-manual FAQ#1

Анатолий.

[Tracer]

avr-libc-user-manual FAQ#1

Анатолий.

Да да именно мой случай.
Ну кто же читет Факи в доках, пока не поморочит себе изрядно голову :о))
Теперь то я уже ЭТО знаю.

[timex]

Добрый день!

У меня WinAVR 20080512 + AVR Studio 4.14 выдаёт предупреждение

Код

../main.c:890: warning: passing argument 2 of 'eeprom_write_block' makes pointer from integer without a cast

на последнюю строку в этом примере:

Код

#define EEPROM_SENSOR2_ADR  0x078 // адрес хранения номера датчика
unsigned char current_sensor_code[8];    //текущий код датчика

...

eeprom_busy_wait();
eeprom_write_block (current_sensor_code, EEPROM_SENSOR2_ADR, 8);

(функции - из eeprom.h того же WinAVR'a)

т.е. ему не нравится то, что указатель на адрес записан в явном виде (конктетный адрес в EEPROM), хотя всё работает.

как мне можно записать указатель на адрес ЕЕПРОМ чтобы компилятор не выдавал предупреждение? Можно ли при этом не расходовать RAM для хранения указателя?
Или может существует какой-нибудь ключ для отмены выдачи предупреждения такой записи указателя?

[Непомнящий Евген...]

ну напишите руками приведение к тому типу, который ожидает eeprom_write_block - примерно так:
eeprom_write_block (current_sensor_code, EEPROM_SENSOR2_ADR, (char*)8);

[timex]

ну напишите руками приведение к тому типу, который ожидает eeprom_write_block - примерно так:
eeprom_write_block (current_sensor_code, EEPROM_SENSOR2_ADR, (char*)8);

Не, дык он же на 2-й аргумент функции ругается! Т.е. на EEPROM_SENSOR2_ADR, который выше обозначен как число 0x078.

вот описание этой функции из доки:

void eeprom_write_block (const void * pointer_ram, void * pointer_eeprom, size_t n)

Write a block of n bytes to EEPROM address pointer_eeprom from pointer_ram.

Сообщение отредактировал timex - Sep 25 2008, 11:30

[mdmitry]

Достаточно распространенная ситуация, когда константы подставляются в вызов функции в том числе из макро. Лучше явно делать преобразование типа (как советует Непомнящий Евгений) для спокойной жизни.

У Вас

#define EEPROM_SENSOR2_ADR 0x078 // адрес хранения номера датчика

Наверно, прошло бы без предупреждения, если не было бы ведущего нуля (0x78).

Нет, не прошло бы. У Вас тип

Код

void

, а это требует явного преобразования к типу используемой памяти.

Посмотрел, как сам использовал

Код

uint8_t    eeprom_buf[RECORD_SIZE];        /* Буфер блока данных */

int8_t eeprom_data_write(const int16_t address)
/* Запись блока данных в EEPROM */
{
    int16_t tmp;
    
    if( (address > EEPMIN_ADDR) && (address < (EEPMAX_ADDR-RECORD_SIZE)))
    {
        
        tmp = address;
        eeprom_busy_wait();
        eeprom_write_block(eeprom_buf, (uint16_t*)tmp, RECORD_SIZE);
        
        return EXIT_SUCCESS;
    }
    
    return EXIT_FAILUREN;    /* Bad address */
}

Явное преобразование типа, а заодно и контроль допустимых адресов записи

[timex]

mdmitry, да, спасиб.
при такой записи строки

Код

eeprom_write_block (current_sensor_code, (unsigned int*) EEPROM_SENSOR2_ADR, 8);

варнинг не выдаётся.


Вдогонку!

Обратил внимание, что в окне сообщений компилятора при Rebuld All выдаётся следующее (помечено "!!!!!!!!>"):

Код

Build started 25.9.2008 at 17:14:51
avr-gcc.exe -I"C:\AVRlib"  -mmcu=atmega16 -Wall -gdwarf-2 -std=gnu99 -fgnu89-inline                 -O2 -fsigned-char -MD -MP -MT main.o -MF dep/main.o.d  -c  ../main.c
!!!!!!!!> C:\WINDOWS\Temp/ccFQajf5.s: Assembler messages:
!!!!!!!!> C:\WINDOWS\Temp/ccFQajf5.s:2433: Warning: expression dangerous with linker stubs
!!!!!!!!> C:\WINDOWS\Temp/ccFQajf5.s:2434: Warning: expression dangerous with linker stubs
avr-gcc.exe -mmcu=atmega16  main.o     -o sensor_ibutton.elf
avr-objcopy -O ihex -R .eeprom  sensor_ibutton.elf sensor_ibutton.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex sensor_ibutton.elf sensor_ibutton.eep || exit 0

AVR Memory Usage
----------------
Device: atmega16

Program:    4506 bytes (27.5% Full)
(.text + .data + .bootloader)
Data:        158 bytes (15.4% Full)
(.data + .bss + .noinit)

Build succeeded with 0 Warnings...

файлов таких в c:\windows\temp нету...
где копать?

Сообщение отредактировал timex - Sep 25 2008, 13:14

[_Pasha]

1. по поводу Linker Stubs - это глюки. Здесь уже была тема. Можно (по крайней мере, в предыдущей winavr 2007) не обращать внимания.
2. Вернемся к

Код

eeprom_write_block (current_sensor_code, (unsigned int*) EEPROM_SENSOR2_ADR, 8);

Вроде как правильно, но Вы уверены, что Вам нужен именно (unsigned int*) ? Имхо, бардака в голове только прибавилось.

[mdmitry]

1. по поводу Linker Stubs - это глюки. Здесь уже была тема. Можно (по крайней мере, в предыдущей winavr 2007) не обращать внимания.
2. Вернемся к

Код

eeprom_write_block (current_sensor_code, (unsigned int*) EEPROM_SENSOR2_ADR, 8);

Вроде как правильно, но Вы уверены, что Вам нужен именно (unsigned int*) ? Имхо, бардака в голове только прибавилось.

1. Это временные файлы, они удаляются после выполнения необходимых действий.
2. Полная аналогия относительно доступа к областям памяти по отношению к функциям типа

Код

memmove, memcpy

и другим (IMHO). Нужен ведь адрес ячейки памяти, а их больше чем 256.

[timex]

1. по поводу Linker Stubs - это глюки. Здесь уже была тема. Можно (по крайней мере, в предыдущей winavr 2007) не обращать внимания.

Сейчас проверил - появляется только при оптимизации -O1, -O2, -O3. При -Оs и -O0 такого нету... (WinAVR-20071221).

Обновил до 20080512 - глюк перестал проявлятся!

2. Вернемся к

Код

eeprom_write_block (current_sensor_code, (unsigned int*) EEPROM_SENSOR2_ADR, 8);

Вроде как правильно, но Вы уверены, что Вам нужен именно (unsigned int*) ? Имхо, бардака в голове только прибавилось.

Упс, от созерцания прекращения выдачи варнингов незаметил .
Переправил на "(unsigned char*)". Но в данном случае, думается, между int и char нет разницы, т.к. в описании функции стоит "void"...?

Сообщение отредактировал timex - Sep 25 2008, 13:57

[Сергей Борщ]

Переправил на "(unsigned char*)". Но в данном случае, думается, между int и char нет разницы, т.к. в описании функции стоит "void"...?

Если вы хотите писать понятно, то приведите к указателю на тот тип, данные которого записываете, т.е. к тому типу, на который у вас указывает current_sensor_code. Если хотите чтобы было "просто правильно", то приведите к тому типу, который ожидает функция, т.е. к void *. Если хотите через полгода-год, смотря в этот кусок кода, мучительно думать "а какого черта здесь приводится именно к unsigned char *, а не к unsigned int *?" - оставьте так, как есть.

P.S. параметр функции объявлен как void *, потому что к void * неявно приводится любой указатель.

[mdmitry]

Если вы хотите писать понятно, то приведите к указателю на тот тип, данные которого записываете, т.е. к тому типу, на который у вас указывает current_sensor_code. Если хотите чтобы было "просто правильно", то приведите к тому типу, который ожидает функция, т.е. к void *. Если хотите через полгода-год, смотря в этот кусок кода, мучительно думать "а какого черта здесь приводится именно к unsigned char *, а не к unsigned int *?" - оставьте так, как есть.

P.S. параметр функции объявлен как void *, потому что к void * неявно приводится любой указатель.

Сергей Борщ, в функциях типа

Код

memmove

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

[Сергей Борщ]

в функциях типа

Код

memmove

и др. все же делается приведение к тому типу данных, который используется.

Здесь какое-то недопонимание. Внутри функции memmove, memset и т.п. переданный указатель типа void * действительно приводится к тому типу, единицами которого осуществляется копирование, стирание (чаще всего к байту). Но сам параметр функции имеет тип void * чтобы при вызове этой функции можно было использовать любой указатель, не делая явного приведения:

Код

int var1;
unsigned char var2;
struct struct_t
{
    unsigned int a;
    unsigned long b;
} var3;

void Test()
{
    memset(&var1, 0, sizeof(var1));
    memset(&var2, 0, sizeof(var2));
    memset(&var3, 0, sizeof(var3));
}

[mdmitry]

Здесь какое-то недопонимание. Внутри функции memmove, memset и т.п. переданный указатель типа void * действительно приводится к тому типу, единицами которого осуществляется копирование, стирание (чаще всего к байту). Но сам параметр функции имеет тип void * чтобы при вызове этой функции можно было использовать любой указатель, не делая явного приведения

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

[vik0]

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

Нет. С точки зрения контроля типов void* - худшее что можно придумать.

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

Нет. С точки зрения компилятора (точнее ассемблера) не имеет никакой разницы, указатель на какой тип используется.

[mdmitry]

Нет. С точки зрения контроля типов void* - худшее что можно придумать.

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

[_Pasha]

Хочу спросить:
почему в хедерах контроллеров не прижилось описание SFR через структуры с битовыми полями?
aesok - Вы ближе всего к идеологии...

[aesok]

Хочу спросить:
почему в хедерах контроллеров не прижилось описание SFR через структуры с битовыми полями?
aesok - Вы ближе всего к идеологии...

Наверное по той-же самой причине по которой выкинули sbi и cbi, с помощью
таких структур можно красиво изменять один бит, но если вам нужно сразу
установить несколько бит в регистре, то код получается избыточным (нужно
последовательно устанавливать каждый бит).

Анатолий.

[demiurg_spb]

К слову, из рассылки ImageCraft от 26 сентября 2008г:

With XMega, Atmel introduce new syntax to access the io registers, using
structs and unions. See AppNote AVR1000 for details.

ImageCraft io header files support new syntax fully, only usage of multi-byte
struct members is different, because compiler does not support C++ anonymous
unions.

[Tracer]

К слову, из рассылки ImageCraft от 26 сентября 2008г:

With XMega, Atmel introduce new syntax to access the io registers, using
structs and unions. See AppNote AVR1000 for details.

ImageCraft io header files support new syntax fully, only usage of multi-byte
struct members is different, because compiler does not support C++ anonymous
unions.

Та в ИКС Мегах, АТМЕЛы сделали виртуальные регистры - специально для битовых операций.
Мне вообще импонирует,что АВР делаются под синтаксис С.

Сообщение отредактировал Tracer - Oct 3 2008, 20:14