Имеется система состоящая из Master receiver и Slave transmitter. Есл исходить из стандарта I2C, т количество передаваемых байт определяется мастером: при получении последнего байта он ставит NOT ACK, а передатчик получив его останавливает передачу. Мне же нужно чтобы количество передаваемых байт определялось передатчиком. С одной стороны, у него нет средств чтобы по своей инициативе остановить передачу - такты выдаются мастером. Но в описании Status Codes for Slave Transmitter Mode написано, что ведомый с передачей последнего байта может не установить TWEA и это будет означать, что передается последний байт. И есть status code 0xC8 означающий, что "Last data byte in TWDR has been transmitted (TWEA = “0”); ACK has been received". Так значит он может каким-то образом остановить передачу по своей инициативе? И как это происходит аппаратно, т.е. что выдается на шину?

Остановить? Точно также как и master - выдачей NAK. Как это аппаратно в МК реализуется я не знаю - не знаток AVR.

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

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

Сообщение отредактировал Kane - May 28 2010, 06:49

Или слейв первым байтом передает количество байтов в посылке. Некоторая неувязка будет с 0 - мастеру придется все же считать еще один байт, чтобы выдать NAСK.

Пардон. Не полностью вник в смысл вопроса. Штатными средствами не получается. Обычно в таких случаях (в EEPROM, например) slave передает некоторый объем данных из кольцевого буфера, размер которого master должен знать заранее.

Ваш slave работает в режиме "Ведомый передатчик" и может передавать данные сколько ему угодно. При передачи последнего байта , не забудьте сбросить бит TWEA , после чего передачик "впадёт" в состояние $C0 "думая" , что сейчас он получит NA , но получит естественно ACK , после чего уже и перейдёт в состояние С8 и будет гнать на шину SDA FFаки. Т.е сам то он остановится.
Мастер в регистре TWSR будет иметь скорее всего код 50 , т.е будет продолжать приём байтов. Можно попробывать отловить "неожиданный" пакет FF и сбросить мастер . Cам slave правильно остановить обмен не сможет , но он может "засадить" ,программно , шину SCL в 0 , после чего уже мастер не получив нормальный код ответа прекратит передачу. Не правильно это, но попробывать можно.

Как мило, оказывается модераторы перенесли тему в "интерфейсы"! А то, что она называется I2C в AVR - это ничего? И вопрос был именно о коде состояния "Last data byte in TWDR has been transmitted", имеющейся только в AVR? И, конечно, в раздел для начинающих - после того, как она сутки провисела в разделе AVR и на нее пришел только один ответ - да, значит только начинающие могут рассказать о тонкостях в кодах состояния контроллера I2C!


Спасибо, я тоже наконец прочитал. Сам он остановится, но мастер об этом не узнает. То есть сбрасывает TWEA он для самого себя.

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


А вдруг FF будет среди байтов данных?

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

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

Почему к противоречию? К противоречию придём только тогда, когда окажется, что источник данных невозможно сделать мастером.
А сейчас есть только то, к чему я склоняюсь в последнее время -- сделать всех "с мозгами" мастерами, превратить для них шину во write-only, они ничего не читают, только пишут. Нужно "нынешнему мастеру" что-то -- он посылает "нынешнему слейву" короткую команду "хочу то-то" и уходит с шины. "Нынешний слейв" переключается в мастера и отправляет известное ему количество информации тому, кто попросил. По загрузке шины практически то же - вместо передачи RESTART + SLA_R имеем передачу STOP+START+SLA_W

Кстати, уходит и обсуждаемая рядом тема растяжки SCL ещё не готовым "нынешним слейвом" - шина свободна, он передаст когда сможет.
Write-only шины -- правильная вещь в некоторых случаях.

1. Это короткое будет START SLA+W и дальше "Я Х О Ч У Э Т О" , слейв всё таки должен как -то в потоке данных расшифровывать , когда данные , а когда "ХОЧУ" т.е он должен анализировать каждый принимаемый байт и определять к данным или "ХОЧУ" он относится. Т.е на анализ уйдёт кучка времени.
2. Он ещё как-то должен выяснить , а кому собственно послать то?
Значит , либо мастер передаёт свой SLA , либо став мастером "бывший" слейв начинает выяснять , кто хотел данные , ау!

Да, я тоже думал сделать так. Но... страшно


Почему каждый? Можно сделать первый байт командным и в нем кодировать "что хочу" и "кто хочет". Кроме того, можно сделать чтобы контроллер отвечал на несколько адресов, для этого в регистр TWAMR записывается битовая маска, показывающая, какие биты будут игнорироваться при сравнении с приходящим адресом. Например, если записать 0x1e, то он будет отвечать на 16 адресов, а младшие 4 бита могут быть любыми. Их можно использовать для передачи адреса запрашивающего устройства ("кто хочет").

Пока у меня I2C "было мало", я об этом и не задумывался. Но сейчас висит на основном процессоре десяток слейвов и уже прото неприлично выглядит выдача команд а потом опрос по кругу -- кто же готов, чтобы из него вынуть информацию и пнуть дальше. Шина постоянно занята тупым опросом. Сейчас уже доделаю как есть, оно должно работать, а потом переделаю на мультимастер и сравню ощущения.
Будет время, почитаю (до этого только проглядывал) спецификации ACCESS.bus. Хотя там, пожалуй, несколько перенавороченные протоколы ввид универсальности шины.

Именно так.
Кстати, в заменителе системы с одним мастером _не_нужно_ выяснять -- кому же понадобились данные. Они понадобились "бывшему единственному мастеру" и его адрес может быть жёстко выделен на этапе проектирования системы. У меня при переделке так и будет -- пульт реально один.
А так -- нет никаих проблем в формате данных в пакетах с комадой "дай" завести поля "вот-это" и "вон-тому", причём "вон-тому" может и не совпадать с адресом того, кто выдал саму команду.

777777, почитайте спецификацию ACCESS.bus. Может чем-то вам поможет.

Какая-то ситуация не совсем логичная для I2C. Не понимаю , что мешает слейву , который готов отдать данные , назначить cебя мастером , захватить шину и передать данные. Пусть у Вас все будут слейвами , до тех пор пока они не готовы выдать информацию для остальных или основному процессору. Любое устройство ,с "мозгами", может быть мастером и слейвом и в зависимости от Вашей программы может работать в этих двух режимах.
А если Ваш слейв , от которого требует мастер данные , просто не готов их ему дать , занят он чем то другим? Причём может быть более важным , чем общение с мастером. Мастер при этом вместо того что бы выполнять свою работу тупо ждёт получение данных от этого слейва , когда , например, остальные уже готовы дать ему информацию и продолжить свою работу.


Вы посчитайте этот формат. И при этом посчитайте , что слейв должен отличать на шине команду ("дай" "вот-это" и "вон-тому" ) от просто данных , которые ему может посылать мастер. Поэтому нужен ещё и префикс , что идёт команда , а не данные. А в диапазоне 8 бит , очень сложно ( а практически невозможно) найти свободное число для префикса команды, т.к. любое число в одном байте можно интерпретировать как данные и как команду. Поэтому потребуется не один байт , а несколько , которые слейв "сложит" в понимание , что получает команду. И тут время опять удлиняется, слейв должен "расшифровать" , что он получает.