roboforum.ru

Ну хоть бы ключевые слова какие сказали, а то я так себе и представляю - захожу сейчас в google и пишу строку поиска "аналогичные решения"

Ну это я так, поплакался, в общем вот что накопал:

1. КТЦ-МК (http://www.cec-mc.ru/) пользует такую распиновку 1-GND, 2-SDA, 3-VCC, 4-SCL.
2. вот и всё.

Не так давно тоже искал http://www.i2cchip.com/i2c_connector.html#Our%20Pinout

Всякие Devantech'и вообще в разных устройствах разный порядок выводов практикуют. Такое ощущение, что издеваются над пользователем будущим.

Это не для RJ-11, да и ничего внятного там не написано, как раз "одни так делают, другие вот так..."

чем больше сгорает тем больше покупают...  бизнес-с

V? заменяем для унификации на команду нижеприведенного вида с адресом FF:
NjjTFFLP{nl}, - запросить тип и версию устройства с адресом jj (4 байта - первые два = производитель, затем тип устройства, затем версия);
Пример - N01TLP{nl} - Запросить тип устройства с адресом 01;
Пример ответа - N01TFFL00P{nl};

Немного подумал

И решил что мне вместо сложной системы команд которую юзают товарищи вот отсюда: http://www.emicros.com/i2c232.htm  хватит на первое время простой команды - отправить устройству X запрос на запись 0..63 байта и тут же не посылая STOP-маркер послать запрос ему же на чтение 0..63 байтов. Этим закрывается наверное 99% всех типов запросов ходящих по шине I2C (в том числе я смотрел как работают устройства сторонних производителей), и пока я реализую этот упрощенный протокол, а затем все желающие смогут реализовать полный протокол, или у меня руки дойдут.

а rj11  допускает 1 А ?

Еще как
http://www.promelec.ru/lines/conn_9_1.html
http://www.promelec.ru/lines/conn_9_4.html

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

А если силовому блоку не надо больше 1А, то просто надо из блока-питания шлейф на него напрямую выводить и тогда блок-питания будет своеобразным хабом

Итак попробуем собрать всё что получилось в одном месте:

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

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

Далее информация не для тех, кто не знает электронику или неумеет программировать МК, то есть для потенциальных соучастников проекта

Основные принципы построения это системы модулей:

1. Каждый обычный модуль системы построен на базе МК (неважно AVR/PIC/?) и является I2C-slave'ом;

2. Один из модулей (далее - шлюзовый модуль) снабжен также интерфейсом RS-232 и является I2C-мастером, этот модуль обязан транслировать поступающие ему через RS-232 команды в шину I2C и посылать обратно ответ, либо выполнять эти команды самому. Никакой другой информации по RS-232 кроме как команды для I2C и ответы на них не передается. 7-битная адресация 00..7F позволяет забрать этому модулю на себя до 128 оставшихся адресов I2C-шины - 80..FF;

3. Вместе с I2C шиной все модули получают базовое 5В питание общим током до 1А на вывод от модуля питания (то есть если сделать звезду от модуля питания, то можно будет хоть 1А на каждый модуль подать);

4. На ПК есть низкоуровневой драйвер порта (базовые функции ввода/вывода), есть диспетчер запросов (разделение порта между всеми желающими использовать), и есть библиотеки-обертки поддерживающие функционал каждого модуля.

Спецификация на разъемы:
RS232:
- На компьютере известно - DB9M;
- На шлюзовом модуле - DB9F
- Соединительный кабель - DB9F-DB9M - обычный удлинитель для COM-порта;

I2C:
- на модулях - розетки RJ-22 (TP4P4)
- соединительный кабель - вилки RJ-22 (TP4P4) на обоих концах

Спецификация на протокол передачи I2C-запросов и ответов на них поверх RS-232:

Замечения:
1. [cr] - символ с кодом 10 - новая строка);
2. Все байты данных и адреса, предназначенные для передачи по I2C-шине, передаются по RS-232 в виде HEX - пары байтов (например "41" переданное в данных по RS-232 будет передано как "A" в данных по I2C).

Qaarr(ww)*[cr] - Унифицированная команда запроса к I2C-шине, где:
* aa - адрес устройства (00..FF);
* rr - количество байт к получению из устройства (00..40);
* (ww)* - байты к передаче на устройство перед чтением с него;

Xee(t)*[cr] - Унифицированный ответ об ошибке при попытке выполнить запрос к I2C-шине, где:
* ee - код ошибки (00..FF);
* (t)* - текст сообщения (обычными символами - не HEX);

R(aa)*[cr] - Унифицированный успешный ответ на запрос к I2C-шине, где:
* (aa)* - байты полученные с устройства (сколько просили в запросе);

Пример №1:
Запрос: QFF000101[cr] - передать I2C-устройству с адресом FF два байта - 01,01 и после этого запросить 00 байт.
Ответ: R[cr] - ответ об успешном выполнении команды.

Пример №2:
Запрос: УFF000101[cr] - кривой запрос.
Ответ: X01Wrong command[cr] - сообщение об ошибке.

Пример №3:
Запрос: QFFA0[cr] - запросить с I2C-устройства с FF адресом A0 (160) байтов.
Ответ: X01Too many bytes to read[cr] - сообщение об ошибке.

Пример №4:
Запрос: QFF018101[cr] - передать I2C-устройству с адресом FF два байта - 81,01 и после этого запросить 01 байт.
Ответ: R01[cr] - ответ об успешном выполнении команды и один запрошенный байт.

За развитием проекта в городе Санкт-Петербург вы можете наблюдать здесь http://quark-bot.blogspot.com/

Черт, до чего ж оно напоминает мне мои родные крейтовые системы... Там SPI - тут I2C, там USB - тут RS-232... Тут 1 ампер - там 5 линий питания - до 20 ампер разного напряжения... Пока-что аналогии во всем! И диспетчер канала обмена и адресация и переброска команд... В общем - так держать, верным путем идете, товарищи!  :wink:

Что есть крейтовые системы?

А вообще я ничего особо не придумывал - с тем же успехом любой USB контроллер садящийся на шину PCI так же работате - преобразует прозрачным образом интерфейс и дает питание