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

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

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

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

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

Алгоритм должен быть... стандартный.
Почитаете про I2C и увидите что там всё довольно однообразно сделано.
Например здесь: TWI по русски
или тут.
Так же инфа есть тут: ApNotes.



Procyon AVRlib? Известная библиотека, наверное кто-нибудь и использовал.
Куча примеров кода с разными вариантами использования TWI (Slave/Master для mega/xmega/tiny)есть на сайте Atmel-а. Может оказаться что проще взять готовое оттуда, а не использовать Procyon AVRlib, который давно не обновляется. Я брал их код для TWI Master на xmega256 - нормально всё работало и написано неплохо.
Выбирать вам.

Сейчас понимаю, что связаться с i2C было ошибкой. БОЛЬШОЙ ошибкой. Две недели впустую. Купился на то, что с двумя проводами платы разводить легче, если дофига чего висит на шине. Получилось, что эта шина развела меня, а не я платы.
А если подумать, может Вы действительно правы и стоит взять за основу архар... атмеловские апноты. А еще лучше - сменить хобби... раз не дано. thanks

Почему же?
В общем нормальная шина и даже довольно быстрая.
Хотя и сам предпочитаю SPI или UART. Они проще.


Что-то не работает?
Возможно не соблюдены какие-то требования.
TWI AVR вполне рабочая штука и Master и Slave и MultiMaster.


Не знаю какой у вас МК.
Работал с TWI давно на megaAVR с EEPROM - писал реализацию сам, вобщем ничего сложного.
И недавно xmega+акселерометр - взял готовые библиотеки от атмел: неплохо написано и работает.


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

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



На рабочих примерах и той же пресловутой симуляции, плавно начинаю въезжать как это происходит.
Можно отследить шину, посмотреть как и что.



с внешним EEPROM у меня получается работать. Преимущество этих штуковин заключается в том,
что часть автоматики они берут на себя.
А вот когда mega vs mega.
Камешки разные. Тестирую обычно на мегах начиная с 8 до 128.



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

Неделя - уже утомительно. Две - внеземная технология. NACK.

С тем, что возвращаться к давно сделанному коду не особо приятно - целиком и полностью согласен.
Периодически писал довольно серьезные программы, правда на Delphi (стаж несколько лет), включая openGL, иногда переписывал с нуля.
На С что-то переписать обычно не сложно, просто нет гарантии, что пример был работающий и как минимум без особенностей.

Резюмируя: По сути дела с этим i2c нужен просто максимально ПОЛНЫЙ интерфейсник без специфических залипов к конкретному компилятору
(чтобы потом не переходить на другой) с кучей примеров, где камешки общаются промеж собой во всех режимах, посылают друг друга NACK.

Ограниченное использование i2c применительно к чему-то одному - естественно проще.

Сообщение отредактировал BeginnerAVR - Jun 3 2012, 15:22

Вот рабочий проект OSD на mega8. В нем реализован I2C slave.
Там есть то, что вам нужно - как два байта переслать

Тут круче даже. Можно юзать VGA дисплей, правда в разрешении CGA/EGA.
И даже буквы местные есть. Thanks.

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


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


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

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

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

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

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



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



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




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



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

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

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

Ещё про IIC.

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

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

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

Для изменения направления передачи, ведь при чтении сначала идет запись адреса, а потом уже чтение. А старт-стоп подразумевают определенный алгоритм, т.ч. это не одно и то же.

И что же, я не могу передать несколько рестартов? Могу. Кто из них тогда "старт" а кто "рестарт"? Нет разницы. И без "стопа" можно спокойно обойтись.

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



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

AVR310. Using the USI module as a I2C master on tinyAVR and megaAVR devices

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

Слейв - чего с него возьмёшь , получил 9 импульсов и рад , а то что один лишний , ему начхать. Мастер же даже не заметил , что кто-то сделал за него его работу и после NACK сформирует STOP.