Обмен МК со Slave устройствами по I2C

[EugVor]

Кто-нибудь писал обмен для МК с I2C устройством вручную? Важна ли Slave устройству с интерфейсом I2C (напр. памяти) стабильность частоты шины синхронизации SCL ? Или достаточно соблюсти временные интервалы ? И ещё: читаю PDF на I2C память FM24C64 - при частоте SCL 100кГц временные выдержки данных надо обеспечить бОльшие, по сравнению с частотой 400кГц.
Казальсь бы частота ниже - времени на внутрение операции у памяти больше, а время Clock High Period высокого состояния шины SCL) требуется в 5 раз больше.

[paha1956]

В ПДФ-ке на FM3104/16/64/256 читаю:

Parameter Min Max Min Max Min Max Units
----------------------------------------
SCLClock 0 100 0 400 0 1000 kHz
ClLowPer 4.7 1.3 0.6 µs
ClHighPer 4.0 0.6 0.4 µs

Как видно из таблички при 100 кГц время высокого состояния синхро 4 мкс, а при 1000 кГц - 0.4 мкс, так что всё в порядке с временами.
А что касается стабильности частоты синхронизации - на то он и синхроимпульс, что бы от него всё синхронизировалось. При этом он может быть любой частоты от 0 до 1000 кГц, главное что бы биты устанавливались до установки синхроимпульса, а читались - после.

[EugVor]

Вот вот. То есть главное чтобы перед установкой шины SCL в высокий уровень, бит данных на шине SDA был уже приготовлен, а после сброса SCL какое-то время удерживался. А таже скважность импульсов синхронизации похоже не важна, как и её постоянство. То есть если мне необходимо в процессе обмена с памятью выполнить какие-то внутренние операции, я могу удлиннить на это время состояние низкого уровня шины SCL?
А по поводу таблицы в PDF, как я понял эти времена, ни есть требуемые. а те которые получатся если работать с частотами 100 и 400кГц.

[paha1956]

... То есть если мне необходимо в процессе обмена с памятью выполнить какие-то внутренние операции, я могу удлиннить на это время состояние низкого уровня шины SCL?...

Теоретически - да. На практике я этого не проверял (не смотрел осцилом), но судя по тому, что всё работает и процесс обмена довольно часто перекрывается вызовами обработчиков прерываний, то и практически, вероятно, тоже - да.