[syoma 1]

Народ извините, в VHDL и Verilog ни бум бум, а надо пару строчек кода придумать.

 

Короче есть шина i2c, назовем ее А, которая одним концом (SCL, SDA) подключена к пинам FPGA, а на других висят несколько периферии - тактовый генератор, датчики температуры и питания. FPGA вроде как мастер.

 

Но также есть и еще одна I2C шина B, концы которой заведены на эту же FPGA, и которая управляется внешним МК. Помимо самой ФПГА на этой шине тоже висит еще несколько устройств.

 

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

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

 

В общем логика я думаю понятно. Вопрос в том - можно ли такое реализовать малой кровью и как? Спасибо.

[Maverick_ 15]

Народ извините, в VHDL и Verilog ни бум бум, а надо пару строчек кода придумать.

 

Короче есть шина i2c, назовем ее А, которая одним концом (SCL, SDA) подключена к пинам FPGA, а на других висят несколько периферии - тактовый генератор, датчики температуры и питания. FPGA вроде как мастер.

 

Но также есть и еще одна I2C шина B, концы которой заведены на эту же FPGA, и которая управляется внешним МК. Помимо самой ФПГА на этой шине тоже висит еще несколько устройств.

 

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

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

 

В общем логика я думаю понятно. Вопрос в том - можно ли такое реализовать малой кровью и как? Спасибо.

Ip core l2c не подходит?

[Bad0512 2]

Народ извините, в VHDL и Verilog ни бум бум, а надо пару строчек кода придумать.

 

Короче есть шина i2c, назовем ее А, которая одним концом (SCL, SDA) подключена к пинам FPGA, а на других висят несколько периферии - тактовый генератор, датчики температуры и питания. FPGA вроде как мастер.

 

Но также есть и еще одна I2C шина B, концы которой заведены на эту же FPGA, и которая управляется внешним МК. Помимо самой ФПГА на этой шине тоже висит еще несколько устройств.

 

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

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

 

В общем логика я думаю понятно. Вопрос в том - можно ли такое реализовать малой кровью и как? Спасибо.

Задачка не такая простая как кажется на первый взгляд. Надо как минимум парсить протокол I2C и переключать tri-state буфера в пинах в соответствии с протоколом. Если делать без парсинга, т.е "по-тупому" - будет deadlock.

 

[ZASADA 0]

в свое время распаралеливал шину I2C, ничего сложного нет, заняло несколько ячеек в cpld. но если делать по уму - надо поставить готовую дешевую микросхему, их навалом под разные конфигурации шины.

 

[LV26 0]

Задачка не такая простая как кажется на первый взгляд. Надо как минимум парсить протокол I2C и переключать tri-state буфера в пинах в соответствии с протоколом. Если делать без парсинга, т.е "по-тупому" - будет deadlock.

 

Абсолютно верно.

ТС надо мультимастер. Проще всего IP-core.

На OpenCores.org должно быть их.

 

2-й вариант (без мультимастеров) - использовать дополнительные пины (по одному на ПЛИС и МК) для

обмена статусом. Линия имеет подтяжку на питание. Если никто обмен не делает линия в 3-м состоянии

Тот кто хочет вылезти на линию смотрит уровень. Если 1 - интерфейс свободен, можно его брать. Мастер

на линию статуса ставит 0 и начинает обмен по И2Ц. Второе устройство не имеет прави вылазить, т.к. 0 на статусной линии.

 

Как-то так.

 

Можно упростить если использовать по 2 сигнала на ФПГА и МК.

[andreichk 0]

http://www.fpga4fun.com/I2C.html

проверено на связке 3 спартан и мк STM32

[Bad0512 2]

Абсолютно верно.

ТС надо мультимастер. Проще всего IP-core.

На OpenCores.org должно быть их.

 

2-й вариант (без мультимастеров) - использовать дополнительные пины (по одному на ПЛИС и МК) для

обмена статусом. Линия имеет подтяжку на питание. Если никто обмен не делает линия в 3-м состоянии

Тот кто хочет вылезти на линию смотрит уровень. Если 1 - интерфейс свободен, можно его брать. Мастер

на линию статуса ставит 0 и начинает обмен по И2Ц. Второе устройство не имеет прави вылазить, т.к. 0 на статусной линии.

 

Как-то так.

 

Можно упростить если использовать по 2 сигнала на ФПГА и МК.

Судя по описанию ТС, мастер в итоге у него будет всего один, то есть SCK можно тупо прокинуть от мастера на вторую шину.

Проблема в том, что направление линии SDA меняется в зависимости от чтения-записи и чтения ACK при разных операциях.

Поэтому и надо парсить протокол чтобы в соответствии с этим переключать направление SDA от мастера к вторичной шине и обратно.

В принципе одна стейт-машина, не так уж и сложно, но мозг включить придётся.

 

[iosifk 3]

Поэтому и надо парсить протокол чтобы в соответствии с этим переключать направление SDA от мастера к вторичной шине и обратно.

В принципе одна стейт-машина, не так уж и сложно, но мозг включить придётся.

Вообще стандартно ситуация разруливается так:

либо дешифрируется адрес и адреса делятся на две зоны. Первая зона адресов относится к одной шине, вторая - к другой. Соотв. переключение и выбор шин определяются адресами...

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

 

[alexadmin 0]

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

Единственное, надо пересэмплировать это все на достаточно высокой частоте, чтобы вносить задержку поменьше в линию передачи данных. Получается банальное управляющее устройство (даже конечным автоматом не назвать) на 3 состояния и 15 строк кода.

[Bad0512 2]

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

Единственное, надо пересэмплировать это все на достаточно высокой частоте, чтобы вносить задержку поменьше в линию передачи данных. Получается банальное управляющее устройство (даже конечным автоматом не назвать) на 3 состояния и 15 строк кода.

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

[syoma 1]

Я так подозреваю, что мне пытаются сказать, что в I2C есть переходы, когда мастер отпускает шину, а слейв должен ее держать - типа АСК в CANe. Тогда могут быть приколы.

Эх надо корку смотреть - просто родное IP core - это просто мастер I2C, и слейва там вроде нету. Конечно можно в итоге всю инфу от Плис к процу уже через PCIe передавать - но именно хотелось красиво оставить. Дело в том, что у меня несколько покупных плат - процессорная, Плис и еще периферия. По стандарту у каждой из них есть IPMB шина для диагностики. Эта шина независимая от всяческих PCIe и т.д. чтобы можно было читать диагностическую инфу от датчиков температуры, тока, напряжения на платах, как раз в случаях если основные камни по каким-то причинам не фурычат. На данный момент на ПЛИСовой карте развели вот такую фигню по непонятным причинам(я подозреваю изза тактового генератора для PCIe) который должен программиться из ПЛИС). Но они на эту де шину и диагностику подцепили, хотя она должна была идти напрямую на IPMB. Плату должны исправить, но непонятно когда, вот я и хочу так сделать, чтобы потом софт не переделывать.

Надеюсь понятно написал.

 

Мастер ессно один - процессор.

[svss 0]

Любопытная тема. Есть всё:

- Короче есть шина i2c, назовем ее А, которая одним концом ... висят несколько периферии ... вроде как мастер. ... приколы. .. корку ... инфу ... к процу

 

Наконец, после обсуждения, написаны таки четыре буквы:

IPMB

 

Отсюда выводы:

1. Multi-master redundant i2c.

2. Cовершенно не "ессно":

Мастер ессно один - процессор.

 

Простите за некропостинг, интересно узнать чем история закончилась?

[egorman44 0]

Если у Вас есть тактовая достаточно большая что-бы мониторить состояние на линиях SDA, то посмотрите здесь:

 

http://electronix.ru/forum/index.php?showt...mp;hl=egorman44

 

Соединял проц с eeprom через ПЛИС, файл прикрепил. Я так понял Вам просто проброс линии SDA необходим.

bus_controller_bypass.v