Для начала предложу вам общую схему устройства (верхний рисунок).
Разъяснение:
БУ - блок управления
БК - блок коммутации
ИУ - исполнительное устройство
БИ - блок индикации
Почему введен коммутатор в схему?
На самом деле коммутатор присутствует практически во всех многоблочных схемах с централизованным упралением. Коммутатор может быть аппаратным устройством (как у меня), или же программным модулем, все
зависит от реализации. Еще одной причиной, по которой БК присутствует в схеме, является возможность легкого внедрения блока индикации.
Вобщем, эта схема мне подходит, хотя любые предложения приветствуются.
Входные данные: предложенная схема.
Задача: разработать по возможности универсальный протокол обмена между всеми частями схемы.
Для решения поставленной задачи думаю нелишним будет расмотреть БК поподробнее:
Данные которые содержит БК
1. Список заданий находящийся в очереди (список занятых устройств)
2. Список заданий принятых к исполнению.
Обеспечиваемые методы (о полноте списка судить вам)
1. Добавить задание в очередь
2. Добавить OOB задание (по аналогии с TCP-IP Out Of Band пакетом) Т.е. поместить его без очереди.
3. Очистить очередь заданий принятых к исполнению
4. Сброс системы (останов)
Думаю пригодится нам и интерфейс ИУ:
1. Команду на исполнение
2. Останов
БК частично выполняет функции обеспечения асинхронного обмена данными, поэтому я предлагаю подобного рода протокол (нижний рисунок)
Вот вопросы, которые я предлагаю обсудить:
Предложения или замечания по поводу "коммутируемой" системы.
Возможные дополнения функций коммутатора или ИУ.
Протокол, каким видите его вы?
[/b]
roboforum.ru
Технический форум по робототехнике.
Соедининие контроллеров: протокол обмена
Соедининие контроллеров: протокол обмена
- Вложения
-
- Протокол
- proto_pic.png (4.81 КиБ) Просмотров: 4832
-
- Блочная схема
- full_block.png (3.88 КиБ) Просмотров: 4823
Предлагаю более правильный подход к разработке протокола обмена.
Для начала нарисуем сетевую модель, согласно стандарту ISO/OSI
мы имеем 7 уровней взаимодействия оборудования:
1. физический
2. канальный
3. сетевой
4. транспортный
5. сессионный
6. представительский
7. приложений
Теперь давай всё раскладывать по полочкам
1. Физический уровень - здесь более менее понятно.
Для внутрисхемного общения здесь выбирается два медных провода один на приём, другой на передачу данных, кодирование ведётся высоким и низким сигналами TTL уровней.
Внешнюю коммуникацию мы рассмотрим чуть познее.
2. Канальный уровень здесь уже начинаются вопросы.
на этом уровне мы должны решить задачу связности устройств между собой и управление каналом если еспользуется единая шина.
3. Сетевой уровень дальше всё пока вообще туманно
на этом уровне решаем вопрос адресации устройств и маршрутизации потоков данных.
4. Транспортный уровень
обеспечиваем требуемое качество доставки даных (CRC проверки блоков , переспросы при повреждении и т.д.)
5. Сесионный уровень
этот уровень нам вероятно не потребуется, впрочемм он может потребоваться на внешнем канале при управлении компом группой мобильных роботов ...
6. Представительский уровень
Представление данных в стандартной форме - всякие там перекодировочки языка, в нашем случае нормализация показаний датчиков.
7. Уровень приложений
И только здесь мы подходим к вышеуказанному пулу задач.
Для начала нарисуем сетевую модель, согласно стандарту ISO/OSI
мы имеем 7 уровней взаимодействия оборудования:
1. физический
2. канальный
3. сетевой
4. транспортный
5. сессионный
6. представительский
7. приложений
Теперь давай всё раскладывать по полочкам
1. Физический уровень - здесь более менее понятно.
Для внутрисхемного общения здесь выбирается два медных провода один на приём, другой на передачу данных, кодирование ведётся высоким и низким сигналами TTL уровней.
Внешнюю коммуникацию мы рассмотрим чуть познее.
2. Канальный уровень здесь уже начинаются вопросы.
на этом уровне мы должны решить задачу связности устройств между собой и управление каналом если еспользуется единая шина.
3. Сетевой уровень дальше всё пока вообще туманно
на этом уровне решаем вопрос адресации устройств и маршрутизации потоков данных.
4. Транспортный уровень
обеспечиваем требуемое качество доставки даных (CRC проверки блоков , переспросы при повреждении и т.д.)
5. Сесионный уровень
этот уровень нам вероятно не потребуется, впрочемм он может потребоваться на внешнем канале при управлении компом группой мобильных роботов ...
6. Представительский уровень
Представление данных в стандартной форме - всякие там перекодировочки языка, в нашем случае нормализация показаний датчиков.
7. Уровень приложений
И только здесь мы подходим к вышеуказанному пулу задач.
1. физический
Думаю этот уровень мы оставим на усмотрение пользователя, кому-то TWI, кому-то RS232 кому-то еще что-то...
2. канальный
3. сетевой
Эти два уровня обеспечиваются работой коммутатора (в моем представлении), рассмотрение управления шиной в топике
4. транспортный
Да, этот вопрос вообще-то стоит расмотреть. Буду думать.
5. сессионный
Пока неясно.
6. представительский
Это черызвычайно важно, это в принципе и есть то, за что боремся - Стандарт.
7. приложений
Это, имхо конечно, уже интерфейс библиотеки. =)
Вобщем принимаем к рассмотрению вопросы 2,3 (обсуждаются в другом топике), 4 (следует или не следует вводить помехозащищенное кодирование), 6 (предложения, наработки).
P.S. За что борюсь: создание удобного для большинства стандарта, и набора типовых решений, народ присоединяемся к обсуждениям.
Думаю этот уровень мы оставим на усмотрение пользователя, кому-то TWI, кому-то RS232 кому-то еще что-то...
2. канальный
3. сетевой
Эти два уровня обеспечиваются работой коммутатора (в моем представлении), рассмотрение управления шиной в топике
4. транспортный
Да, этот вопрос вообще-то стоит расмотреть. Буду думать.
5. сессионный
Пока неясно.
6. представительский
Это черызвычайно важно, это в принципе и есть то, за что боремся - Стандарт.
7. приложений
Это, имхо конечно, уже интерфейс библиотеки. =)
Вобщем принимаем к рассмотрению вопросы 2,3 (обсуждаются в другом топике), 4 (следует или не следует вводить помехозащищенное кодирование), 6 (предложения, наработки).
P.S. За что борюсь: создание удобного для большинства стандарта, и набора типовых решений, народ присоединяемся к обсуждениям.
Уточню
Виталий писал(а):1. физический
Думаю этот уровень мы оставим на усмотрение пользователя, кому-то TWI, кому-то RS232 кому-то еще что-то...
2. канальный
3. сетевой
Эти два уровня обеспечиваются работой коммутатора (в моем представлении), рассмотрение управления шиной в топике
4. транспортный
Да, этот вопрос вообще-то стоит расмотреть. Буду думать.
5. сессионный
Пока неясно.
6. представительский
Это черызвычайно важно, это в принципе и есть то, за что боремся - Стандарт.
7. приложений
Это, имхо конечно, уже интерфейс библиотеки. =)
Вобщем принимаем к рассмотрению вопросы 2,3 (обсуждаются в другом топике), 4 (следует или не следует вводить помехозащищенное кодирование), 6 (предложения, наработки).
P.S. За что борюсь: создание удобного для большинства стандарта, и набора типовых решений, народ присоединяемся к обсуждениям.
М-да.... Мы здесь изучаем сетевые технологии ??? или разрабатываем комутаторы ????...... Есть много стандартов... И сделать универсальный необычайно трудная задача !!!!
Поэтому надо быть проше. Пакет должен однозначно содержать следующие поля :
- адресное поле
- поле длины пакета
- поле данных
- поле контрольной суммы
И этого достаточно ... для связи двух контроллеров.
этого достаточно для связи двух контроллеров одного типа.
посмотю я как вы передадите инфу от контроллера к другому через оптоволоконный канал
впрочем если считать что среда связи медь, принебречь помехами, принять за уровни сигналов TTL тогда и только тогда перечисленных выше условий будет достаточно, да и то если тайминги более менее совпадут.
посмотю я как вы передадите инфу от контроллера к другому через оптоволоконный канал впрочем если считать что среда связи медь, принебречь помехами, принять за уровни сигналов TTL тогда и только тогда перечисленных выше условий будет достаточно, да и то если тайминги более менее совпадут.
Тогда надо уточнять условия , а то здесь можно придумать такое........с криптографией,с помехоустойчивостью, с избыточным кодом, с 10 байтной адресацией ....Я так понимаю границ здесь нет..... 
:lol: :lol: :lol: :lol:
:lol: :lol: :lol: :lol:А зачем вообще пытаться какой-то новый протокол придумать? Ведь действительно много "стандартных" существует. Например MODBUS чем вас не устраивает :?: Там уже заложены всё необходимое. Я имею ввиду поля для адреса устройства, длину команд и данных, проверки CRC и т.д.
Но если Вам нужно буквально "пару байтов переслать" и не хочется из-за этого изучать систему команд модбаса, тогда конечно, просторы для полёта фантазии не ограничены!
Но если Вам нужно буквально "пару байтов переслать" и не хочется из-за этого изучать систему команд модбаса, тогда конечно, просторы для полёта фантазии не ограничены!
Змей-Горыныч писал(а):А зачем вообще пытаться какой-то новый протокол придумать? Ведь действительно много "стандартных" существует...
Согласен, сам к этому в последнее время пришёл.
однако это не освобождает придумывания 5 6 и 7 уровня модели
Создал протокол обмена информацией между котролерами управления приводами,
интегрировал регуляторы положения, скорости и тока...
Тестируемая скорость: вопрос ответ 120µс ... Предусмотрено управление через com-порт
интегрировал регуляторы положения, скорости и тока...
Тестируемая скорость: вопрос ответ 120µс ... Предусмотрено управление через com-порт
Digit - Конечно нет. Протокол похож на тот, что описан выше 
, но..
В нем отсутствует блок коммутации и блок индикации (мне кажеться), так как такой уровень визуализации меня не интересовал по двум причинам:
1. При большом кол-ве участников сети (например > 10) возникнет дополнительная нагрузка на протокол. Если конечно блок коммутации не являеться участником, а играет роль наблюдателя, но в таком случае его функции и так выполняються обшей (Мастер) системой (напреимер PC), которая по восможностям в 1000 раз превосходит любой контроллер.....
2. Визуализацию каких-то промежутчных данных - это, на мой взгляд, можно исползовать лишь как "примочку" для наблюдений "поведения" отдельных участков системы, либо отдельного объекта. Гораздо целесообразней создавать подобные веши уже на высоком уровне, дабы не перегружать второстепенными вопросами "дохленькие" контроллеы.
И так о протоколе:
протокол имеет набор комманд:
1. Инизиализации и парамеметрирования протокола.
2. Управления объектами (задание, истенное значение)
Все участники системы имеют два адреса:
1. Собственный (заресервированные адреса, включая адрес "Мастера")
2. Обший - позволяет управлять всеми участниками сети одновременно (достоинство на лицо)
Обмен информации осуществляеться по принципу - Master -> Slave, Slave -> Мастер.
Физеческая основа протокола - асинхорнная передача данных с(или без) "адресным" битом.
С адресным битом легко - прохитал свой адрес значит принимаем
Без адресного бита - дело тяжелее. "Дергать всё время ухо в остро" - дело не шуточное - Надо байты считать или еше как-нибудь выкручиваться - не важхно, так как это слишком загружает контроллеры (постоянные прерывания - дестабилизируют работу "строгих" к дискретности регуляторов).
Не все контроллеры обладают UARTом с адресным битом
Но есть выход: использовать контроллеры - толко с такой опцией
И второе, самое главное НУЖНО ИСПОЛьЗОВАТь 7-БИТНЫЙ ПРОТОКОЛ, потому что когда дело дойдет до связи с ком-портом можно столкнуться с проблемой - в запасе толко 8-бит для передачи, а сгенерировать адресный бит (9-тый) просто так не выйдет....
И так... о скоростях передачи:
120µс - это не предел можно конечно и меньше (это при 1 Мбит на шине), но представь себе то, что Команда на контроллере выполняеться в среднем от 200 до 1000 нс. Т.е по макс. 1µs - это значит за 120 команд обработать, например, посылку из 4 байт (адрес, тип команды, данные, контрольная сумма) - рашифровать, проверитъ контрольная сумму,сохранить данные (как минимум); сформировать и послать ответ (например 4 байта).... я думаю, что 120 команд - это не много....
, но..
В нем отсутствует блок коммутации и блок индикации (мне кажеться), так как такой уровень визуализации меня не интересовал по двум причинам:
1. При большом кол-ве участников сети (например > 10) возникнет дополнительная нагрузка на протокол. Если конечно блок коммутации не являеться участником, а играет роль наблюдателя, но в таком случае его функции и так выполняються обшей (Мастер) системой (напреимер PC), которая по восможностям в 1000 раз превосходит любой контроллер
.....2. Визуализацию каких-то промежутчных данных - это, на мой взгляд, можно исползовать лишь как "примочку" для наблюдений "поведения" отдельных участков системы, либо отдельного объекта. Гораздо целесообразней создавать подобные веши уже на высоком уровне, дабы не перегружать второстепенными вопросами "дохленькие" контроллеы.
И так о протоколе:
протокол имеет набор комманд:
1. Инизиализации и парамеметрирования протокола.
2. Управления объектами (задание, истенное значение)
Все участники системы имеют два адреса:
1. Собственный (заресервированные адреса, включая адрес "Мастера")
2. Обший - позволяет управлять всеми участниками сети одновременно (достоинство на лицо)
Обмен информации осуществляеться по принципу - Master -> Slave, Slave -> Мастер.
Физеческая основа протокола - асинхорнная передача данных с(или без) "адресным" битом.
С адресным битом легко - прохитал свой адрес значит принимаем
Без адресного бита - дело тяжелее. "Дергать всё время ухо в остро" - дело не шуточное
- Надо байты считать или еше как-нибудь выкручиваться - не важхно, так как это слишком загружает контроллеры (постоянные прерывания - дестабилизируют работу "строгих" к дискретности регуляторов).Не все контроллеры обладают UARTом с адресным битом
Но есть выход: использовать контроллеры - толко с такой опцией
И второе, самое главное НУЖНО ИСПОЛьЗОВАТь 7-БИТНЫЙ ПРОТОКОЛ, потому что когда дело дойдет до связи с ком-портом можно столкнуться с проблемой - в запасе толко 8-бит для передачи, а сгенерировать адресный бит (9-тый) просто так не выйдет....
И так... о скоростях передачи:
120µс - это не предел можно конечно и меньше (это при 1 Мбит на шине), но представь себе то, что Команда на контроллере выполняеться в среднем от 200 до 1000 нс. Т.е по макс. 1µs - это значит за 120 команд обработать, например, посылку из 4 байт (адрес, тип команды, данные, контрольная сумма) - рашифровать, проверитъ контрольная сумму,сохранить данные (как минимум); сформировать и послать ответ (например 4 байта).... я думаю, что 120 команд - это не много
....