Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: WinAVR-20080610
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Страницы: 1, 2
aesok
Цитата(777777 @ Jul 18 2008, 15:56) *
а 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
Цитата(mdmitry @ Jul 30 2008, 17:26) *
Сначало надо установить winavr, а затем студию. Она сама подцепит winavr.

что-то сомневаюсь. Надёжнее ручками подцепить. Да и собственно, цеплять-то особо нечего. Разве что указать пути к системным хедерам и библиотекам. Скорее всего надо разбираться с настройками проекта в студии. Здесь помочь ничем не могу.
Антон Малыгин
Самое интересное что дома попробывал сейчас немного по другому.
Установил в начале WinAVR-20080610 затем устанвил AVR Studio 4.14 build589
и всё заработало...хм интресно...завтра на работе попробую такую же комбинцию. smile.gif

В общем тут немного поэксперементировал и пришёл к выводу.
Если создаёшь проект то в пути до проекта не ДОЛЖНО БЫТЬ РУССКИХ БУКВ
Например (C:\Documents and Settings\Admin\Мои документы\test)
Иначе Makefail не создастся...Для его создание необходимо исключить русские символы в пути до проекта....
haker_fox
Цитата(Антон Малыгин @ Jul 31 2008, 03:16) *
Самое интересное что дома попробывал сейчас немного по другому.
Установил в начале WinAVR-20080610 затем устанвил AVR Studio 4.14 build589
и всё заработало...хм интресно...завтра на работе попробую такую же комбинцию. smile.gif

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

Это верно. При разработке программ под что угодно, в путях не должно быть русских имен. Я даже имена каталогов и файлов стараюсь не делать длинее 8 символов. Хотя здесь проблем не возникало никогда.
kaf
Цитата(haker_fox @ Jul 31 2008, 09:48) *
Наверно студия при установки смотрит, установлен ли WinAVR, и если да - то она готова для работы с ним. В противном случае начинаются проблемы.

Если сама не нешла, то достаточно прописать в плагине пути до make и gcc
_Pasha
Цитата(Антон Малыгин @ Jul 30 2008, 21:16) *
Если создаёшь проект то в пути до проекта не ДОЛЖНО БЫТЬ РУССКИХ БУКВ


Я даже больше скажу : если Вы "случайно" сделали лог. диск командой типа 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
Цитата(mdmitry @ Jul 31 2008, 20:26) *
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")));


?
aesok
Цитата(Tracer @ Sep 11 2008, 23:04) *
Вот нарвался на странность


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

Анатолий.
Tracer
Цитата(aesok @ Sep 11 2008, 22:35) *
Приведите больше кода, как вы работаете с указателемя, как выделяете память под структуры.

Анатолий.


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


Все поправил
Объявляю теперь так
Код
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
Сергей Борщ
Цитата(Tracer @ Sep 11 2008, 22:58) *
Компилятор ругается - но не сильно А всетаки, что ему не нравится?
void rb_flush(volatile RINGBUFFER *rb)
Но вы хорошенько подумайте, нужен ли вам volatile для всего буфера? Возможно, достаточно объявить с volatile только индексы и статус?
Tracer
Цитата(Сергей Борщ @ Sep 11 2008, 23:50) *
void rb_flush(volatile RINGBUFFER *rb)
Но вы хорошенько подумайте, нужен ли вам volatile для всего буфера? Возможно, достаточно объявить с volatile только индексы и статус?

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

Вы хотите сказать, что корректный С-код компилируется в неверную программу? Можете привести полный пример?
Tracer
Цитата(Непомнящий Евгений @ Sep 12 2008, 07:13) *
Вы хотите сказать, что корректный С-код компилируется в неверную программу? Можете привести полный пример?

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

В версии 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.
aesok
Цитата(Tracer @ Sep 12 2008, 23:01) *
Я с тех пор глобальные переменные - объявляю типа volatile.


avr-libc-user-manual FAQ#1

Анатолий.
Tracer
Цитата(aesok @ Sep 12 2008, 22:08) *
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
Цитата(Непомнящий Евгений @ Sep 25 2008, 14:56) *
ну напишите руками приведение к тому типу, который ожидает 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.
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 нету...
где копать?
_Pasha
Цитата(timex @ Sep 25 2008, 16:16) *

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

Вроде как правильно, но Вы уверены, что Вам нужен именно (unsigned int*) ? smile.gif Имхо, бардака в голове только прибавилось.
mdmitry
Цитата(_Pasha @ Sep 25 2008, 17:23) *
1. по поводу Linker Stubs - это глюки. Здесь уже была тема. Можно (по крайней мере, в предыдущей winavr 2007) не обращать внимания.
2. Вернемся к
Код
eeprom_write_block (current_sensor_code, (unsigned int*) EEPROM_SENSOR2_ADR, 8);

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

1. Это временные файлы, они удаляются после выполнения необходимых действий.
2. Полная аналогия относительно доступа к областям памяти по отношению к функциям типа
Код
memmove, memcpy
и другим (IMHO). Нужен ведь адрес ячейки памяти, а их больше чем 256.
timex
Цитата(_Pasha @ Sep 25 2008, 17:23) *
1. по поводу Linker Stubs - это глюки. Здесь уже была тема. Можно (по крайней мере, в предыдущей winavr 2007) не обращать внимания.


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

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

Цитата(_Pasha @ Sep 25 2008, 17:23) *
2. Вернемся к
Код
eeprom_write_block (current_sensor_code, (unsigned int*) EEPROM_SENSOR2_ADR, 8);

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


Упс, от созерцания прекращения выдачи варнингов незаметил smile.gif.
Переправил на "(unsigned char*)". Но в данном случае, думается, между int и char нет разницы, т.к. в описании функции стоит "void"...?
Сергей Борщ
Цитата(timex @ Sep 25 2008, 16:44) *
Переправил на "(unsigned char*)". Но в данном случае, думается, между int и char нет разницы, т.к. в описании функции стоит "void"...?
Если вы хотите писать понятно, то приведите к указателю на тот тип, данные которого записываете, т.е. к тому типу, на который у вас указывает current_sensor_code. Если хотите чтобы было "просто правильно", то приведите к тому типу, который ожидает функция, т.е. к void *. Если хотите через полгода-год, смотря в этот кусок кода, мучительно думать "а какого черта здесь приводится именно к unsigned char *, а не к unsigned int *?" - оставьте так, как есть.

P.S. параметр функции объявлен как void *, потому что к void * неявно приводится любой указатель.
mdmitry
Цитата(Сергей Борщ @ Sep 25 2008, 18:19) *
Если вы хотите писать понятно, то приведите к указателю на тот тип, данные которого записываете, т.е. к тому типу, на который у вас указывает current_sensor_code. Если хотите чтобы было "просто правильно", то приведите к тому типу, который ожидает функция, т.е. к void *. Если хотите через полгода-год, смотря в этот кусок кода, мучительно думать "а какого черта здесь приводится именно к unsigned char *, а не к unsigned int *?" - оставьте так, как есть.

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

Сергей Борщ, в функциях типа
Код
memmove
и др. все же делается приведение к тому типу данных, который используется. Согласен, мой пример требует корректировки с точки зрения соблюдения всех стандартов.
Сергей Борщ
Цитата(mdmitry @ Sep 25 2008, 18:02) *
в функциях типа
Код
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
Цитата(Сергей Борщ @ Sep 25 2008, 22:17) *
Здесь какое-то недопонимание. Внутри функции memmove, memset и т.п. переданный указатель типа void * действительно приводится к тому типу, единицами которого осуществляется копирование, стирание (чаще всего к байту). Но сам параметр функции имеет тип void * чтобы при вызове этой функции можно было использовать любой указатель, не делая явного приведения

Насколько я понимаю, в прототипе указатели на источник и приемник имеют тип void* с целью дать программисту возможность явного приведения типа указателей как для удобства (работа с конкретными типами данных), так и для контроля типов самим компилятором. Предполагаю, что приведение типа может улучшить как скорость работы функции, так и эффективность использования памяти (дырки и выравнивание). Исходный код этих функций я не смотрел (неверно, неплохо и ознакомиться smile.gif ).
vik0
Цитата(mdmitry @ Sep 25 2008, 22:46) *
Насколько я понимаю, в прототипе указатели на источник и приемник имеют тип void* с целью дать программисту возможность явного приведения типа указателей как для удобства (работа с конкретными типами данных), так и для контроля типов самим компилятором.

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

Нет. С точки зрения компилятора (точнее ассемблера) не имеет никакой разницы, указатель на какой тип используется.
mdmitry
Цитата(vik0 @ Sep 26 2008, 00:13) *
Нет. С точки зрения контроля типов void* - худшее что можно придумать.

Согласен и не утверждал обратное.
Типы, указанные программистом, лучше контролируются.
_Pasha
Хочу спросить:
почему в хедерах контроллеров не прижилось описание SFR через структуры с битовыми полями?
aesok - Вы ближе всего к идеологии... smile.gif
aesok
Цитата(_Pasha @ Sep 30 2008, 11:06) *
Хочу спросить:
почему в хедерах контроллеров не прижилось описание SFR через структуры с битовыми полями?
aesok - Вы ближе всего к идеологии... smile.gif


Наверное по той-же самой причине по которой выкинули 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
Цитата(demiurg_spb @ Oct 1 2008, 10:40) *
К слову, из рассылки 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.


Та в ИКС Мегах, АТМЕЛы сделали виртуальные регистры - специально для битовых операций.
Мне вообще импонирует,что АВР делаются под синтаксис С.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.