WinAVR, как указать, что ATMEGA8 от внутреннего резонатора
- xelos
- Потрогал лапой паяльник
- Сообщения: 336
- Зарегистрирован: Пн мар 20, 2006 13:05:08
- Контактная информация:
WinAVR, как указать, что ATMEGA8 от внутреннего резонатора
тут столкнулся с проблемой - есть готовая карточка, где ATMega8 от внутреннего RC работает.
пишу маленький тестик в WinAVR. как в Makefile указать, что Atmega от внутреннего резонатора работает? или вручную в коде конфигурировать?
пишу маленький тестик в WinAVR. как в Makefile указать, что Atmega от внутреннего резонатора работает? или вручную в коде конфигурировать?
Я просто верю в то, что рушить догмы - лучший способ не стареть.
- avr123.nm.ru
- Вечно гонимый
- Сообщения: 331
- Зарегистрирован: Пн сен 04, 2006 20:25:28
- Откуда: самоучитель по микроконтроллерам
- Контактная информация:
Re: WinAVR, как указать, что ATMEGA8 от внутреннего резонато
xelos писал(а):тут столкнулся с проблемой - есть готовая карточка, где ATMega8 от внутреннего RC работает.
пишу маленький тестик в WinAVR. как в Makefile указать, что Atmega от внутреннего резонатора работает? или вручную в коде конфигурировать?
а какая разница WinAVR от чего тактируется МК ?
единственно ему может пригодится частота.
- Iron Rat
- Нашел транзистор. Понюхал.
- Сообщения: 156
- Зарегистрирован: Чт сен 14, 2006 10:57:27
- Откуда: Санкт-Петербург
- Контактная информация:
Хм, тогда почему же информация hex-файла и fuse-битов всегда скармливается программаторам по отдельности? При компиляции avr-gcc компилеру передаются данные только о типе кристалла, Да и в формате ISP-программирования для записи байта во flash и во fuse предусмотренны отдельные команды.xelos писал(а):информация о fuse должна содержаться в HEX файле.
- avr123.nm.ru
- Вечно гонимый
- Сообщения: 331
- Зарегистрирован: Пн сен 04, 2006 20:25:28
- Откуда: самоучитель по микроконтроллерам
- Контактная информация:
- xelos
- Потрогал лапой паяльник
- Сообщения: 336
- Зарегистрирован: Пн мар 20, 2006 13:05:08
- Контактная информация:
avr123.nm.ru писал(а):xelos писал(а):информация о fuse должна содержаться в HEX файле.
зачем ?
для промышленных нужд (для серийного прозводства).
Последний раз редактировалось xelos Ср сен 27, 2006 05:58:04, всего редактировалось 1 раз.
Я просто верю в то, что рушить догмы - лучший способ не стареть.
- xelos
- Потрогал лапой паяльник
- Сообщения: 336
- Зарегистрирован: Пн мар 20, 2006 13:05:08
- Контактная информация:
Iron Rat писал(а): Хм, тогда почему же информация hex-файла и fuse-битов всегда скармливается программаторам по отдельности? При компиляции avr-gcc компилеру передаются данные только о типе кристалла, Да и в формате ISP-программирования для записи байта во flash и во fuse предусмотренны отдельные команды.
т.е. avr-gcc не умеет интегрировать в hex информацию о фузах?
Я просто верю в то, что рушить догмы - лучший способ не стареть.
- avr123.nm.ru
- Вечно гонимый
- Сообщения: 331
- Зарегистрирован: Пн сен 04, 2006 20:25:28
- Откуда: самоучитель по микроконтроллерам
- Контактная информация:
- xelos
- Потрогал лапой паяльник
- Сообщения: 336
- Зарегистрирован: Пн мар 20, 2006 13:05:08
- Контактная информация:
Iron Rat писал(а):Не умеет, и незачем ему. Компилятору-компиляторово, программатору-программаторовоavr-gcc генерит бинарник, который будет помещён во флэш-память программы, а шить фьюзы, которые вообще вне адресного пространства - это уже дело программатора.
ЗЫ А кто из компиляторов так умеет?
для пиков PICC от CSS и от HiTech умеют. либо у меня программатор (софт для него) такой умный.... блин, так и придется в формате hex файла ковыряться. откуда-то же мой программатор для пика знает какие фузы были утсановлены.
Я просто верю в то, что рушить догмы - лучший способ не стареть.
- xelos
- Потрогал лапой паяльник
- Сообщения: 336
- Зарегистрирован: Пн мар 20, 2006 13:05:08
- Контактная информация:
ну, вобщем в 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 файла можно фузы в него записать или нет?
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 файла можно фузы в него записать или нет?
Я просто верю в то, что рушить догмы - лучший способ не стареть.