Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: частота синхросигнала на шине i2c
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
DeathOfPower
ваяю девайс в котором по i2c должны обмениваться пакетами 2 разных контроллера - ATMega32 и ATMega168. Тактовая частота у ATMega168 - 14.7456 МГц а у ATMega32 в 2 раза меньше (ему высокая производительность не нужна и для понижения энергопотребления решил уменьшить частоту, но нижний порог её ограничен тем, что тактовая частота должна быть как минимум в 16 раз больше частоты синхроимпульсов на шине i2c ну и частота доожна быть удобной для деления с целью получения точных значений скорости передачи на RS232 - связь с компьютером для выгрузки логов и диагностики). Решил выбрать частоту синхросигнала на линии SCL, реализуемую при помощи делителей на обоих контроллерах, полез в документацию и обнаружил что максимальной такой частотой является 368640 Гц - у и ATMega168 при этом делитель 40, а у и ATMega32 - 20.

но написав тестовый пример бесконечной передачи байта, для замера реальной частоты синхроимпульсов, обнаружил - тактовая частота при передаче от и ATMega168 к и ATMega32 меньше таковой при передаче от и ATMega32 к и ATMega168 примерно на 48 кГц!!! я уж заподозрил ошибку в формуле расчёта коэффициента деления в документации к ATMega168. Но потом обнаружил, что при приёме байта в и ATMega32 - от факта обнаружения взведённости флага TWINT до его сброса (необходимо проверить регистр статуса, если статус соответствующий, то сохранить принятый байт в памяти) проходит 14 тактов и всё это время линия SCL удерживается в низком уровне приёмной стороной. И происходит это после приёма каждого байта (в битах = 8 бит + 1 бит подтверждения). Попробовал рассчитать среднюю частоту с учётом этой задержки, но она получилась всего на 16 кГц меньше устанавливаемой делителем.
Куда деваются ещё 32 кГц? Есть у кого-нить мысли? Прерывания во время приёма и передачи запрещены.
=GM=
Цитата(DeathOfPower @ Mar 13 2009, 09:05) *
я уж заподозрил ошибку в формуле расчёта коэффициента деления в документации к ATMega168

Ну, ошибка там, похоже, всё-таки есть - пропущены скобки, делитель должен быть (16+2(TWBR))*prescaler, а не 16+2(TWBR)*prescaler.

Цитата(DeathOfPower @ Mar 13 2009, 09:05) *
написав тестовый пример бесконечной передачи байта, для замера реальной частоты синхроимпульсов, обнаружил - тактовая частота при передаче от и ATMega168 к и ATMega32 меньше таковой при передаче от и ATMega32 к и ATMega168 примерно на 48 кГц

Тут как-то не верится, что-то вы не то делаете. Каков измеренный период синхроимпульсов?
DeathOfPower
Цитата(=GM= @ Mar 13 2009, 15:16) *
Ну, ошибка там, похоже, всё-таки есть - пропущены скобки, делитель должен быть (16+2(TWBR))*prescaler, а не 16+2(TWBR)*prescaler.


Тут как-то не верится, что-то вы не то делаете. Каков измеренный период синхроимпульсов?


скобки эти у меня никак не повлияют ибо prescaler = 1
период мерять нечем, есть только самопальный некалиброваный частотомер на AtTiny2313 smile.gif хоть частоту меряет и не точно но уж разницу то такую грех не заметить. Попробую AtMega32 тактовать от кварца на 14.756 и делитель поставить как на AtMega168. Чтобы посмотреть будут ли при этом частоты на SCL одинаковы у обоих контроллеров.
_Pasha
Цитата(DeathOfPower @ Mar 13 2009, 13:05) *
 обнаружил - тактовая частота при передаче от и ATMega168 к и ATMega32 меньше таковой при передаче от и ATMega32 к и ATMega168 примерно на 48 кГц!!!
Куда деваются ещё 32 кГц? Есть у кого-нить мысли? Прерывания во время приёма и передачи запрещены.

Вы не учли, что тактовая устанавливается по процедуре арбитража - в Вашем случае кто из приемников раньше отпустит SCL - на том варианте и быстрее. Так что ищите причину в запрещенных прерываниях.
ЗЫ: на всякий случай. При приеме SCL держится приемником в нуле до прочтения TWDR или TWSR - не помню.
DeathOfPower
Цитата(_Pasha @ Mar 13 2009, 17:12) *
Вы не учли, что тактовая устанавливается по процедуре арбитража - в Вашем случае кто из приемников раньше отпустит SCL - на том варианте и быстрее. Так что ищите причину в запрещенных прерываниях.
ЗЫ: на всякий случай. При приеме SCL держится приемником в нуле до прочтения TWDR или TWSR - не помню.


SCL держит приёмник пока не сбросишь флаг TWINT записав туда еденицу...
просто эта задержка возникает лишь после приёма 8 байт и ответа ACK-ом - т.е. через каждые 9 тактов на SCL и по моим расчётам она ответственна лишь за 1/3 обнаруженного понижения частоты
_Pasha
Цитата(DeathOfPower @ Mar 13 2009, 21:23) *
просто эта задержка возникает лишь после приёма 8 байт

Дык напрашивается вывод: код в студию! А то сам себя не проверишь...
DeathOfPower
в коде всё верно...
"собака зарылась" в настройках проекта smile.gif

я видимо когда некоторые части кода отлаживал под эмулятором, то отключил оптимизацию кода в проекте который компилируется под ATMega168 smile.gif
включил оптимизацию и частота стала очень близкой с тем вариантом когда передачей занимается ATMega32, но тут просто разница (очень небольшая) из-за различного типа доступа к регистрам шины I2C - в ATMega32 они находятся в адресном пространстве I/O Registers запись/чтение их осуществляется коммандами OUT/IN каждая из которых занимает 1 такт. А вот в ATMega168 эти регистры попадают в Ext I/O Reg. и запись/чтение их осуществляется коммандами (ST/STS/STD)/(LD/LDS/LDD) каждая из которых занимает 2 такта.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.