Спешу обрадовать (ся?) всех. Переписал это левой ногой писанный обработчик I2C и всё заработало под осью причём с кучей тредов и FIQ-ом. Теперь термометр и мост на OWI работают на 400 КГц I2C без единого глюка. Бывает же такое - кривой обработчик, но без оси работал тоже без глюков.

Вобщем получилась тема дубль 2 с моей старой темой - про глюки FIQ
Если кому надо могу выложить обработчик прерывания I2C (только для мастера). Обработчик умеет в одном пакете передавать блок данных и сразу же принимать второй блок, не освобождая шину.

Может да, может нет. Разборки были много лет назад. Пока все устраивает.

Конечно надо, буквально на следующей неделе буду этим заниматься. Отчего же сразу не выложили?

Выкладываю. Причесал его как следует. По объёму текста получился такой же как у zltigo.

Забыл там ещё вот это

typedef signed short Int16;

Ещё очепятку нашёл в строке 29. Надо исправить число 11 на 12 вот так:

SetCoupleBits(PINMODE1,12,2); // резист.подтяжка выкл для P0.28

Хотя для I2C эта подтяжка возможно вообще не используется.

Ещё немного отшлифовал и улучшил. Работает прекрасно на 400 КГц I2C @ 24 МГц LPC2368. 7 тредов, 1 FIQ 8 КГц (занимающее 25% времени проца). Уж не знаю чем ещё загрузить проц для тестирования.

Много думал...
До сих пор непонятно, нужно ли при приёме данных на последнем байте мастеру передавать NACK ? Судя по картинке из мануала на 2368 "Fig 113. Format and States in the Master Receiver mode" - нужно. Но если подумать, то слишком умный слэйв (проц например) может воспринять этот NACK как ошибку приёма. С обычными I2C слэйвами в виде перифирийных микросхем проблем нет в обоих вариантах (ACK/NACK). В то же время я видел чей-то официальный исходник для MCS-51 с программной реализацией I2C, в котором всегда при приёме последнего байта по I2C мастер передавал NACK.

_______________________

По поводу моих исходников. Там можно в дополнение к I2CEngine() сделать её асинхронную версию (как ReadFile()/WriteFile() в винде) и во время передачи пакета по I2C проц будет выполнять что-либо полезное, периодически проверяя статус I2CEngine.

По стандарту нужно:

Если слейв "слишком умный" для совместимости, то это его проблемы.

Не всегда. С какими-то из слейвов у меня точно были проблемы из-за забытого NAK.
Увы, не вспомню уже, с какими именно. Возможно, это было с AD.

Из за отсутствия NAK имел проблемы с ds1307 при чтении ОЗУ. Вроде вполне распосраненная микросхема.

Если кто уже успел опробовать исходники - поделитесь впечатлениями и характеристиками работы/тестов.