Вызов мастера в I2C чип LPC2131 Опции

[Папа Карло]

Всем привет!

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

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

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

[zltigo]

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

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

[MaxEngee]

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

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

[zltigo]

надо подумать как не попалить порты, т.к i2c sda с открытым коллектором а digital pin - комплементарная пара.

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

[Папа Карло]

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

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

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

[zhevak]

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

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

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

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

[Папа Карло]

Чтоб не создавать новый топик задам тут вопрос ещё по 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 символов.

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

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

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

[Lelikk]

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

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

Чтоб не создавать новый топик задам тут вопрос ещё по 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 символов.

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



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

[Папа Карло]

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

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

[zhevak]

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

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

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

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

[Папа Карло]

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

Код

    case 0xA8://own SLA+R received, ACK returned (slave transmitter)
    case 0xB8://Data transmitted, ACK received
        if(i2c_size--)                  // if not last data byte transmitted
            {
            I2C0DAT = *i2c_data++;      // send next data byte
            I2C0CONSET = 0x04;//
            }
        else
            {
            I2C0CONCLR = 0x04;//
            i2c_stat   = 0;             //
            i2c_size = 0;
            }  
        break;
    case 0xC8://Last data transmitted, ACK received
        I2C0CONCLR = 0x04;//
        break;

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

Код

        case 0x50:
            *i2c_data++ = I2C0DAT;                  //
            i2c_read = 1;
            if(--i2c_size)                          // if not last data byte received
            {
                I2C0CONSET = 0x04;                  // set ACK bit
                I2C0CONCLR = 0x10;                  // clear "STOP" state
                   I2C0CONCLR = 0x20;                  // clear "START" state
            }
            else
            {    
                I2C0CONCLR = 0x04;                  // reset ACK bit
                I2C0CONCLR = 0x10;                  // clear "STOP" state
                   I2C0CONCLR = 0x20;                  // clear "START" state
                i2c_stat   = 0;                     // send transfer end flag
            }
            break;
        case 0x58:                                  // slave address and RD bit transmitted. ACK not received. Data read.
            I2C0CONSET = 0x10;                      // send "STOP" state
            I2C0CONCLR = 0x20;                      // clear "START/RESTART" state
            i2c_stat   = 0;                         // send transfer flag
            break;

[singlskv]

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

А как же вот это на 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.

?

[zltigo]

?

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

[singlskv]

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

тогда переведите вот эту фразу:
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" просто отсутствует из-за баги...

[zltigo]

тогда....

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

[singlskv]

Повторяю медленно и печально - это честные OD на выход.

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

то есть для LPC2103 таки I2C0 честный а I2C1 не совсем ?

В отличие от Atmel-овских чипов.

А у AVR разьве не честный OD ?

[Папа Карло]

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

[zltigo]

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

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

то есть для LPC2103 таки I2C0 честный а I2C1 не совсем ?

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

А у AVR разьве не честный OD ?

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

[singlskv]

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

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

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

как Вы все-таки уклончиво отвечаете..
Но суть понятна, для LPC2103 только I2C0 честный OD.

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

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

[zltigo]

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

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

[singlskv]

я надеюсь что к моим умозаключениям про LPC2103 и их i2c вопросов нет ?

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

Очень красиво Вы все описали, только какое это имеет отношение к 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.

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

[zltigo]

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

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

[singlskv]

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

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

[zltigo]

ну вот и объясните как оно будет работать...

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

[singlskv]

Еще раз, но уж точно последний - для уровней на шине 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 работает "верхний" драйвер,
я же утверждаю что его там нет...
как будем проверять ?

[zltigo]

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

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

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

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

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

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

[singlskv]

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

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

[zltigo]

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

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

I2C0 input/output. Open-drain output (for I2C-bus compliance).
Open-drain 5 V tolerant digital I/O pad, compatible with I2C-bus 400 kHz specification. This pad requires an external pull-up to provide
output functionality. When power is switched off, this pin connected to the I2C-bus is floating and does not disturb the I2C lines.

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

I2C1 input/output (this is not an open-drain pin). Open-drain configuration applies only to I2C function on that pin.

[defunct]

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

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

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

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

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

Код

case 0xA8:
case 0xB8://Data transmitted, ACK received
        if(i2c_size--)                  // if got no more data to send not last data byte transmitted
            {
            I2C0DAT = *i2c_data++;      // send next data byte
            I2C0CONSET = 0x04;//
            }
        else
            {
            I2C0CONCLR = 0x04;//
            i2c_stat   = 0;             //
            i2c_size = 0;
            }
break;

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

Код

case 0xA8: // SLA+R (slave transmitter start)

    if(!i2c_size)                 // NO DATA TO SEND?
        I2C0DAT = 0;          // Notify Master - we have no data
    else
        I2C0DAT = i2c_size;   // send message len
    I2C0CONSET = 0x04;            // enable ACK for data byte
    break;

case 0xB8: //Data transmitted, ACK received

    if(!i2c_size)              // NO DATA TO SEND?
        I2C0DAT = 0xA5;          // MUST send GAP data byte
    else
    {
        i2c_size--;
        I2C0DAT = *i2c_data++; // send next data byte
    }
    I2C0CONSET = 0x04;             // enable ACK for data byte
    break;

А у AVR разьве не честный OD ?

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

[Папа Карло]

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

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

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

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

[defunct]

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

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

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

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

[Папа Карло]

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

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

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

[defunct]

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

политика "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 на слейве Вы только нарушите работу его машины состояний, что может привести к печальным последствиям, т.к. мастер-то об этом не знает.

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

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

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

[singlskv]

Так, до Вас начало доходить. Продолжим - нет он не честный.

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

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

[Папа Карло]

из диаграммки сигналов Slave-Transmitter'а видно, что ACK'и в шину Slave не посылает!

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

[defunct]

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

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

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

[Папа Карло]

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

Ещё вопрос.

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

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

[defunct]

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

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

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