roboforum.ru

[blindman]

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

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

• Все устройства которыми можно управлять через шлюз, делим на 2 группы : подключенные по I2C и прочие
• Контроллеру назначается 1-байтный адрес, который является валидым I2C адресом
• Адресация в протоколе - двухбайтная. Если старший байт == 0, адресуется устройство на шине I2C, иначе - внутренний ресурс контроллера. В последнем случае старший байт адреса задает I2C адрес контроллера, младший - внутренний адрес ресурса
• формат команд ((W addr data+)|(R addr count))+ P. Тот же I2C, по сути.
• программа на шлюзе состоит из 2 частей - одна разбирает запрос, другая его исполняет и выдает ответ
• если контроллером надо управлять по I2C - оставляем на нем только ту часть, что отвечает за выполнение команд и выдачу ответа. А на управляющем устройстве используем тот же самый код, что и на шлюзе с одной маленькой модификацией - после разбора, те запросы, что идут к I2C-устройствам, идут непосредственно к ним, прочие транслируются контроллеру
• в процессе написания шлюза мы бесплатно получаем софт для устройства, которое будет мастером на I2C
• формат команд не зависит от канала связи. Код для управляющего I2C-устройства может быть с минимальными изменениями перенесен на ПК, и наооборот

----------------
Now playing: Rage - Human Metal (Radio-OMa)

Добавлено спустя 4 минуты 37 секунд:

blindman: то что ты предлагаешь очень похоже на 10-и битную адресацию I2C, только первый байт там имеет определенные значения.
И если реализовать 10-и битную адресацию, то мы вполне под каждый регистр можем занять адрес.
Кстати это избавляет нас от проблемы собственного адреса устройства и его хранения в eeprom
т.к. устройств понимающих 10 бит мало.

TWI не поддерживает 10-битную адресацию. Да она и не нужна - см. выше.

Но сам пакет менять не стоит, ты забыл IC (имхо нужная комманда)
V тоже полезна.

Элементарно реализуется в концепции регистров

----------------
Now playing: Amatory - Черно-белые дни (Radio-OMa)

[=DeaD=]

внесу чуть больше конкретики. Итак.

• Все устройства которыми можно управлять через шлюз, делим на 2 группы : подключенные по I2C и прочие
• Контроллеру назначается 1-байтный адрес, который является валидым I2C адресом
• Адресация в протоколе - двухбайтная. Если старший байт == 0, адресуется устройство на шине I2C, иначе - внутренний ресурс контроллера. В последнем случае старший байт адреса задает I2C адрес контроллера, младший - внутренний адрес ресурса
• формат команд ((W addr data+)|(R addr count))+ P. Тот же I2C, по сути.

Непонятно, к чему такие сложности с 2-байтной адресацией? Пытаемся сэкономить 1 байт в будущих запросах к локальным устройствам? А если рядом подчиненный такой же контроллер - на нём начинаем терять этот сэкономленный только что байт?

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

Мне просто кажется решение с 1-байтовой адресацией и унифицированным обращением как к локальному, так и к подчиненному контроллеру самоочевидным и не ясно - ради какого бонуса надо от такого красивого решения отклоняться

Добавлено спустя 34 секунды:
PS: В формате W/R....P нету мультистарта вроде?

[Vooon]

Ага, S то потеряли...
Хотя можно и по R/W посылать старт, тем не мение я за сохранение базового обмена userial.
Тут еще вопрос к чему драйвер раньше появится, у нас или у автора.
Другие опенсурсные USB-to-I2C укомплектованы драйверами, некоторые уже в ядре (i2c-tiny-usb).
Но у всех одна и таже проблема для нас — работа через «чистый» USB

[blindman]

=DeaD=, ну я не знаю, как еще объяснять чтобы понятно стало. Я уже и конкретные команды привел. Неужели не ясно что в моем варианте мы избавляемся от избыточной операции записи, что делает протокол более простым и удобным. Нам нужны только 2 операции - запись в устройство и чтение из него. А ты предлагаешь ввести фактически еще и операцию записи адреса.

Ты никак не хочешь понять, что единственное, но важное отличие моего подхода - это концептуальная простота. В нем нет избыточных операций. Есть чтение, есть запись - и все. Чтение - всегда чтение. Запись - всегда запись. Предельно просто и понятно. Ты же предлагаешь операцию чтения предварять еще и записью адреса, из которого читаем, причем делать это только для локальных устройств. Ну и где тут унификация?

Красота - понятие относительное, кстати

[=DeaD=]

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

По ходу мы друг друга не понимаем! Я не предлагаю только для локальных устройств что-то делать!

Пусть у нас есть контроллер, у которого в регистре 00 лежит информация по битам, которые надо выдать в первые 8 портов GPIO, при этом в нашей конструкции есть девайс на шине i2c с адресом 0x80 и девайс локальный с присвоенным по дефолту адресом 0x10, тогда выставление всех портов в 1 будет выглядеть как:

IS10W00FFP для локального контроллера

и как

IS80W00FFP для подчиненного по шине.

Итого отличие только в адресе. Вот это я и хочу, чтобы было.

Добавлено спустя 2 минуты 6 секунд:

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

Не понял, протокол i2c по своей спецификации сложнее. Если мы сделаем только 2 операции - отдельно чтение, отдельно запись - мы не реализуем всего множества доступных i2c-команд? Где мультистарт? Где чтение и запись в 1 команде?

[blindman]

Приведи тогда примеры команд для чтения с порта GPIO и для записи/чтения устройства I2C (отличного от самого шлюз-контроллера - скажем некий датчик).

Добавлено спустя 2 минуты 6 секунд:
Re: Обсужд. модулей Open Robotics - общие вопросы, распростр.

Не понял, протокол i2c по своей спецификации сложнее. Если мы сделаем только 2 операции - отдельно чтение, отдельно запись - мы не реализуем всего множества доступных i2c-команд? Где мультистарт? Где чтение и запись в 1 команде?

Устройство остается адресованным, пока не получен STOP или не адресовано другое устройство.

Добавлено спустя 7 минут 17 секунд:
В I2C за Start всегда следует R/W с адресом. То есть Start нам для описания формата команд не нужен - он подразумевается, и нужен будет только если мы обращаеися к устройству физически подключенному к I2C.

[=DeaD=]

Приведи тогда примеры команд для чтения с порта GPIO и для записи/чтения устройства I2C (отличного от самого шлюз-контроллера - скажем некий датчик).

А пример команд которые я привёл разве не закрывают этот вопрос? "IS80W00FFP" для подчиненного по шине - как раз запись устройства отличного от самого шлюз-контроллера. Скажем второй контроллер такой же, только подвешенный не по уарту напрямую, а по шине.

Пример чтения привести - видимо уже позже, вечером, не хочется в форуме днём просиживать за границей

То есть Start нам для описания формата команд не нужен - он подразумевается, и нужен будет только если мы обращаеися к устройству физически подключенному к I2C.

Вот это место мне категорически не нравится. Не должно быть отличий между физически подключенным и логически подключенным устройством, должен меняться только адрес. IMHO именно так строятся реально надежные и прозрачные системы (как пример - вебсервер работает с локальным mySQL так же как и с удалённым - по TCP/IP, хотя на 1 машине крутится всё). А если мы начинаем лепить отличия на каждом шаге - мы только плодим себе проблемы.

[blindman]

Пример чтения привести - видимо уже позже, вечером, не хочется в форуме днём просиживать за границей

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

Вот это место мне категорически не нравится. Не должно быть отличий между физически подключенным и логически подключенным устройством, должен меняться только адрес. IMHO именно так строятся реально надежные и прозрачные системы (как пример - вебсервер работает с локальным mySQL так же как и с удалённым - по TCP/IP, хотя на 1 машине крутится всё). А если мы начинаем лепить отличия на каждом шаге - мы только плодим себе проблемы.

А разве я говорю что будут отличия на уровне протокола? Все будет точно так же. И если уж рассматривать пример с TCP/IP, то и эти отличия как раз есть - и реализуются они на уровне драйвера устройства (которое кстати определяется по адресу). На верхнем уровне это конечно скрыто. Но и в моем протоколе эти детали на высоком уровне отсутствуют. Ты же моделируешь протокол на основе I2C, который может и вовсе в обмене участвовать не будет.

IMHO именно так строятся реально надежные и прозрачные системы

Ай, какой некрасивый прием в дискуссии Может создаться впечатление, что я предлагаю что-то ненадежное и непрозрачное.

----------------
Now playing: Андрей Макаревич и группа "Папоротник" - Пусть я не разгадал чудес

[=DeaD=]

А разве я говорю что будут отличия на уровне протокола? Все будет точно так же. И если уж рассматривать пример с TCP/IP, то и эти отличия как раз есть - и реализуются они на уровне драйвера устройства (которое кстати определяется по адресу). На верхнем уровне это конечно скрыто. Но и в моем протоколе эти детали на высоком уровне отсутствуют. Ты же моделируешь протокол на основе I2C, который может и вовсе в обмене участвовать не будет.

Погоди, на высоком уровне у тебя - это где?

IMHO именно так строятся реально надежные и прозрачные системы

Ай, какой некрасивый прием в дискуссии Может создаться впечатление, что я предлагаю что-то ненадежное и непрозрачное.

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

Давай я попробую сначала - пусть мы пока оставим за кадром конкретное символьное представление протокола.

Я предлагаю следующее:

По соответствию с предыдущим примером с TCP/IP и общающимися по нему веб-сервером и mysql-ем наш символьный протокол должен стать на место этого самого TCP/IP и передавать информацию как девайсу локальному, так и подключенному по шине i2c при этом делать это он должен унифицированно; (заметим, что для локальной машины может использоваться как предопределенный адрес 127.0.0.1, так и её реальный IP-адрес, например, 81.91.32.43, у нас это соответствует адресу назначенному локальному контроллеру);

При этом мне пока инвариантно какое символьное представление будет у протокола, но я поддерживаю Vooon'а в его предложении обеспечить 100% покрытие всевозможных команд i2c и считаю корректным отсутствие специальных команд для GPIO. Если можно в этот же формат впихнуть работу с SPI - я только за.

Скажи в каком месте мы начинаем расходиться?

Добавлено спустя 2 минуты 4 секунды:
PS: Если ты протестуешь против конкретного набора команд, который кажется в 95% случаев информационно избыточным - давай добавим в него еще команд, которые будут более компактные и уберут эту избыточность, но 100% i2c команд должно поддерживаться IMHO.

[bolt]

но 100% i2c команд должно поддерживаться

Извините, но I2C - это не набор команд, а протокол обмена информацией, в т.ч. и командами, между несколькими девайсами на общей шине. Имеет несколько стандартных скоростей и вариантов адресации. Поддерживается большинством МК и др. чипами на уровне железа.

[=DeaD=]

2bolt: Спасибо что просвятил, а то мы сидим тут и гадаем что такое I2C

[blindman]

Погоди, на высоком уровне у тебя - это где?

На уровне адресации и набора команд.

Скажи в каком месте мы начинаем расходиться?

В способе адресации и наборе команд. Аналогия с TCP/IP здесь очень удобна. Адрес определяет устройство, порт обычно связывают с конкретным сервисом. Мой двухбайтный адрес как раз можно рассматривать как комбинацию адреса и номера порта. Контроллер предоставляет ряд сервисов - порты ввода/вывода, SPI, управление моторами, управление сервами, конфигурация и состояние системы, диагностическая информация, и т.д. Каждому сервису мы ставим в соответствие номер регистра - это можно считать аналогом порта. И как раз тут обеспечивается прозрачность - запросы не к локальному контроллеру, а к подключенному скажем по I2C просто ретранслируются ему, и ответ возвращается запрашивающему устройству. И даже более того - можно ввести простую маршрутизацию, и менять конфигурацию подключенных устройств, например переключить подчиненный контроллер с I2C на ИК или радиоканал - причем полностью прозрачно, сохраняя адресацию и формат команд.

Команд нужно всего 2: чтение из регистра и запись в регистр, все прочие избыточны. Конкретному регистру соответствует определенный драйвер (опять же аналогия с TCP/IP - сервер, слушающий определенный порт).

PS: Если ты протестуешь против конкретного набора команд, который кажется в 95% случаев информационно избыточным - давай добавим в него еще команд, которые будут более компактные и уберут эту избыточность, но 100% i2c команд должно поддерживаться IMHO.

Я как раз не хочу плодить команды. И моя система из 2 команд (чтение/запись), во-первых, покроет 100% потребностей обмена со шлюзом, а во-вторых -- практически один в один мапится на I2C. Та же самая последовательность "адресация - чтение/запись". Мы закрепляем регистр 0 за I2C - и все. А разбираться когда и какие управляющие сигналы выдавать на шину будет ее драйвер.

[Duhas]

Dead, Vooon! blindman толковый вариант вам вталкивает ))

[=DeaD=]

Я как раз не хочу плодить команды. И моя система из 2 команд (чтение/запись), во-первых, покроет 100% потребностей обмена со шлюзом, а во-вторых -- практически один в один мапится на I2C. Та же самая последовательность "адресация - чтение/запись". Мы закрепляем регистр 0 за I2C - и все. А разбираться когда и какие управляющие сигналы выдавать на шину будет ее драйвер.

Погоди, у меня тогда такие вопросы есть:
1. Будет ли необходимость на стороне ПК писать драйвер?
2. Покроет ли эта система из 2 команд все возможные способы работы по шине i2c? Например позволит ли она делать мультистарт-запросы, читать из подряд идущих регистров и писать в них и т.п.?
3. Насколько хорошо, что людям, которые уже работали с i2c, мы ломаем концепцию работы и они теперь перестают понимать что реально будет проходить по шине i2c?
4. Не будет ли правильным сделать такой подход на более высоком уровне, а на уровне UART-обмена реального оставить предлагаемый Vooon'ом протокол?

[blindman]

1. Это зависит от того, что понимать под драйвером Позволь мне ответить вопросом на вопрос : а будет ли необходимость на стороне ПК писать драйвер в случае протокола используемого userial или различных его вариаций, предлагавшихся здесь? Ответ на эти вопросы один и тот же.
2. Да, без вопросов. Причем на самом деле это зависит не от протокола обмена, а от драйвера. Например, управляем 32 сервами. Можно выделить под это дело 32 регистра, при адресации любого из которых последовательная запись увеличивает номер регистра, а можно выделить под все один регистр, в который последовательно записывается 32 значения. Но это уже детали реализации драйвера, не зависящие от протокола.
3. Мы ничего не ломаем. Я же говорю, протокол напрямую мапится на I2C. На I2C любой запрос записи и чтения предваряется старт-состоянием - и те, кто привык к I2C прекрасно это понимают.
4. Думаю, что нет. Получим еще один уровень, единственная задача которого - переводить запросы из одного формата в другой. Это только добавит избыточные элементы, не несущие никакой полезной информации и не имеющие функциональной нагрузки.