Как отправить даные Master со Slave? I2C Опции

[BeginnerAVR]

Доброго времени суток!

Объясните, люди добрые, новичку, что и как...
Два AVR связаны по I2C. Мастер отправляет инфу - слейв принимает. Все ок.
А как сделать чтобы на запрос мастера, например, отправилось два байта со слейва.

Какой должен быть алгоритм для master и slave?

Пользуюсь готовым интерфейсником i2c.c
// Title : I2C interface using AVR Two-Wire Interface (TWI) hardware
// Author : Pascal Stang - Copyright © 2002-2003

Может кто-то уже реализовывал I2C с этой библиотекой?

[Maik-vs]

Сейчас понимаю, что связаться с i2C было ошибкой. БОЛЬШОЙ ошибкой.

Посмотрите, как устроены телевизоры/мониторы, и вам станет легче. Не для лишней мороки Филипс изобрели IIS, уж поверьте.

Если бы у меня было образование соответствующее, то количество моих вопросов
на форуме может быть и вообще равно 0x00.

Вовсе нет, круг знаний больше - больше и граница незнаемого. Просто ваши вопросы были бы не очень понятны beginner'ам

Всегда добиваюсь того, чтобы работало не только в камне, но и в Proteus. Это принципиальный момент.

Зачем?!! Вы что-то должны протеусу? Любой симулятор - всего лишь модель. "Работать должно в корпусе, а не в принципе" - вот фраза, выкованная жизнью.

Как мастер вытаскивает данные со слейва, написано,например, в документе UM10204 "I2C-bus specification and user manual".
Мастер посылает слейву старт, потом адрес с признаком чтения и гонит снихроимпульсы. Слейв подставляет данные, а если не успевает, может "прижать" синхроимпульс, тогда мастер ждёт. После каждого байта мастер даёт АСК, а когда наелся - NAK. Вот и всё.

Из мануала: "For additional information, please visit: http://www.nxp.com"

Сообщение отредактировал Maik-vs - Jun 5 2012, 04:40

[BeginnerAVR]

Посмотрите, как устроены телевизоры/мониторы, и вам станет легче. Не для лишней мороки Филипс изобрели IIS, уж поверьте.

Согласен. Разработчику всегда проще обращаться со своей разработкой, нежели чем с чужой, какой гениальной она бы не была.

Вовсе нет, круг знаний больше - больше и граница незнаемого. Просто ваши вопросы были бы не очень понятны beginner'ам

Чем больше знаний, тем развитее интуиция в плане изысканий. Уже не нужно спрашивать, иногда достаточно клочка кода, заветной строчки и дальше
можно не читать. Сужу, правда по программированию, и все-таки, практика возни с электроникой частично подтверждает.

Зачем?!! Вы что-то должны протеусу? Любой симулятор - всего лишь модель. "Работать должно в корпусе, а не в принципе" - вот фраза, выкованная жизнью.

До камня я пложу на диске варианты схемы, модифицируя конструктив и код, решаю как лучше подключить, что следует заложить на будущее чего-либо еще.
Согласен, что до настоящего реалтайма и точности ему все далеко, однако по сравнению со сбокой макетки - удобнее. Дебаггеры шин, например, мне очень помогли. Видно что передано, что получено.
Это сугубо частное мнение, без претензий на "абсолютную правильность".

Как мастер вытаскивает данные со слейва, написано,например, в документе UM10204 "I2C-bus specification and user manual".
Из мануала: "For additional information, please visit: http://www.nxp.com"

Читал, он мне снится уже.

Мастер посылает слейву старт, потом адрес с признаком чтения и гонит снихроимпульсы. Слейв подставляет данные, а если не успевает, может "прижать" синхроимпульс, тогда мастер ждёт. После каждого байта мастер даёт АСК, а когда наелся - NAK. Вот и всё.

Вот! Золотые слова. Последовательность "на пальцах". И именно такое описание шины ИДЕАЛЬНО подходит чтобы понять ее суть, дальше - детали.
Уверен, что преподаватели в ВУЗах не начинают нести крутой бред про i2c, а сначала объясняют в общих чертах.
А то в статьях все сразу пытаются в одном абзаце объять необъятное и впихнуть не... Потом сразу идет раздел "СТАРТ И СТОП", потом "АДРЕСАЦИЯ"...
Если начать с простого описания - то все легче, понятнее, предсказуемее.
Maik-vs, спасибо. Нужно было написать вопрос две недели назад и получить ваш ответ, сохранив тем самым две недели и нервы.

Сообщение отредактировал BeginnerAVR - Jun 5 2012, 21:25

[Maik-vs]

Нужно было написать вопрос две недели назад и получить ваш ответ, сохранив тем самым две недели и нервы.

Это вряд ли. Я тогда искал как сделать, чтобы окно, сделанное в MFC С++ оставалось "живым" на длинных операциях и как покрасить строку в листбоксе. Весь в компе/интернете, только ноги наружу торчали

Ещё про IIC.

Совершенно непонятно, зачем им сущность "рестарт". Ну старт и старт, нет, надо обозвать одно и то же разными словами.

И неприятный глюк, про который аппноты молчат.
Например, мастер пишет в слейв. И пропал один синхроимпульс. Слейв выставляет свой АСК, а мастер уже обмен закончил. Всё, линия данных заблокирована. Или наоборот, мастер читает со солейва. Помеха прибежала, лишний синхроимпульс. Слейв может никогда не увидеть NAK от мастера, останется в цикле чтения и засадит шину данных в 0.
Словом, любая рассинхронизация счётчиков битов мастера и слейва может привести к катастрофическому зависанию.

Поэтому вторая версия протокола предусматривает ограничение скорости обмена снизу, или проще говоря тайм-ауты, которые должны бдить все устройства на шине. Нет синхроимпульсов в течение заданного времени - работу долой, шину освободить, ждать старта.

[BeginnerAVR]

Это вряд ли. Я тогда искал как сделать, чтобы окно, сделанное в MFC С++ оставалось "живым" на длинных операциях и как покрасить строку в листбоксе. Весь в компе/интернете, только ноги наружу торчали

Для ЯВУ (в отличие от микроконтроллеров) полно FAQ-cборников, где по направлениям разбиты "финты ушами", в том числе покраски VCL и прочие шалости.
Для AVR такого не найти в принципе. Думаю, это связано с тем, что программистов больше, чем инженеров и это менее затратное хобби увлечение

Ещё про IIC.
Совершенно непонятно, зачем им сущность "рестарт". Ну старт и старт, нет, надо обозвать одно и то же разными словами.
И неприятный глюк, про который аппноты молчат.
Например, мастер пишет в слейв. И пропал один синхроимпульс. Слейв выставляет свой АСК, а мастер уже обмен закончил. Всё, линия данных заблокирована. Или наоборот, мастер читает со солейва. Помеха прибежала, лишний синхроимпульс. Слейв может никогда не увидеть NAK от мастера, останется в цикле чтения и засадит шину данных в 0.
Словом, любая рассинхронизация счётчиков битов мастера и слейва может привести к катастрофическому зависанию.
Поэтому вторая версия протокола предусматривает ограничение скорости обмена снизу, или проще говоря тайм-ауты, которые должны бдить все устройства на шине. Нет синхроимпульсов в течение заданного времени - работу долой, шину освободить, ждать старта.

Автомат TWI в AVR конечно здорово, но легче от этого не становится если взять обработку всех флагов через прерывание и учесть многообразие внештатных ситуаций, подсчета числа попыток, повторных попыток, то половину прошивки будет занимать только работа с шиной. Поэтому примеров связи двух AVR по i2c с многочисленными отправками/приемами практически нет...
Обычно - лишь опросы мастером на AVR разной периферии, в которой i2c реализован и тысячу раз проверен разработчиками.
На форумах очень часто пишут: "master сделал, а вот на разработке slave груз поймал"...