Всем привет!

Настраиваю I2C между 2 устройствами на чипах LPC2131.
Один мастер, а другой ведомый.

Как ведомому сообщить мастеру, что у него есть информация важная ?

Чипы соединены только по I2C и других проводов протянуть нельзя.

Раньше надо было думать . Теперь только через заднепроходное отверстие заводя переключение режимов master/slave и наворачивая механизм логического разрешения коллизий. Или без I2C (EINT вместо SDA помнится вешалось) и опять думая о разрешении коллизий. А вообще, поскольку при нормальной реализации I2C затраты на его обслуживание не слишком велеки, то сканируйте slavе до опупения .

Еще как вариан:
Переключать пины на цифровой вход/выход и использовать их как флаги в две стороны:
--> мастер инициализирует связь
<-- слайф инициализирует связь

инициализация - переключение ног на модуль i2c, сброс флагоф, сеанс общения и опять переключение ног на цифровой вход/выход.
единственное, надо подумать как не попалить порты, т.к i2c sda с открытым коллектором а digital pin - комплементарная пара. Впринципи пожно просто резак включить

С матчастью LPC ознакомьтесь - это физически честный I2C - всегда OD и не засаживающий шину и при отсутствии питания.

Пока сделал сканирование, но не прикольно как то.

И в будущем на шине ещё могут устройства появится.
2 устройства - это временно.

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

Существенное ограничение. Даже теории нет по этому вопросу...

Уважаемый, Папа Карло, я бы Вам тоже рекомендовал найти дополнительную ножку у МК и пробросить
на нее МГТФ-ом сигнал со слейва. Решение будет крайне простое, недорогое, абсолютно понятное всем,
кто будет после Вас, и самое главное -- рабочее! А все остальное -- от Лукавого. Намаетесь больше, чем
заработаете денег.

Вам нужно ехать и ли Вам нужно "прикольно"?

Чтоб не создавать новый топик задам тут вопрос ещё по I2C.

Пытаюсь скачать Ведущем шины у ведомого данные.

Вот статусы ведущего:
08 40 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 58

Вот статусы ведомого:
A8 B8 B8 B8 B8 B8 B8 B8 C8

У ведущего запрос ведомому считать до 20 символов.
У ведомого в буфере строка из 7 символов для отправки ведущему.

Как я заметил, ведущий прекращает приём только после считывания максимальной длинны символов в 20 штук.
А ведомый отправляет, как и положено, 7 символов.

Объясните пожалуйста, как мне сделать, чтоб ведущий прекратил приём при окончании символов в буфере ведомого ?



Мне нужно "прикольно".
Я радиолюбитель !

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

P.S. А "радиолюбитель" обязательно предполагает реализацию не по-человечески?

А разве Ведущий может тактировать шину, если не получен АА.
Я так понял, что Ведущий качает данные, пока сам не прекратить или ведомый не выставит No Ack.

Есть 2 модуля и между ними только I2C шина. Навешивать сопли не мой вариант.

Если без соплей, то тогда остается либо только "неприкольное" сканирование на предмет готовности информации у слейва,
либо еще более "неприкольные" танцы с динамической конфигурацией портов и всеми вытекающими отсюда проблемами.

Что там у Вас происходит на шине и почему после получения бита NOT ACK Ведущий Мастер от Ведомого Слейва продолжает
тактировать, сложно сказать. Возможно, Вы что-то не так написали. Осциллографом не пробовали подловить картинку
передачи седьмого байта?

Осциллографа нет.
Могу выложить код ведомого:


Код ведущего:

А как же вот это на LPC2103:
I2C1.1I2C1 pins are not bi-directional GPIO pins
Introduction: There are two I2C interfaces, I2C0 and I2C1. I2C0 functions are shared as alternate functions on port pins P0.2 and P0.3. I2C1 functions are shared on port pins P0.17 and P0.18.
Problem: I2C1 pins are currently open-drain output pins but they should be regular bi-directional GPIO pins. I2C0 pins are configured as open-drain output pins (for I2C bus compliance).
Work-around: None.

?

Вы совсем не поняли что процитировали? Тогда перечитайте то, что отцировали из моего поста - считайте, что это краткий перевод.

тогда переведите вот эту фразу:
Problem: I2C1 pins are currently open-drain output pins but they should be regular bi-directional GPIO pins. I2C0 pins are configured as open-drain output pins (for I2C bus compliance).

Обясните что значить currently open-drain ...but ... should be regular bi-directional GPIO pins

Если имеется в виду что проблема с ними как с GPIO то тогда почему это озаглавленно как проблема i2c ?

А если это относится к i2с, то следует что там таки не OD на выход...

заметьте что для I2C0 специально указанно "for I2C bus compliance", те все-таки нужно полагать
что для I2C1 эта самая "compliance" просто отсутствует из-за баги...

Повторяю медленно и печально - это честные OD на выход. Посему они не похожи на остальные "обычные" GPIO, только это не баг а полезная (точнее обязательная) фича. На свежих LPC, правда, разумно (для внутриплатных необязательно) таким сделали только один из 2-3 I2C портов. Точно так-же правильно сделаны I2C, например, у PIC32. В отличие от Atmel-овских чипов.

вобще-то я задавал вопрос не чтоб указать на Вашу неточность а чтоб выяснить как оно на самом деле...
Но Вы совсем запутали...,
что из этого верно ?
- "это честные OD на выход."
- "На свежих LPC, правда, разумно таким сделали только один из 2-3 I2C портов."

то есть для LPC2103 таки I2C0 честный а I2C1 не совсем ?
А у AVR разьве не честный OD ?

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

Оба утверждения верны.

Первый эмулирует OD только если запрограммирован, как I2C. Нулевой по жизни OD, что позволяет исключить подсаживание им I2C шины и при отсутствии питания чипа. У обсужаемого 21xx оба I2C c железным OD, чем и было вызвано мое замечание в ответ на предупреждение об "опасности сжечь"....

По крайней мере у тех, с которыми имел дело - нет. У них и I2C тоже только похожий.

Не выясняя подробности Вашей реализации, могу предположить что NACK(Not ACK) Вы выставляете на последнем
байте, а нужно на предпоследнем...


как Вы все-таки уклончиво отвечаете..
Но суть понятна, для LPC2103 только I2C0 честный OD.
Только похожий ? "Эмуляция" OD ?
Как Вы себе представляете MultiMaster без честной OD ??? А он там реализован вроде как полностью...

Я уже перестал понимать, что Вы не понимаете . Вы совсем не понимаете, что "обычный" трехстабильный выход из-за наличия паразитного p-n перехода с высоколегированной области стока выходного p-канального транзистора на подложку чипа засадит шину. Поскольку ограничивает уровень на шине уровнем напряжения питания контроллера + ширина запрещенной зоны кремния.... При отсутствии питания это гарантированная неработоспособность. Честный OD, естественно, "верхнего" транзистора не имеет, как класс и этой проблемы нет.

я надеюсь что к моим умозаключениям про LPC2103 и их i2c вопросов нет ?
Очень красиво Вы все описали, только какое это имеет отношение к AVR ?
Я обычно вдумчиво читаю в таких сомнительных местах... :
• SCL/ADC5 – Port C, Bit 5
SCL, Two-wire Serial Interface Clock: When the TWEN bit in TWCR is set (one) to enable the
Two-wire Serial Interface, pin PC5 is disconnected from the port and becomes the Serial Clock
I/O pin for the Two-wire Serial Interface. In this mode, there is a spike filter on the pin to suppress
spikes shorter than 50 ns on the input signal, and the pin is driven by an open drain driver
with slew-rate limitation.
PC5 can also be used as ADC input Channel 5. Note that ADC input channel 5 uses digital
power.
• SDA/ADC4 – Port C, Bit 4
SDA, Two-wire Serial Interface Data: When the TWEN bit in TWCR is set (one) to enable the
Two-wire Serial Interface, pin PC4 is disconnected from the port and becomes the Serial Data
I/O pin for the Two-wire Serial Interface. In this mode, there is a spike filter on the pin to suppress
spikes shorter than 50 ns on the input signal, and the pin is driven by an open drain driver
with slew-rate limitation.

и даташиту я увы верю больше чем Вам...

Надо не "верить", а банально хоть чего-нибудь понимать. Вы не можете понять разницу между tri-state выходом эмулирующим open-drain у Atmel и реальным open-drain в применении к I2C шине , но это как-бы не мои проблемы.

Я Вас уже просил объяснить работу MultiMaster на "эмулируемых" open-drain,
ну вот и объясните как оно будет работать...

Еще раз, но уж точно последний - для уровней на шине I2C не превышающих текущее напряжение питание контроллера точно так-же, как и настоящий OD требуемый для I2C.

А в чем собственно разница ? только в том что LPC при питании 3,3V имеет 5V толерантные входы ?
вот для LPC:
VI input voltage 5 V tolerant I/Opins
[5][6] -0.5 +6.0 V
other I/O pins [5] -0.5 VDD + 0.5[7] V

вот для AVR:
VIH Input High Voltage except XTAL1 and RESET pins
VCC = 2.7V - 5.5V 0.6 VCC (2) VCC + 0.5 V

ну и в чем принципиальная разница кроме толерантности LPC к 5V ?

Давайте четко определим предмет спора.
в посте №20 Вы заявили что у AVR в режиме I2C работает "верхний" драйвер,
я же утверждаю что его там нет...
как будем проверять ?

Не говорите глупости, тем более не приписывайте их мне. Я говорил, то что говорил. Цитирую:

Где тут про "работает"? Просто присутствует и ввиду его присутствия имеется паразитный диод на подложку создающий проблемы.

Все. Утомился от многократного повторения элементарного.

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

Так, до Вас начало доходить. Продолжим - нет он не честный. Честный он (у производителей придерживающизся спецификации I2C ) такой:

А про другие I2C совместимые (тоже имеющиеся на борту того-же контроллера):

Сделать соответвующий протокол... Который будет следовать хотя бы трем основным пунктам:

1. Слейв первым байтом шлет длину сообщения, если нечего слать - соответвенно первым байтом шлет 0.
2. Мастер посылает NACK перед приемом последнего байта.
3. Когда слать больше нечего (сообщение полностью отправлено), Слейв всегда шлет GAP символ 0xA5 до тех пор пока мастер выдает ACK.
(выделенное - должно быть реализовано обязательно!)

т.о. даже если слейву вообще нечего слать, минимальная I2C транзация будет состоять минимум из двух символов - 0x0 (длина) и GAP (т.к. мастер перед приемом первого символа всегда выдает ACK).

По Вашему коду, конкретно по состояниям 0xA8 и 0xB8:

поменяйте на:






Не честный - во всех AVR. В обесточенном состоянии садят шину через защитные диоды (МК питается от шины ).

По вашему выходит, что минимальная транзакция будет довольно большая.
Но если ведомый не выставит на шину АА, что готов, то минимальная будет гораздо меньше, всего из 2 посылок, начало передачи статус 08 и конец передачи статус 0х48.
Может там ещё подводные камни есть ?

А что такое GAP и как на него должен Мастер реагировать ?

Посмотрел статусы в ДШ и складывается впечатление, что при начале приёма Мастером Ведомый уже не может прервать приём у Мастера.
АА Мастер смотрит только после пересылки адреса ведомого.

GAP - заполнитель пустых областей (напр при форматировании дискеты, межсекторные промежутки заполняются GAP символами). Мастер должен его отбрасывать, (при получении нулевой длины сообщения, это сделать не сложно - он просто не будет ничего складывать в приемный буфер).


Именно. Поэтому только так - как я описал выше.

Пока я сделал чуть по другому.
Если ведомому нечего передавать он снимает АА.
И ведущий, при запросе сам обрывает связь при не получении АА.

Если же ведомому есть что передать, то он ставить АА.
Ведущий делает запрос и получая длинну данных скачивает именно нужное кол-во.

Может при таком подходе GAP не обязателен ?
Уш очень не хочется загрузить шину зря.

политика "Abort" - не есть правильный подход.
(К слову про Abort'ы ;>, TCP можно сделать без состояний FIN_WAIT, FIN_WAIT2, CLOSE_WAIT, CLOSING, LAST_ACK, TIME_WAIT. Использовать тупо RST (connection abort) для разрыва соединения всегда, state машина упростится до безоразия и TCP будет прекрасно работать! Но это моветон!)

Ну и самое главное, - из диаграммки сигналов Slave-Transmitter'а видно, что ACK'и в шину Slave не посылает! ACK'и должен слать мастер . А раз ACK шлет мастер, то как Вы себе представляли "перекрыть" ACK=0, NACKом - высокоомным состоянием? Сбросив AA на слейве Вы только нарушите работу его машины состояний, что может привести к печальным последствиям, т.к. мастер-то об этом не знает.


Разница в 1 байт. Не уж-то так принципиально?

Подход при котором GAP не обязателен Вам уже описали выше - кинуть проводок на свободный GPIO пин и сигналить когда данные будут готовы к отгузке.

Если бы Вы сразу же высказались в том ключе что i2c на AVR не поддерживает полностью
спецификацию из-за защитных диодов то было бы сразу все понятно, это я и так знал,
но Вы завели разговор про "'эмуляцию" OD, чем совсем сбили с толку...

З.Ы. я так понимаю что I2C1 на LPC2103 это практически то же самое что и на AVR,
ну а I2C0 не будет держать шину и при отключенном питании.

Всё таки Мастер ждёт АА когда посылает адрес в шину и если ответа нет, то прекращает связь.
А Ведомый должен подтвердить, что он тут выдав АА на шину.
Вот, если Ведомый нашёлся, то Мастер уже переходит в режим приёма и тупо качает данные...

Хотите чтобы Slave пропадал с шины?!
Как вы тогда будете различать есть ли Slave на шине вообще, правильный ли задан адрес, или у слейва просто нет данных?

Вообще мне все равно, устройство ваше, как сделаете так и будет.

Всё таки сделал по вашему т.к., если МК перевести в режим Мастера, то он не сможет принять команды !

Ещё вопрос.

Я в прерывании I2C вызываю функцию для передачи статуса в UART.
Функция простейшая и ожидает пока освободится от передачи UART и записывает следующий символ в него.
Так если я вставляю функцию в обработчик, то передаётся с ошибками информация.

Из-за чего это может быть ?

Вероятно нельзя столько долго находиться в прерывании.
Организуйте очередь/кольцевой буфер для УАРТа - пишите в него без утомительных ожиданий.

В main-loop'е вычитывайте данные из этого буфера и отправляйте в UART.