Обсуждаем контроллеры компании Atmel.
Ответить

WinAVR, как указать, что ATMEGA8 от внутреннего резонатора

Пн сен 25, 2006 23:50:24

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

Вт сен 26, 2006 02:01:18

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

Вт сен 26, 2006 08:28:25

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

Вт сен 26, 2006 09:37:29

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

Вт сен 26, 2006 09:49:51

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

Re: WinAVR, как указать, что ATMEGA8 от внутреннего резонато

Вт сен 26, 2006 17:11:00

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


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

Вт сен 26, 2006 19:28:46

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

Вт сен 26, 2006 20:07:45

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

Вт сен 26, 2006 22:10:00

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


зачем ?

Ср сен 27, 2006 05:55:25

avr123.nm.ru писал(а):
xelos писал(а):информация о fuse должна содержаться в HEX файле.


зачем ?


для промышленных нужд (для серийного прозводства).
Последний раз редактировалось xelos Ср сен 27, 2006 05:58:04, всего редактировалось 1 раз.

Ср сен 27, 2006 05:57:14

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

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

Ср сен 27, 2006 07:35:13

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

Ср сен 27, 2006 08:13:25

xelos писал(а):
avr123.nm.ru писал(а):
xelos писал(а):информация о fuse должна содержаться в HEX файле.


зачем ?


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


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

Ср сен 27, 2006 08:16:49

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

Ср сен 27, 2006 23:50:52

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

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

Чт сен 28, 2006 00:11:15

ну, вобщем в 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 файла можно фузы в него записать или нет?
Ответить