Обсуждение протокола шлюз-контроллера

=DeaD=

Вернёмся к этой важной теме.

По итогам переписки с blindman'ом в аське возникли примерно такие идеи:

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

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

3. Кроме информации о том, что драйвер работает в таком-то адресном пространстве должно быть некоторое описание этого драйвера, типа "что это?". И вот тут начинается неопределенность. Можно от 1 байта запользовать под идентификацию типа драйвера до строки + 2 байта - на строковое название драйвера и 2 байта - номер версии и субверсии.

Добавлено спустя 3 минуты 7 секунд:
Такой подход нисколько не усложняет работу с устройствами по сравнению с текущей схемой, когда драйверы располагаются по конкретным адресам. Если мы не хотим писать код, который будет совместим с кучей разных контроллеров - можем прописать в своей программе работающей с контроллером конкретные адреса везде.

Более гибкая схема - сделать эти адреса настраиваемые, или стартовые адреса настраиваемые. Но тогда пользователь сам должен будет следить, чтобы всё было указано правильно.

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

Vooon

Интроспекция — это удобно

В качестве идентификатора драйвера предлагаю использовать uint32_t.
Со строкой сложность — нужно делать дополнительный запрос для определения длинны.

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

Возможный формат:
00 00 — get drivers count (1 byte)
00 nn — get driver nn uid (nn = 1..count+1) (4 byte)
00 uu ii dd nn 00 — get driver registers count (uuiiddnn = uid) (1 byte)
00 uu ii dd nn rr — get driver register rr address (uuiiddnn = uid, rr = 1..count+1) (1 byte)

=DeaD=

Vooon писал(а):

В качестве идентификатора драйвера предлагаю использовать uint32_t.

Как их раздавать?

Vooon писал(а):

Со строкой сложность — нужно делать дополнительный запрос для определения длины.

Или можно сказать что длина всегда 11 символов. Прижимаем влево, справа добиваем пробелами.

Vooon писал(а):

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

Я бы посадил его на несколько первых адресов, чтобы сделав запрос по номеру драйвера получить обратно по нему полную инфу.

blindman

=DeaD= писал(а):

Как их раздавать?

Централизованно, как это делает Филипс с I²C

=DeaD= писал(а):

Я бы посадил его на несколько первых адресов, чтобы сделав запрос по номеру драйвера получить обратно по нему полную инфу.

Одного вполне достаточно. Пишем туда запрос, читаем из него же ответ. Формат ответа зависит от запроса. Если нужна передача строк - ограничиваем их длину.

=DeaD=

Неее... нарушается логика - не должны мы из 1 адреса читать более 1 байта. Если читаем 2 байта - это читаем 2 адреса.

Добавлено спустя 44 секунды:
Раздавать централизованно - ну можно. Надо тогда диапазон выделить типа 192.168.х.х чтобы там пользователи могли что угодно делать

blindman

Почему это не должны? Как это не читать более 1 байта? Наверно что-то другое имелось в виду?

Добавлено спустя 47 секунд:

=DeaD= писал(а):

Раздавать централизованно - ну можно. Надо тогда диапазон выделить типа 192.168.х.х чтобы там пользователи могли что угодно делать

Адназначна

=DeaD=

blindman писал(а):

Почему это не должны? Как это не читать более 1 байта? Наверно что-то другое имелось в виду?

Да вроде нет, вроде в I2C всегда если я читаю 10 байт с адреса 00 это эквивалентно чтению по очереди по 1 байту с каждого из 10 адресов начиная с 0 и заканчивая 9.

Или я что-то упустил в стандарте i2c и типичных его реализациях?

Digit

ничего не упустил,Dead. все верно

Добавлено спустя 1 минуту 42 секунды:
может не в тему: т.к. у нас возможен мультимастер, то мы можем писать по адресу 0 свой адрес (буфер), а потом ждать, когда нам драйвер по этому адресу все выгрузит. подойдет?

=DeaD=

2Digit: Мультимастер это не слишком круто? У нас идеология пока не под него. Давайте под мультимастер потом отдельную обертку сделаем?

Digit

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

в принципе, зарезервировать диапазон адресов за "нулевым" драйвером можно. только ж у нас адресов 255 - жалко

а то, о чем говорит blindman - это аналог портов в TSP/IP, а не адресов в и2с

blindman

Мы вообще здесь не говорим о I2C. Чтобы не было путаницы - давайте говорить "регистр", а не "адрес"

MiBBiM

а контроллер может выступать в роли ведомого, т.е. возможна схема из вложенных контроллеров? если нет, то 255 адресов - вполне достаточно, ведь адрес только указывает на модуль (кто навешает на бота 200 модулей :shock:

)

Digit

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

вот о регистрах и говорим?
согласно стандарту и2с чтение последовательно двух байт при задаче N-го регистра равносильно чтению подряд регистров N и N+1. Инкремент номера регистра производится автоматически.

blindman, мы об этом. если это не учитывать, то уже не и2с получается.

Добавлено спустя 2 минуты 14 секунд:
или мы делаем "надстройку над регистрами"?

Добавлено спустя 1 минуту 1 секунду:
т.е. вводим что-то вроде портов?
типа в регистре "0" устройства лежит номер порта буфера, куда складывать данные? как-то коряво :pardon:

blindman

Еще раз. Забудьте на время о I²C. Нету его. Есть система драйверов, описанная здесь : viewtopic.php?f=69&t=5890. Чтобы понять о чем мы сейчас говорить надо почитать документацию в архиве который я там выкладывал. Код здесь : http://hg.vehq.ru/orfa/file/

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

Vooon

Ох, дигит, загляни в код, не будет лишних вопросов
http://hg.vehq.ru/orfa/file/a45b152221bf/main.c#l1

Я что-то не припомню чтобы стандарт I2C регламентировал регистры.

И мне вовсе не очевидно что второй байт регистра 20 есть регистр 21.
Номер регистра лишь указывает с какой областью памяти работать

Добавлено спустя 3 минуты 27 секунд:
Хм, пока писал блиндман успел ответить

ПС:

Код:

vovan@vovan-pc:~/dev/project/orfa$ find -regex '.*\.\(h\|c\)' | xargs wc
  176   427  3333 ./main.c
  310   932  6770 ./serialgate/i2c.c
  122   540  3554 ./serialgate/i2c.h
  221   711  5334 ./serialgate/command.c
   50   284  1911 ./serialgate/command.h
  453  1158  8812 ./serialgate/parser.c
   61   374  2635 ./serialgate/parser.h
   85   347  2268 ./serialgate/cbuf.c
  114   530  3836 ./serialgate/cbuf.h
   51   263  1826 ./serialgate/common.h
   64   271  1884 ./serialgate/test.c
   97   398  2576 ./serialgate/usart.c
  129   544  3890 ./serialgate/usart.h
   78   281  2095 ./serialgate/serialgate.c
   72   341  2271 ./serialgate/serialgate.h
  157   538  4038 ./registers/spi_driver.c
   32   207  1388 ./registers/spi_driver.h
  148   510  3743 ./registers/ports_driver.c
   32   207  1394 ./registers/ports_driver.h
   91   349  2535 ./registers/driver.c
  148   800  8287 ./registers/driver.h
   56   282  2241 ./registers/common.h
   61   429  4217 ./registers/docs.h
   71   336  2634 ./registers/test.c
  177   604  4576 ./registers/motor_driver.c
   32   207  1394 ./registers/motor_driver.h
  108   415  3038 ./registers/ports.c
  111   594  5960 ./registers/ports.h
 3307 12879 98440 итого

roboforum.ru

Правила форума

Обсуждение протокола шлюз-контроллера

Кто сейчас на конференции