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

Объясните, люди добрые, новичку, что и как...
Два 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 применительно к чему-то одному - естественно проще.

Вот рабочий проект 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"

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



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



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




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



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

Это вряд ли. Я тогда искал как сделать, чтобы окно, сделанное в 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.

Что значит "во время 9 импульса"? В жизни он увидел окончание 8 импульса и поставил свой АСК. Это в талмудах только данные так красиво меняются посерединке между синхроимпульсами.

Т.е плюнул на всех разработчиков шины и как захотел так и стал работать. Вы путаете работу мастера с привязкой CLK. Для себя мастер сформировал все 9 тактов , физически slave получил 8 и не ответил мастеру ACK , но т.к. мастер освободил шину SDA - лог.1 в момент 9-го импульса, то теперь SDA принадлежит slave - нет конфликта встречных выходов . И по своему 9 импульсу он получит NACK . И взависимости от заданной Вами программы обработки ошибки выполнит какое-то действие.
В работе в режиме чтения , после выдачи адреса с режимом чтения, мастер освобождает шину , но продолжает выдавать clock , по которым slave выдает данные на шину, затем мастер на 9-ом перехватывает шину и шлёт ведомому ACK или NACK. Данные на шине считаются верными только в течении high длительности импульса.
Но все эти обработки ack и nack нужны в большенстве случаем , когда мастер общается с себе подобным устройством. Когда с обеих сторон есть возможность принять действия к "откату" и повтору с наименьшими потерями. Для простых slave легче сформировать Stop и повторить обмен, если данных от него не много.

Вопрос по библиотеке AVRLab.

Функция i2cSlaveTransmitService в интернетах встречается везде в практически неизменном виде.



Вопрос в слеующем: сколько бы не отправлял запросов от мастера, слейв отвечает,
правда байтами 0xFF на всю длинну массива. master акает и, естественно, выводит массив из 0xFF.
Пробовал заполнять localBuffer и в самой функции и до ее вызова.
В чем может быть проблема?

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


Ответил! По окончании 8-го импульса он выставил ACK низким уровнем на линию данных. И ждёт 9-й импульс, по его окончанию он снимет этот свой АСК. А не дождётся: пропал импульс, сгинул в дороге.


Здесь точно не помню, но опять-таки, если мастер и слейв сбились в подсчёте импульсов, то может возникнуть ситуация, когда слейв выдаёт нулевые биты, мастер ставит свой NAK, но в это время слейв передаёт 0. Слейв видит АСК и может держать линию данных как угодно долго, ожидая синхроимпульсов. Мастер, наверное, должен проверять свой собственный NAK, установился ли (через какое время? ёмкость линии никто не отменял). Не установился, что ему делать? Предлагают передать 9 синхроимпульсов и молиться.


Я всё о наболевшем: слейв держит линию данных и не отпускает, какой стоп?
Кстати, если всё прекрасно, откуда взялось понятие "Soft reset" ?

Понимаю, что я уже становлюсь здесь лишним.

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

Может прокомментируете по поводу многократных 0xFF?

1. Проверьте не перепутали подключение SDA SCL не только глазами и правильность подключения но и тестером если печатка с переходами
2 Скорость шины
Сформируйте только старт - проверьте ответит 0x08

Для Maik-vs



Ну это я проэммулирую , когда вернусь с дачи .
Слава богу , что мастер не ставит NACK. за него это делают pull-up резисторы. Но давайте забудем про внешнии clock и вспомним , что они лишь проявление того , что происходит унутри мастера.
А внутри у него всё хорошо все 9 импульсов он сформировал и получил ACK.

Откуда взялось, ну точно не знаю , но было это давно. Помнится применял ещё на I8048, надо покапаться в старых тетрадях. Сейчас , я лично его использую при выходе из MENU.

С правильностью подключения и скоростью все в порядке.
Slave на прием работает как часики, но выдает только 0xFF

Я так понимаю , что вы хотите релизовать режим , при котором мастер после запроса становился "ведомым приёмником" судя по

Тогда надо чуть-чуть изменить init мастера после запроса. Присвоить ему адрес ( хотя у Вас их только два проца) тогда проверьте TWAR - там должно быть 0х00 и TWGCE - установите в 1 - отзываться на всё что только можно. Далее slave должон передать адрес с префиксом W)- запись (закрепить своё превосходство ну и далее согласном протокола slave to master два байта.

Ой забыл , ещё в TWCR мастера= 1<<TWEA|1<<TWEN

Slave уже может стучаться к мастеру , но будет получать NACK , поэтому придётся подождать пока slave не получит ACK , а уж затем слать. Что собственно он может сделать когда ему заблагорассудится

Спасибо. Пошукаю до флажков через UART. Если Вам доводилось писать что-то с i2c, Вы пользовались какими-либо библиотеками?

Много , но преимущественно на asm , там всё просто и до предела ясно что происходит. Поищите поиском по форуму , может кто-то реализовывал такой режим на С . Я так особо не приглядывался.
Но алгоритм прост , можете и сами написать.
Мастер
1. Отослать запрос
2 TWAR= 0x01
3.TWCR = 1<<TWEA|1<<TWEN
Занятся чем либо полезным, если включено прерывание TWI или мониторить TWSR на код $70 и если =
4.TWCR = 1<<TWEA|1<<TWEN|1<<TWINT
Занятся чем либо полезным, если включено прерывание TWI или мониторить TWSR на код $90 и если =
5. Считать данные
TWCR = 1<<TWEA|1<<TWEN|1<<TWINT
Занятся чем либо полезным, если включено прерывание TWI или мониторить TWSR на код $90 и если =
5. Считать данные.
Теперь главное!!!
Отключить TWI , что бы slave не наглел.

вернуть к исходному состоянию мастера - чисто библиотека ATMEL.
Можно мониторить TWCR- состояние бита TWINT - а затем читать TWSR на код статуса.

Slave
1. Получить запрос
2 . Оценить возложенную на него ответственность и подготовить 2 байта , если их ещё нет
3 . Ну далее тоже по библиотеке , он теперича мастер.
4. Отослать 2 байта.
5 Вернуть себе статус slave - обидно конечно.


Но честно говоря не совсем понятно , если уж мастер спокойно записывает в slave, то и читать по префиксу чтение должен тоже спокойно. Смотрите , как у Вас обрабатывается запрос от мастера на чтение данных . Может он не из той ячейки берёт данные , а тама токмо $FF

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

Если четно, то мне очень стыдно за свой полный тупизм с i2c.
И, самое удивительное, не удалось найти гарантированно рабочих примеров с полнофункциональным слейвом под avrlib.
Единственное, что нашел - рукописный пример на easyelectronics, правда в обрамлении RTOS.
Мне советуют атмеловские аппноты.
Вот и думаю что делать...
1. выковыривать изюм из булки RTOS
2. взять за основу аппноты
3. начать писать свое, поглядывая на все нагугленное?