Интересный вопрос знатокам по теме интерфейса TWI

Интересная задача:

К ATMega 2560 подключен 3D-e-compass LSM303DLHC.
Используется шина TWI (I2C).
Для оптимального использования ресурса МК выход компаса DRDY подключен к ноге МК, генерирующей прерывания. Что означает, что факт готовности сенсора к передаче очередной порции данных вызывает прерывание в МК.
Все работает исключительно хорошо и быстро. Но...

...в пытливом уме возникает резонный вопрос: до каких пределов можно увеличивать частоту выборки данных ?

LSM умеет выдавать данные со частотой 1, 10, 25, 50, 100, 200, 400, 1620, 5376 Гц.
Каждая выборка состоит из 12 байт: по 2 байта на ось (x,y,z), всего 2 источника данных: акселерометр и магнетометр.

Даташит LSM303DLHC гласит (страница 12 таблица 6): I2C standard mode SCL clock frequency 1000 KHz (MAX). I2C fast mode 400 KHz.
И затем сноска: Data based on standard I2C protocol reuirements, not tested in production

Что означает, что если следовать стандарту реализации TWI, то LSM не вывезет больше 100 КГц на шине. На практике так и есть - предел 110 КГц.
К примеру, у Pololu есть шилд, у которого на борту стоит LSM303 и там умышленно изменены номиналы подтягивающих резисторов с тем, чтобы увеличить частоту шины до 400КГц. И на практике так и есть: работает на 400КГц и разгоняется до 650КГц.

Но в моем случае реализация TWI должна соответствовать стандарту.
А значит условия задачи выглядят так:
а) шина TWI
б) частота шины 100 КГц
в) каждый сеанс связи с устройством состоит из двух последовательных команд на чтение состояния двух регистров
г) в итоге устройство возвращает 6 байт информации

Вопрос: как рассчитать предельную частоту выборок (частота, с коротой сенсор генерит данные), которая гарантирует стабильную работу устройства при заданных условиях ?

 

Исходя из условий задачи
min ( частота I2C / длина пакета , частота выборки )

 

имхо, в вашей формуле ошибка.

Для чтения одного регистра (например, магнетометр x,y,z) получается:
- START condition (1 clock)
- ADDR [0:6] (7 clock)
- R/W bit (1 clock)
- ACK (1 clock)
- SUBADDR [0..7] (8 clock)
- ACK (1 clock)
- (DATA + ACK) * 5 (45 clocks)
- DATA + NACK (9 clock)
- STOP (1 clock)
Всего на один регистр 74 clocks.
На каждый сеанс итого 74 х 2 = 148 TWI clocks

1 TWI clock = 10 usec (при частоте 100 КГц)
148 TWI clocks = 1.48 msec
Округлим до 1.5 msec

Хоть и не учтена задержка, вызываемая кодом обработчика прерывания TWI_vect, она ничтожно мала по отношению к 1.5 msec. Ее можно не учитывать.

Полагаю, что для гарантированной работы интервал между пакетами должен быть вдвое больше длительности пакета.
Т.е.
1 / samplig_rate > 2 x packet_clocks, что для 100 КГц на шине дает
1 / sampling_rate > 2 x 0.0015 =>
1/ sampling_rate > 0.003

sampling_rate < 1 / 0.003

sampling_rate < 333 Hz

Тем не менее, спасибо за участие.
Хорошо бы кто-нибудь проверил бы мои расчеты...

 

Не, ну в такие детали я не влезал. Естественно будут и другие задержки, но грубо можно прикинуть и так. Еще проще проверить экспериментально если есть осциллограф. Попросить МК дернуть ногой по окончании обработки пакета и напрямую замерить время реакции.

 

Экспериментально я проверил - 200Гц предел (333 Гц сенсор не умеет)
Но верная теория - лучшее подтверждение эксперименту