roboforum.ru

1. Будет ли необходимость на стороне ПК писать драйвер?

Ес-но! Ботом ведь управлять надо. И протокол здесь уже не I2C, поскольку канал беспроводный.

2. Покроет ли эта система из 2 команд все возможные способы работы по шине i2c?

Сам I2C протокол предусматривает различные варианты работы. Другое дело, что при избыточности свободных пинов на любом из модулей системы в I2C и адресации нет необходимости.

...мы ломаем концепцию работы и они теперь перестают понимать что реально будет проходить по шине i2c?

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

blindman писал(а):1. Это зависит от того, что понимать под драйвером Позволь мне ответить вопросом на вопрос : а будет ли необходимость на стороне ПК писать драйвер в случае протокола используемого userial или различных его вариаций, предлагавшихся здесь? Ответ на эти вопросы один и тот же.

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

blindman писал(а):2. Да, без вопросов. Причем на самом деле это зависит не от протокола обмена, а от драйвера.

Так всё-таки драйвер обязателен? Или если нет - тогда как тут быть?

blindman писал(а):3. Мы ничего не ломаем. Я же говорю, протокол напрямую мапится на I2C. На I2C любой запрос записи и чтения предваряется старт-состоянием - и те, кто привык к I2C прекрасно это понимают.

Как он мапится? Как мультистарт запрос сюда подцеплять, когда запись и тут же чтение ответа? Объявлять транзакцию? Мы ведь на ПК будем писать, тут потоки бывают независимые и им всем захочется потрогать наш i2c

blindman писал(а):4. Думаю, что нет. Получим еще один уровень, единственная задача которого - переводить запросы из одного формата в другой. Это только добавит избыточные элементы, не несущие никакой полезной информации и не имеющие функциональной нагрузки.

А не корректней для начала не придумывать что-то своё, а сделать проверенное, то что 100% понятно как должно работать и проверено людьми, что 100% работает во всех ситуациях?

=DeaD= писал(а):Ничего подобного - не один и тот же ответ, в случае с USERIAL мы получаем инвариантность формата запроса от адресуемого устройства, а тут нет. А значит либо драйвер обязателен, либо перекраивать программу при переходе от устройства на шлюз-контроллере к устройству на подчиненном контроллере, третьего не дано.

Я же вроде доступно объяснил, что формат запросов всегда один и тот же, и никак не зависит от способа подключения устройства. Мне сказать тут больше нечего, попробуй еще раз прочитать viewtopic.php?f=69&t=5581&start=15#p88557 . Я вот понять не могу, что такого волшебного в USERIAL?

=DeaD= писал(а):Так всё-таки драйвер обязателен? Или если нет - тогда как тут быть?

Да. На стороне шлюза обязательно будет драйвер. То есть программа, знающая как общаться с конкретным устройством. И заметь - этот драйвер будет там всегда, какой бы протокол команд не был выбран.

=DeaD= писал(а):Как он мапится?

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

Код: Выделить всё

Мой протокол         I2C
=============================
R ADDR               S ADDR R
W ADDR               S ADDR W
P                    P

Как видим, соответствие между элементами протокола однозначное

=DeaD= писал(а):Как мультистарт запрос сюда подцеплять, когда запись и тут же чтение ответа? Объявлять транзакцию? Мы ведь на ПК будем писать, тут потоки бывают независимые и им всем захочется потрогать наш i2c

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

=DeaD= писал(а):А не корректней для начала не придумывать что-то своё, а сделать проверенное, то что 100% понятно как должно работать и проверено людьми, что 100% работает во всех ситуациях?

А вот это мне странно от тебя слышать Как раз потому, что понятно как это работает - понятно, как это можно улучшить и упростить. Решения, принятые "для начала", зачастую остаются постоянными, а когда хочется что-то улучшить - приходится все ломать.

Т.е. мультистарт у тебя тоже в 1 запросе идёт, только вместо SaaWxxSaaRxxP у тебя WaaxxRaaxxP - так?
А адрес у тебя сколько байт? 1 или 2? Меня по сути два пункта волнует больше всего - наличие мультистарта и адресация, остальное не критично.

2Vooon: кстати, а ты чего не участвуешь в обсуждении?

=DeaD= писал(а):Т.е. мультистарт у тебя тоже в 1 запросе идёт, только вместо SaaWxxSaaRxxP у тебя WaaxxRaaxxP - так?

Совершенно верно.

=DeaD= писал(а):А адрес у тебя сколько байт? 1 или 2? Меня по сути два пункта волнует больше всего - наличие мультистарта и адресация, остальное не критично.

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

Про мультистарт - ок, 50% вопросов снимается

А про адресацию - правильно ли я понимаю, что при таком подходе мы экономим 1 байт на запросах к локальному контроллеру (встроенному в шлюз-контроллер) и теряем 1 байт на запросах к подчиненным по i2c контроллерам?

при адресации встроенного контроллера сразу передаём регистр и данные, а при адресации подчиненного - 0, адрес, регистр - так?

PS: Ненавижу загадочный чешский интернет, почти всегда только половина сайтов работает, периодически вообще ничего не работает

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

С таким протоколом есть проблема с определением какие команды нужно послать подчиненному I2C шлюзу.

Такая посылка одинакова будет и для i2c и для usart'а:
S aa W ss dd dd dd S aa R cc P

А в твоем варианте потребуется дополнительно разбираться что же нужно послать в случае i2c.

А "в твоем" - это чьем?

2 blindman в твоем варианте

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

Добавлено спустя 19 минут 18 секунд:
Я видимо недостаточно четко выразился, есть один момент, который мне кажется очевидным : в случае подключения шлюза по I2C я рассматриваю I2C просто как транспорт для доставки команд шлюзу и получения ответов. Детали общения по I2C нас не интересуют - мы описываем протокол высокого уровня, который не должен зависеть от транспорта.

Ребят, я последнее время совсем редко и ненадолго заглядываю Вот и сейчас внимательно вчитаться нет времени.
Если надо, могу вечером запостить вордовский документ с описанием протокола для и2с - с год назад прорабатывал вариант и2с-бэйсед протокола для интеллектуальных устройств, чтоб он совместим был с простыми устройствами и2с. До конца, правда, разработку не довел...
Оно вам надо? Или вы уже тут более-менее продумали все и пришли к чему-то?

Запость, может там есть что-то интересное?
Только желательно в pdf...

2blindman: А напиши что-нибудь на эту тему:

=DeaD= писал(а):А про адресацию - правильно ли я понимаю, что при таком подходе мы экономим 1 байт на запросах к локальному контроллеру (встроенному в шлюз-контроллер) и теряем 1 байт на запросах к подчиненным по i2c контроллерам?

при адресации встроенного контроллера сразу передаём регистр и данные, а при адресации подчиненного - 0, адрес, регистр - так?

=DeaD= писал(а):при адресации встроенного контроллера сразу передаём регистр и данные, а при адресации подчиненного - 0, адрес, регистр - так?

Вот так:

при адресации встроенного контроллера передаём адрес, регистр и данные
при адресации подчиненного - адрес, регистр и данные

Откуда бы мы не обращались к контроллеру - с другого контроллера подключенного по I2C, с другого контроллера подключенного через уарт, с ПК подключенного через уарт - формат команды и адрес неизменны. Это та самая прозрачность за которую ты ратуешь.