Тактовая частота МК Atmega8

[NStorm]

никакого отношения к регистрам МК она не имеет.

К фьюзам вы имели в виду видимо.

Частота МК задаётся фьюзом или регистром прескалера главной тактовой частоты

У атмеги8 нет регистров таких. Только фьюзами CKSEL3..0 задается.

Добавлено after 3 minutes 40 seconds:
Ну точнее через OSCCAL можно подкрутить в пределах +- 50%, но это не о том, это калибровка.

Вообще я бы посоветовал ТС забить на попытки работать с мегой8 на 8МГц от внутреннего RC. Он откалиброван для работы на 1 МГц. Если ставить его на 8МГц, то соб-но по ДШ требуется еще пользовательская калбировка через соб-но OSCCAL регистр. А если ТС разобраться не может чем фьюз от дефайна отличается... то это будет mission impossible. Лучше поставить внешний кристалл и запустить от него тогда уж.

[roman.com]

Просто там внутри есть макросы препроцессора, которые при расчетах кол-ва тактов на единицу времени, опираются на константу F_CPU. IDE...

Просто я всё упростил... для лучшего понимания... ))

макросы

.MACRO __DELAY_USB
LDI R24,LOW(@0)
__DELAY_USB_LOOP:
DEC R24
BRNE __DELAY_USB_LOOP
.ENDM

.MACRO __DELAY_USW
LDI R24,LOW(@0)
LDI R25,HIGH(@0)
__DELAY_USW_LOOP:
SBIW R24,1
BRNE __DELAY_USW_LOOP
.ENDM
...


А для лучшего понимания лучше писать на Ассемблере ))

[parovoZZ]

У атмеги8 нет регистров таких. Только фьюзами CKSEL3..0 задается.

Ну точнее через OSCCAL можно подкрутить в пределах +- 50%

Я кручу. Есть ограничения. Но когда очень хочется, то можно.

[NStorm]

Ну атмега8 - это ж "динозавр". Там всё по-старинке еще, через одно место:

The ATmega8 stores four different calibration values for the internal RC Oscillator. These bytes
resides in the signature row High byte of the addresses 0x0000, 0x0001, 0x0002, and 0x0003
for 1MHz, 2MHz, 4MHz, and 8Mhz respectively. During Reset, the 1MHz value is automatically
loaded into the OSCCAL Register. If other frequencies are used, the calibration value has to be
loaded manually, see “Oscillator Calibration Register – OSCCAL” on page 31 for details.
...
During Reset, the 1MHz calibration value which is located in the signature row High byte (address 0x00) is automatically loaded into the OSCCAL Register. If the internal RC is used at other frequencies, the calibration values must be loaded manually. This can be done by first reading the signature row by a programmer, and then store the calibration values in the Flash or EEPROM. Then the value can be read by software and loaded into the OSCCAL Register.

Про "кручения" именно на меге8 есть такая ремарка:

The calibrated Oscillator is used to time EEPROM and Flash access. If EEPROM or Flash is written, do not calibrate to more than 10% above the nominal frequency. Otherwise, the EEPROM or Flash write may fail. Note that the Oscillator is intended for calibration to 1.0MHz, 2.0MHz, 4.0MHz, or 8.0MHz. Tuning to other values is not guaranteed, as indicated in Table 11.

[shrus43]

Подниму тему,глупый может вопрос,но возник в моем котелке любителя,прямо в исходном коде нельзя установить эти фьюз биты резонирования и будет ли работать?обязательно использовать для этого программу прошивалку с установкой птичек?Код вижен например при созданий проекта предлагает код:пример на атмеге328 8мгц

static void Quartz_resonator(void)
{
#pragma optsize-
CLKPR=(1<<CLKPCE);
CLKPR=(0<<CLKPCE) | (0<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS1) | (0<<CLKPS0);
#ifdef _OPTIMIZE_SIZE_
#pragma optsize+
#endif

}

Добавлено after 10 minutes 19 seconds:
И что будет с битами CLKPR,если убрать прагму с оптимизацией кода?

[parovoZZ]

не понял, что такое фьюз биты резонирования?

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

[shrus43]

parovoZZ писал(а):

не понял, что такое фьюз биты резонирования?

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

Не правильно выразился ввиду своей не грамотности в этом деле,сам бы хотел понять и выставлять частоту тактирования по своему ладу прямо в коде,без генератора содвижена,с этим фокусом все как надо работает вроде,в AVRDUDE_PROG прошиваю мк по дефолту под 1мгц,а работает в железе как 8мгц с кварцем на 8мгц благодаря этой вставке в коде,зачем сказывается заморачиваться с фьюз галочками в прошивалке?или что то я не догоняю)

[parovoZZ]

имеется ввиду ckdiv8? Это для случая безопасного применения МК. Просто ckdiv8 выставляет биты в CLKPR сразу после ресета, а программист там, где ему надо. Вот и вся разница.

[Jack_A]

CLKPR=(0<<CLKPCE) | (0<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS1) | (0<<CLKPS0);

Ну сколько можно двигать нули, уже 100500 раз об этом. Почему просто не написать

Код:

   CLKPR=0  ;

https://radiokot.ru/forum/viewtopic.php ... 9#p4059139

[ST7FOX]

Особенно смешно это выглядит на фоне прагм и условий компиляции...

Добавлено after 4 minutes 34 seconds:

shrus43 писал(а):

И что будет с битами CLKPR,если убрать прагму с оптимизацией кода?

скорее всего, останется лишь CLKPR = 0; так как по идее первое присваивание перед вторым бессмысленно (с точки зрения мифического компилятора), но, учитывая, что это всё-таки компилятор для какого-то мк, то может остаться так:
CLKPR = 0x80;
CLKPR = 0x00;

Вообще, Вы можете сами уметь отвечать себе на такой вопрос, просто глянув листинг ассемблера после компиляции.

[slav0n]

Ну сколько можно двигать нули, уже 100500 раз об этом. Почему просто не написать

в данном случае это пишется просто для наглядности конфигурации.
я тоже иногда так делаю, очень удобно

Код:

TCCR2A = (1<<WGM21)|(0<<WGM20)| (0<<COM2A1)|(1<<COM2A0);//CTC
TCCR2B = (0<<CS22)|(1<<CS21)|(1<<CS20);// /32

[shrus43]

ST7FOX писал(а):

Особенно смешно это выглядит на фоне прагм и условий компиляции...

Добавлено after 4 minutes 34 seconds:

shrus43 писал(а):

И что будет с битами CLKPR,если убрать прагму с оптимизацией кода?

Вообще, Вы можете сами уметь отвечать себе на такой вопрос, просто глянув листинг ассемблера после компиляции.

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

Добавлено after 3 minutes 4 seconds:

Jack_A писал(а):

CLKPR=(0<<CLKPCE) | (0<<CLKPS3) | (0<<CLKPS2) | (0<<CLKPS1) | (0<<CLKPS0);

Ну сколько можно двигать нули, уже 100500 раз об этом. Почему просто не написать

Код:

   CLKPR=0  ;

https://radiokot.ru/forum/viewtopic.php ... 9#p4059139

этож не я)))это кодвижен генерит

[slav0n]

кстати
https://chipenable.ru/index.php/program ... rammy.html

Добавлено after 19 minutes 32 seconds:
https://www.nongnu.org/avr-libc/user-ma ... _fuse.html

[ST7FOX]

shrus43 писал(а):

этож не я)))это кодвижен генерит

не знаю, что это, но в любом случае, выбросьте скорее.

[slav0n]

ничего выбрасывать не надо, даже плохих советчиков

[ST7FOX]

Всё, что делает 0 << х | - надо выбросить. Тех, кто считает, что не надо - тоже.
По одной простой причине - это идиотизм, и не стоит его плодить, иначе в будущем поля начнут поливать газировкой.

[slav0n]

ключевые слова плохого советчика:

не знаю, что это, но в любом случае

[Dimon456]

иначе в будущем поля начнут поливать газировкой.

А что не так в этой записи?Если я выброшу (0<<ADIF), это повлияет на результат? А может (0<<ADATE) выкинуть, результат изменится?

Ни как не пойму, в чем проблема?

У CVAVR прекрасный генератор начального кода.

[ST7FOX]

Да и пофиг. Если бессмысленность прекрасна - пусть так и будет.
Вчера разбирал кривое устройство - спроектировано примерно с применением сдвига нуля. Гляжу - а внутри атмега. И совершенно не удивился.
И лично у меня такая статистика набирается: устройство хорошее - значит, скорее всего там не атмел. Устройство глючное - скорее всего, там атмел.
Потому что безграмотно и бессмысленно. Но прекрасно...

[slav0n]

бессмысленная статистика