В даташите на Tiny13 написано, что в сигнатуре имеются два калибровочных байта: один для внутреннего генератора 9.6 МГц,
второй для внутреннего генератора 4.8МГц. Причем первый из них грузится аппаратно при старте (если выбран 9.6), второй
(для частоты 4.8)нужно грузить программно. По особенностям работы устройства требуется генератор на 4.8Мгц,однако программатор ChipProg2 показывает только один калибровочный байт и непонятно для какой частоты.
М.б. генератор только один. а вторая частота получается делением на 2 и потому одно калибровочное число?
Непонятно..Как поступить?
Полная версия этой страницы: ATtiny13 калибровочные байты RC генератора
Цитата(vika1 @ Jul 14 2009, 07:46) 
Непонятно..Как поступить?
Непонятно... Что Вы собственно хотите? И в DS написано, что калибровочных байтов - один. И он - не меняется. Желаете произвести собственную калибровку. У Atmel'а есть соответствующая AN. Пользовательское значение калибровочного байта заносится в регистр OSCCAL программым путём (т.е. из приложения).
Цитата(Палыч @ Jul 14 2009, 08:54)
Непонятно... Что Вы собственно хотите?
И в DS написано, что калибровочных байтов - один. И он - не меняется. Желаете произвести собственную калибровку. У Atmel'а есть соответствующая AN. Пользовательское значение калибровочного байта заносится в регистр OSCCAL программым путём (т.е. из приложения).
И в DS написано, что калибровочных байтов - один. И он - не меняется. Желаете произвести собственную калибровку. У Atmel'а есть соответствующая AN. Пользовательское значение калибровочного байта заносится в регистр OSCCAL программым путём (т.е. из приложения).
А вот и нет. В даташите (для ATtiny13A)стр.105 написано, что в наличии два калибровочных байта:
17.3 Calibration Bytes
The signature area of the ATtiny13A contains two bytes of calibration data for the internal oscil-
lator. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6
MHz operation. During reset, this byte is automatically written into the OSCCAL register to
ensure correct frequency of the oscillator.
Собственная калибровка не требуется, т.к. точность на фабрике устраивает.
Мой вопрос так и не проясняется.
В продолжение (из даташита)
The calibration data for 4.8 MHz operation is located in
the high byte at address 0x01 of the signature area.
Цитата(vika1 @ Jul 14 2009, 09:30)
А вот и нет. В даташите (для ATtiny13A)стр.105 написано, что в наличии два калибровочных байта
Ну, наверное, у меня устаревший DS. В моём - той же стр.105 "Signature area of the ATtiny13 has one byte of calibration data for the internal RC Oscillator. This byte resides in the high byte of address 0x000." Ну, стало, наверное, два... Ваш программатор, наверное, об изменениях - не знает... Если Вас устраивают заводские установки - то, вопрос, собственно, в чем заключается? Попадут ли значения для обоих частот в соответствующий регистр? Скорее всего - да. Иначе, зачем было городить "огород" со вторым калибровочным байтом. Это ведь легко проверяется на железе: регистр OSCCAL - программно доступен; напишите тестовую программу: считал, да и выдал наружу.
Цитата(vika1 @ Jul 14 2009, 10:30)
В продолжение (из даташита)
The calibration data for 4.8 MHz operation is located in
the high byte at address 0x01 of the signature area.
The calibration data for 4.8 MHz operation is located in
the high byte at address 0x01 of the signature area.
Не понятно почему здесь написано адрес 0x01 в signature area. Логично предположить что здесь имеентся в виду calibration area. В описании команды "Read Calibration Byte" в таблици 17-9 даташита на ATtiny13 в 3 байте команды младший бит являеться адресом и эта команда позволяет прочесть 2 калибровочных байта.
Попробуйте взять другий програматор который может читать все калибровочные байты, а не только первый. Когдато давно я посылал патч для avrdude для чтения любого количества калибровочных байтов, попробуйте воспользоваться им.
Я не вижу в этом контроллере возможности прочесть из програмы калибровочные байты, так что придёться читать его програматором и копировать в какой нибудь определеннй адрес FLASH или EEPROM и затем уже оттуда копировать в OSCCAL.
Анатолий.
Цитата(vika1 @ Jul 14 2009, 09:30)
А вот и нет. В даташите (для ATtiny13A)стр.105 написано, что в наличии два калибровочных байта:
17.3 Calibration Bytes
The signature area of the ATtiny13A contains two bytes of calibration data for the internal oscil-
lator. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6
MHz operation. During reset, this byte is automatically written into the OSCCAL register to
ensure correct frequency of the oscillator.
17.3 Calibration Bytes
The signature area of the ATtiny13A contains two bytes of calibration data for the internal oscil-
lator. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6
MHz operation. During reset, this byte is automatically written into the OSCCAL register to
ensure correct frequency of the oscillator.
Если там так написано и если вас устраивает работа на 9.6 МГц то не нужно ничего заносить в OSCAL - при старте калибровочный байт на 9.6 МГц автоматически загрузится в него.
Документации на ATTiny13A под рукой нет но в обычной ATTiny13 только 1 калибровочный байт.
Или Вы желаете знать оба заводских калибровочных байта? Протокол Serial Programming в DS описан: соберите своё устройство, которое прочитает higt bytes сигнатуры с Вашего МК.
Цитата(aesok @ Jul 14 2009, 09:47)
Не понятно почему здесь написано адрес 0x01 в signature area.
Почему же - непонятно? Очень даже понятно... Старшие байты в signature area - не заняты, вот туда и помещены байты калибровки.Цитата(aesok @ Jul 14 2009, 09:47)
Я не вижу в этом контроллере возможности прочесть из програмы калибровочные байты, так что придёться читать его програматором и копировать в какой нибудь определеннй адрес FLASH или EEPROM и затем уже оттуда копировать в OSCCAL.
И зачем это нужно. Имхо, калибровочные байты попадут в OSCCAL аппаратно, и если заводская калибровка устраивает, и делать ничего не нужно. Ну, а если - не устраивает, то калибравать прийдётся самостоятельно, и заводские значения, опять же - не интересны.
Цитата(Палыч @ Jul 14 2009, 10:59)
И зачем это нужно. Имхо, калибровочные байты попадут в OSCCAL аппаратно, и если заводская калибровка устраивает, и делать ничего не нужно. Ну, а если - не устраивает, то калибравать прийдётся самостоятельно, и заводские значения, опять же - не интересны.
Так человека как раз и интерисует заводское значение на чачтоту 4.8, а автоматом копируеться значение на 9.6.
Анатолий.
Цитата(vika1 @ Jul 14 2009, 09:30)
The signature area of the ATtiny13A contains two bytes ...
Ага! Значит не ATtiny13, а ATtiny13АP.S. В программаторе Вы выставляете МК "ATtiny13", а нужно "ATtiny13A", если программатор знает про такой МК. Если не знает - попробуйте найти для него последние обновления (если таковые существуют).
Цитата(aesok @ Jul 14 2009, 10:01)
Так человека как раз и интерисует заваодское значение на чачтоту 4.8, а автоматом копируеться значение на 9.6.
Не факт, что второй калибровочный байт не будет загружен для частоты 4.8
Цитата(Палыч @ Jul 14 2009, 11:06)
Ага! Значит не ATtiny13, а ATtiny13А
Зачем гадать на кофейной гуще. В ревизии I даташита на ATtiny13 написано про 2 калибровочных байта.
Цитата(Палыч @ Jul 14 2009, 11:06)
Не факт, что второй калибровочный байт не будет загружен для частоты 4.8
Пожалуйста приведите цитату из даташита описывающию этот "Не факт".
Анатолий.
Кстати и для ATtiny13 и ATtiny13V в редакции от 05/08 на стр 104 также говорится о двух калибровочных байтах.
Согласен, из программы пользователя прочитать калибровочный байт для 4.8МГц не получится.
При прошивке микросхем программатор должен читать оба калибровочных числа,т.к. индивидуально танцевать с каждой мс при серийном производстве никто не будет.
Примерно так делает Elnec T51(делают в Чехии): он читает калибровочный байт для выбранного фузами генератора и предлагает прописать его в ячейку flash или EEPROM по заданному пользователем адресу памяти, а программа пользователя должна читать его из этой ячейки и грузить в регистр OSCCAL. Засада в том, прочитанный калибровочный байт одинаков для каждого из двух генераторов. . И это несмотря на то, что программатор Elnec c обновленной(июньской версией ПО) Почему одинаковый, если Atmel говорит о двух байтах, а разработчики ПО для программаторов сообщают только об одном? Тогда остается только версия одного генератора на 9.6 МГц и наличии делителя на 2
Согласен, из программы пользователя прочитать калибровочный байт для 4.8МГц не получится.
При прошивке микросхем программатор должен читать оба калибровочных числа,т.к. индивидуально танцевать с каждой мс при серийном производстве никто не будет.
Примерно так делает Elnec T51(делают в Чехии): он читает калибровочный байт для выбранного фузами генератора и предлагает прописать его в ячейку flash или EEPROM по заданному пользователем адресу памяти, а программа пользователя должна читать его из этой ячейки и грузить в регистр OSCCAL. Засада в том, прочитанный калибровочный байт одинаков для каждого из двух генераторов. . И это несмотря на то, что программатор Elnec c обновленной(июньской версией ПО) Почему одинаковый, если Atmel говорит о двух байтах, а разработчики ПО для программаторов сообщают только об одном? Тогда остается только версия одного генератора на 9.6 МГц и наличии делителя на 2
Ответ техподдержки с Atmel:
Dear Customer,
For the ATtiny13A, the 4.8 MHz clock is indeed generated by dividing the 9.6 MHz clock.
However, the device still has separate calibration bytes for these two modes.
То бишь они признаются , что генератор Один единственный и вторая частота получается делением на 2!
А вот по поводу равенства калибровочных байт для первой и второй частот непонятно, написал еще раз в техподдержку!
Ждем.
Dear Customer,
For the ATtiny13A, the 4.8 MHz clock is indeed generated by dividing the 9.6 MHz clock.
However, the device still has separate calibration bytes for these two modes.
То бишь они признаются , что генератор Один единственный и вторая частота получается делением на 2!
А вот по поводу равенства калибровочных байт для первой и второй частот непонятно, написал еще раз в техподдержку!
Ждем.
Цитата(vika1 @ Jul 14 2009, 15:37)
А вот по поводу равенства калибровочных байт для первой и второй частот непонятно, написал еще раз в техподдержку! Ждем.
Так если генератор - один, почему калибровочные байты должны быть разными? По-видимуму, это - "заготовка" для двух генераторов.
Нашел у себя Tiny13, подключил к AVRISP. Прочитал два различных калибровочных байта. Только зачем разработчики Atmel сделали два генератора, если имеется клок прескалер (регистр CLKPR) от 1 до 256. На месте автора топика я бы им воспользовался и плюнул на генератор 4,8 MHz раз программатор не читает его калибровочный байт.
Цитата(#alex_ @ Jul 15 2009, 09:41)
На месте автора топика я бы им воспользовался и плюнул на генератор 4,8 MHz раз программатор не читает его калибровочный байт.
Лишние пару слов тратить из 512-ти имеющихся..
Я бы напротив - поставил 4.8 фузами, и плюнул бы на калибровочные байты (на кой их вообще читать если заводская частота устраивает?).
Цитата(#alex_ @ Jul 15 2009, 09:41)
Нашел у себя Tiny13, подключил к AVRISP. Прочитал два различных калибровочных байта.
Аналогично, только программатор, естественно, avreal.ATtiny13V
У двух экземпляров
1: 4F, 4D
2: 64, 65.
Цитата(defunct @ Jul 15 2009, 13:30)
Лишние пару слов тратить из 512-ти имеющихся..
Я бы напротив - поставил 4.8 фузами, и плюнул бы на калибровочные байты (на кой их вообще читать если заводская частота устраивает?).
Я бы напротив - поставил 4.8 фузами, и плюнул бы на калибровочные байты (на кой их вообще читать если заводская частота устраивает?).
Хорошее предложение! Вот только с каким разбросом настроены эти генераторы? Судя по описанию регистр OSCCAL по умолчанию в нуле. Согласно даташиту ATTiny13A (другие варианты ATtiny13 сняты с производства) см.график фиг19-51 частота генератора 4.8 Мгц меняется в диапазоне 2-9 МГц при изменении OSCCAL 0-0x7F. На какой частоте будет молотить RC генератор, если не грузить OSCCAL?
На практике проверил с десяток образцов - при выборе фузами генератора 4.8 Мгц разброс частоты не превышает 5%, регистр OSCCAL не загружается. Но ведь при этом OSCCAL=0, а согласно графика 19-51 частота при этом значении равна 2Мгц?
Опять какая то нестыковка.
Мне задают вопрос- почему выбрана частота 4.8 а не 9.6 МГц. Выбор этой частоты диктуется батарейным питанием устройства
(лит. бат) -получается гарантированная работа на напряжении 1.8V.
Хотя справедливости ради можно отметить: проверял несколько экземпляров с частотой 9.6Мгц на напряжении 1.8V- работают! Это при комнатной температуре. А что будет на крайних температурных точках? Согласно даташита работа не гарантируется.
Цитата(vika1 @ Jul 16 2009, 20:46)
Вот только с каким разбросом настроены эти генераторы?
укладываются в указанные в ДШ +/- 10% при Vcc=3V, T=25C
Цитата(vika1 @ Jul 16 2009, 20:46)
регистр OSCCAL не загружается.
Если бы он оставался в 0, то ни о каких 5% не было бы и речи. Имели бы 2Mhz с хвостиком всегда.
Цитата(vika1 @ Jul 16 2009, 20:46)
Мне задают вопрос- почему выбрана частота 4.8 а не 9.6 МГц. Выбор этой частоты диктуется батарейным питанием устройства
(лит. бат) -получается гарантированная работа на напряжении 1.8V.
(лит. бат) -получается гарантированная работа на напряжении 1.8V.
Да нет проблем, у меня даже вопроса не возникало зачем оно Вам. Раз решили использовать 4.8Mhz, значит так надо.
И тут все просто. Раз документировано, что фузами можно включить 4.8Mhz, значит включится именно 4.8Mhz, а не 2 и не 9Mhz.
Хотя бы из простых соображений -
Уважающий себя производитель не может заявить фичу которая не совпадает ни с документацией и ни со старой ревизией чипа, и вообще хз как работает. Кто б тогда это г. покупал?
Цитата
Хотя справедливости ради можно отметить: проверял несколько экземпляров с частотой 9.6Мгц на напряжении 1.8V- работают!
При 1.8В гарантируется работа МК на частотах 0-4Mhz. Даже 4.8Mhz - это уже существенный оверклок +20%, ДШ рекомендует делить частоту RC ренератора в таком случае на 8, соотв. фузом.
Можно ставить генератор на любую частоту, но надо поделить его так чтобы частота тактирования МК получилась <=4Mhz даже при стартапе если чип питается от 1.8В.
Лично меня бы в этом случае вероятно удовлетворила бы комбинация RC на 9.6 + CKDIV8 (в итоге 1.2Mhz в т.ч. при стартапе).
Ну а Вы смотрите, если готовы к оверклоку +20%, и не боитесь огрести проблем, то пробуйте.
Можно разве только учесть что:
при 2.7В гарантируется работа на 10Mhz
1.8В гарантируется работа на 4Mhz.
Цена каждых 100мв (грубо) равна 6Mhz / 9 = 0.667Mhz
Для гарантированной работы на 4.8Mhz надо питать хотя бы от 2.0В.
Ну а возвращаясь к Вашему изначальному вопросу о калибровочных байтах:
Цитата
During reset, hardware loads the calibration data into the OSCCAL register and thereby automatically
calibrates the oscillator. There are separate calibration bytes for 4.8 and 9.6 MHz
operation but only one is automatically loaded during reset (see section “Calibration Bytes” on
page 105). This is because the only difference between 4.8 MHz and 9.6 MHz mode is an internal
clock divider.
calibrates the oscillator. There are separate calibration bytes for 4.8 and 9.6 MHz
operation but only one is automatically loaded during reset (see section “Calibration Bytes” on
page 105). This is because the only difference between 4.8 MHz and 9.6 MHz mode is an internal
clock divider.
Internal RC осциллятор всегда стартует на 9.6Mhz, и всегда загружается один и тот же калибровочный байт для частоты 9.6Mhz. Когда фузами программируется частота 4.8Mhz, то просто включается делитель на 2 с выхода генератора. Вот и вся разница.
На вопрос "нафиг нужен второй калибровочный байт?" мой ответ будет таким:
1. для того, чтобы можно было ручками включить 4.8Mhz в программе, когда генератор фузами настроен на 9.6Mhz.
2. для того чтобы можно было расчитать значение OSCCAL для любой другой частоты (ведь когда есть две точки - можно провести прямую).
Цитата
Для гарантированной работы на 4.8Mhz надо питать хотя бы от 2.0В.
Полностью согласен с Вашим выводом.
Цитата
Internal RC осциллятор всегда стартует на 9.6Mhz, и всегда загружается один и тот же калибровочный байт для частоты 9.6Mhz. Когда фузами программируется частота 4.8Mhz, то просто включается делитель на 2 с выхода генератора. Вот и вся разница.
Спасибо! Именно эта Ваша фраза и разъясняет ситуацию.
Но вот изречение на стр 105 даташита опять настораживает
Цитата
There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation but
this data is not loaded automatically. The hardware always loads the 9.6 MHz calibraiton data
during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL
register must be updated by firmware.
this data is not loaded automatically. The hardware always loads the 9.6 MHz calibraiton data
during reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCAL
register must be updated by firmware.
Зачем тогда на частоте 4.8 Мгц программно обновлять регистр OSCCAL вторым калибровочным байтом?
Цитата
На вопрос "нафиг нужен второй калибровочный байт?" мой ответ будет таким:
1. для того, чтобы можно было ручками включить 4.8Mhz в программе, когда генератор фузами настроен на 9.6Mhz.
1. для того, чтобы можно было ручками включить 4.8Mhz в программе, когда генератор фузами настроен на 9.6Mhz.
А вот здесь не совсем так:
Значения калибровочных байт для частот 9.6 и 4.8Мгц отличаются всего лишь на несколько дискрет.
Цитата(ReAl @ Jul 15 2009, 17:23)
Аналогично, только программатор, естественно, avreal.
ATtiny13V
У двух экземпляров
1: 4F, 4D
2: 64, 65.
ATtiny13V
У двух экземпляров
1: 4F, 4D
2: 64, 65.
Поэтому , если первоначальная настройка генератора была на 9.6 Мгц и в ходе выполнения программы генератор перестраивается при помощи команды
OSCCAL=(Cal_byte4.8MHz). Изменения частоты при этом будут незначительными. То есть смысл введения в сигнатуру контроллера второго калибровочного байта остается непонятным
Цитата(vika1 @ Jul 17 2009, 11:28)
Поэтому , если первоначальная настройка генератора была на 9.6 Мгц и в ходе выполнения программы генератор перестраивается при помощи команды
OSCCAL=(Cal_byte4.8MHz). Изменения частоты при этом будут незначительными. То есть смысл введения в сигнатуру контроллера второго калибровочного байта остается непонятным
OSCCAL=(Cal_byte4.8MHz). Изменения частоты при этом будут незначительными. То есть смысл введения в сигнатуру контроллера второго калибровочного байта остается непонятным
Да Вы правы.
Мне почему то ночью показалось, что Real пронумеровал калибровочные байты (и первым поставил второй)
Всмысле что 0x64 первый калибровочный байт, а 0x4F - второй.
Прошу прощения за невнимательность.
Цитата(defunct @ Jul 17 2009, 03:35)
На вопрос "нафиг нужен второй калибровочный байт?" мой ответ будет таким:
1. для того, чтобы можно было ручками включить 4.8Mhz в программе, когда генератор фузами настроен на 9.6Mhz.
2. для того чтобы можно было расчитать значение OSCCAL для любой другой частоты (ведь когда есть две точки - можно провести прямую).
3. Для того, чтобы меньше менять при переходе с tiny13 на tiny13А - скрипты/ключи/галочки программаторов, вынимавшие второй OSCCAL для тини13 - будут продолжать работать для tiny13A1. для того, чтобы можно было ручками включить 4.8Mhz в программе, когда генератор фузами настроен на 9.6Mhz.
2. для того чтобы можно было расчитать значение OSCCAL для любой другой частоты (ведь когда есть две точки - можно провести прямую).
А для tiny13 эти байты были разные (причём встречальись и бОльшие различия, более, чем на единичку в двух парах выше) и это было принципиально.
По поводу различий между ATtiny13(Rev. 2535I–AVR–05/08) и ATtiny13A( Rev. 8126B–AVR–12/08) различий в даташитах в части описания калибровочных байт нет никаких. В наличии два генератора и два калибровочных байта.
Для ATtiny13( Rev. 2535G–AVR–01/07) имеем два генератора и один калибровочный байт.
А как определить ревизию конкретной мс?
Стою на асфальте я , в лыжи обутый........
Для ATtiny13( Rev. 2535G–AVR–01/07) имеем два генератора и один калибровочный байт.
А как определить ревизию конкретной мс?
Стою на асфальте я , в лыжи обутый........
О чо нашёл в апноте по калибровке RS генератора:
Цитата
Version 1.x oscillators
This version is the earliest internal RC for AVR that can be calibrated, though asynchronous operation is not possible. Due to this, parts having this version of the internal oscillator cannot be calibrated using an external crystal and does not appear in Table 6-1.
Version 2.x oscillators
This oscillator is offered with a frequency of 1MHz. The dependency between the oscillator frequency and operating voltage and temperature is reduced significantly compared to version 1.x.
Version 3.x oscillators
This version was introduced along with the first devices produced in the 35.5k process.
The oscillator system is expanded to offer multiple oscillator frequencies. Four different RC oscillators with the frequencies 1, 2, 4, and 8MHz are present in the device. This version features automatic loading of the 1MHz calibration byte from the Signature Row. Due to the fact that 4 different RC oscillators are present, 4 different calibration bytes are stored in the Signature Row. If frequencies other than the default 1MHz are desired, the OSCCAL register should be loaded with the corresponding calibration byte at run-time.
Version 4.x oscillators
A single oscillator frequency of 8MHz is offered in version 4.0. For later 4.x versions, two frequencies are offered: 4 and 8MHz for ATtiny2313, and 4.8 and 9.6MHz for the ATtiny13. The OSCCAL register is changed so that only 7 bits are used to tune the frequency for the selected oscillator. The MSB is not used. Auto loading of the default calibration value and system clock prescaler is present.
Version 5.x oscillators
A single oscillator frequency of 8MHz is offered in version 5.0 All 8 bits in the OSCCAL register are used to tune the oscillator frequency. Auto loading of the default calibration value and system clock prescaler is present. The OSCCAL register is split in two parts. As seen in Figure 7-2, the MSB of OSCCAL selects one of two overlapping frequency ranges, while the 7 least significant bits are used to tune the frequency within this range.
This version is the earliest internal RC for AVR that can be calibrated, though asynchronous operation is not possible. Due to this, parts having this version of the internal oscillator cannot be calibrated using an external crystal and does not appear in Table 6-1.
Version 2.x oscillators
This oscillator is offered with a frequency of 1MHz. The dependency between the oscillator frequency and operating voltage and temperature is reduced significantly compared to version 1.x.
Version 3.x oscillators
This version was introduced along with the first devices produced in the 35.5k process.
The oscillator system is expanded to offer multiple oscillator frequencies. Four different RC oscillators with the frequencies 1, 2, 4, and 8MHz are present in the device. This version features automatic loading of the 1MHz calibration byte from the Signature Row. Due to the fact that 4 different RC oscillators are present, 4 different calibration bytes are stored in the Signature Row. If frequencies other than the default 1MHz are desired, the OSCCAL register should be loaded with the corresponding calibration byte at run-time.
Version 4.x oscillators
A single oscillator frequency of 8MHz is offered in version 4.0. For later 4.x versions, two frequencies are offered: 4 and 8MHz for ATtiny2313, and 4.8 and 9.6MHz for the ATtiny13. The OSCCAL register is changed so that only 7 bits are used to tune the frequency for the selected oscillator. The MSB is not used. Auto loading of the default calibration value and system clock prescaler is present.
Version 5.x oscillators
A single oscillator frequency of 8MHz is offered in version 5.0 All 8 bits in the OSCCAL register are used to tune the oscillator frequency. Auto loading of the default calibration value and system clock prescaler is present. The OSCCAL register is split in two parts. As seen in Figure 7-2, the MSB of OSCCAL selects one of two overlapping frequency ranges, while the 7 least significant bits are used to tune the frequency within this range.
Цитата(Т.Достоевский @ Jul 26 2009, 03:31)
О чо нашёл в апноте по калибровке RS генератора:
Это все так, но вопрос то в другом: почему при единственном RC генераторе с частотой 9.6 МГц и внутреннем делителе частоты на 2 в контроллере предусмотрено два калибровочных байта.
Цитата(vika1 @ Jul 14 2009, 14:37)
Ответ техподдержки с Atmel:
Dear Customer,
For the ATtiny13A, the 4.8 MHz clock is indeed generated by dividing the 9.6 MHz clock.
However, the device still has separate calibration bytes for these two modes.
То бишь они признаются , что генератор Один единственный и вторая частота получается делением на 2!
А вот по поводу равенства калибровочных байт для первой и второй частот непонятно, написал еще раз в техподдержку!
Ждем.
Не знаю, насколько это ещё интересно, но...Dear Customer,
For the ATtiny13A, the 4.8 MHz clock is indeed generated by dividing the 9.6 MHz clock.
However, the device still has separate calibration bytes for these two modes.
То бишь они признаются , что генератор Один единственный и вторая частота получается делением на 2!
А вот по поводу равенства калибровочных байт для первой и второй частот непонятно, написал еще раз в техподдержку!
Ждем.
Зачем при одном генераторе и 4.8=9.6/2 читается два калибровочных байта - понять можно. Для совместимости.
Но почему эти байты разные? Не может же частота 9.6 меняться от того, включен делитель на 2 после генератора или нет.
Просто мимо меня пробежало некоторое количество tiny13A, по четыре штуки середины и конца 2009-го, шесть штук начала 2010-го года. А я про эту тему вспомнил.
0923: 45 43
0923: 53 55
0923: 55 55
0923: 5C 5E
0951: 4B 46
0951: 60 63
0951: 5E 5F
0951: 57 58
1012: 41 3D
1012: 63 65
1012: 46 44
1012: 4B 49
1012: 49 45
1012: 5B 5D
Вот и непонятен ответ про один генератор (точнее, думаю, и раньше генератор был один, просто разные источники перезарядного тока были). Байты калибровки все разные, при одном генерирующем элементе и подключаемом делителе на два это как-то неестественно.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.