тут столкнулся с проблемой - есть готовая карточка, где ATMega8 от внутреннего RC работает.
пишу маленький тестик в WinAVR. как в Makefile указать, что Atmega от внутреннего резонатора работает? или вручную в коде конфигурировать?

Укажи с какой частотой он работает...

А какой программой прошивается контроллер? Сам я всегда шил понипрогом, в нём все фьюзы и указывал

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

И эта прога не позволяет fuse-биты прошивать?

а какая разница WinAVR от чего тактируется МК ?
единственно ему может пригодится частота.

информация о fuse должна содержаться в HEX файле.

Хм, тогда почему же информация hex-файла и fuse-битов всегда скармливается программаторам по отдельности? При компиляции avr-gcc компилеру передаются данные только о типе кристалла, Да и в формате ISP-программирования для записи байта во flash и во fuse предусмотренны отдельные команды.

зачем ?

для промышленных нужд (для серийного прозводства).

т.е. avr-gcc не умеет интегрировать в hex информацию о фузах?

Не умеет, и незачем ему. Компилятору-компиляторово, программатору-программаторово avr-gcc генерит бинарник, который будет помещён во флэш-память программы, а шить фьюзы, которые вообще вне адресного пространства - это уже дело программатора.
ЗЫ А кто из компиляторов так умеет?

компилятор CVAVR хранит такую инфу в файле проекта и имеет встроеный интерфейс программирования.

А комбайн avr-gcc + uisp/avreal/avrdude хранит эту информацию в Makefile , в котором никто не запрещает упомянуть и ключики программатора, лично так делал - make burn набрал - и готово =)))

для пиков PICC от CSS и от HiTech умеют. либо у меня программатор (софт для него) такой умный.... блин, так и придется в формате hex файла ковыряться. откуда-то же мой программатор для пика знает какие фузы были утсановлены.

ну, вобщем в Microchipовском hex файле есть специальная зона для фузов (формат для 18 пиков, для 16-х похоже):

Each line in the file has this format:
:BBAAAATT[DDDDDDDD]CC
where
: is start of line marker
BB is number of data bytes on line
AAAA is address in bytes
TT is type. 01 means EOF and 04 means extended address
DD is data bytes, number depends on BB value
CC is checksum (2s-complement of number of bytes+address+data)
• Code: This is at the top of the file and may be proceeded by an extended
address line - :020000040000FA, where 04 is the type for extended address
Some compilers include empty code lines (all FF) but others omit these
lines to save space
• EEPROM Data: It is proceeded by the extended address line -
:0200000400F00A. The EEPROM section is optional
• Configuration bytes: These are stored at 300000h and a preceded by the
extended address line - :020000040030CA
The correct format is 8 Fuse bytes and 6 Lock bytes all on the same line but
different compilers and assemblers have different methods of displaying
these bytes. Sometimes lock bytes are omitted if they are not set, sometimes
the data is spread over multiple lines.
The standard format displays unused bits as 1 (e.g. FF for an unused byte)
but on the PIC device they read as 0. The programmer masks unused bits
to 0 so that the Configuration Byte verify will be correct.
• User ID: These are bytes for the user to store data, such as code version
numbers. They are stored at 200000h. Again they are preceded by the
extended address line :020000040020DA
The standard format requires 8 bytes but again some compilers omit unused
bytes.
• End of File: The End Of File marker for all Intel Hex files is :00000001FF

ну, товарищи знатоки-любители, кто скажет у Atmelевского hex файла можно фузы в него записать или нет?