Ситуация такая: есть коробочка, на которой стоит оптический излучатель, а рядом с ним приемник. Есть вторая такая коробочка, которая относится на растояние до 30м и разворачивается (т.е. излучатель напротив приемника). Одна коробочка знает, что она передатчик, а вторая - что она приемник. Требуется, чтоб по нажатию кнопочки передатчик передал на приемник несколько сотен мегабайт. Скорость передачи в условиях прямой видимости желательно хотя бы 16 мегабит, лучше 20. Естественно, между коробочками могут проходить люди, коробочки могут трястись в руках у операторов - вообщем, могут возникать проблемы в канале, после которых нужно восстанавливать передачу. В целом, вроде ситуация ясна. Внутри коробочек стоит циклон2, для которого оптический приемник и излучатель - два провода, rx и tx.
Мне, соответственно, требуется разработать схему, которая обеспечит работоспособность, выбрать (придумать) протокол и реализовать.
Подскажите, на какие стандартные протоколы в такой ситуации можно посмотреть, на что опираться? Какие могут быть готовые или окологотовые решения?

а чем MODBUS или PROFIBUS не подходят ?

Вроде зарекомендовали себя уже давно...
PROFIBUS - воопсче злая вЭщ!

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

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




Хм. Про модемные протоколы я и не подумал. А они тут подходят?

По вычислительной мощности - там стоит второй циклон, в котором еще около 10000 свободных элементов.

Я не знаю возможности ПЛИС, а на контроллере программа не сложная. Указанные протоколы имеют реализацию на С в свободном доступе. Достаточно немного поискать.
Если реализация только на ПЛИС, то эти протоколы, наверно, не лучшие.

Думаю можно использовать старый, добрый протокол канала Манчестер (MIL-STD 1553), ну возможно в упрощенной форме, т.к. абонентов только 2.

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

Сейчас глянул вкратце описание MIL-STD 1553, там написано, что до 1Mбита. А надо 16. Получится ли легко модифицировать этот протокол до 16 мегабит? Плюс, пишут, что алгоритм весьма сложен в реализации. Нет ли чего попроще, что можно сделать с использованием манчестера?

Манчестер это физический уровень согласно 7-ми уровневой модели OSI, а вам нужно реализовать канальный и возможно транспортный. Посмотрите на описание сетевой модели OSI хотя бы в Википедии. Может там найдете знакомые названия и ответ на свой вопрос

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

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

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

MIL STD 1553 - это протокол мультиплексного канала (один хост, много оконечников)

ИМХО, не имеет смысла говорить о каком-то протоколе, пока нет обратного канала (или он есть, но я как всегда чего-то не понял?)

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

А обмен между компами идёт?
или между какими-т о железными коробочками?
Если между компами, то проще всего поставить с каждой стороны преобразователь Ethernet (какой-нить простой Риалтек) и получится прозрачный канал Ethernet (только по оптике).
Иначе - HDLC (канальный уровень) или TCP.
А достоверность передачи и перезапросы - на уровне приложений
Хотя если точка-точка, то можно любой самопальный протокол придумать, главное, задокументировать как следует.

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

хорошая идея при этом использование принципов записи на компакт диск

Да нет же, обратная связь есть! Обе коробки могут как передавать, так и принимать, причем одновременно. Полный дуплекс.
Компов рядом с коробочками нет и не будет. Данные жать нет смысла - они уже пожатые передаются.
Меня еще смущает тот момент, что угол наведения достаточно узкий, поэтому требуется сделать такое: передатчик с момента подачи питания должен постоянно находиться в режиме поиска, ища приемник на том конце.

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

...HDLC - это протокол управления протоколом канального уровня и он ни коим образом не сравним с TCP



... в принципе подходит TCP/IP, ModBus вряд ли. Мне кажется Вам надо проработать подробнее вопрос обмена информацией: например, связь между "ящиками" должна быть постоянно или устанавливаться эпизодически? ... "ящики" равноправные или один из них ведущий, а другой подчиненный? А уже потом определяться с протоколом.

Так, еще раз формулирую задачу. Две коробки. Каждая коробка может излучать в оптич. диапазоне и принимать в опт. диапазоне. Коробки разнесены на предельное расстояние, при котором уже начинаются проблемы с помехами в канале связи, проблемы с наводкой одной коробки на другую и т.п.. Одна коробка знает, что она - ведущая, носитель информации. Вторая знает, что она - ведомая, приемник информации. Нужно: ведущая коробка должна постоянно находиться в режиме поиска ведомой, и при обнаружении (устойчивом наведении) сигнализировать об этом оператору. Далее оператор отдает команду на передачу и ведущая коробка передает ведомой 100-200 мегов. Минимальная скорость - 2 мега в секунду в условиях устойчивой видимости. Дополнительно: В случае разрыва связи (посторонний объект на линии наведения) должна восстанавливаться докачка с места разрыва, но при этом в течение разрыва энергопотребление должно снижаться (типа того, что потеряли связь - начинаем опять режим поиска с большими паузами между запросами. Нашли - начинаем передавать с места разрыва в полную силу).

зачем телеге реактивный двигатель??? если для того чтобы передать данные достаточно их просто передать и убедиться в достоверности для этого достаточно 32 ячейки CPLD
никая сеть тут не нужна!!!!!!! никакого сужения спектра делать не надо

Про сеть никто и не говорит.

тут нужен протокол не сложнее уартовского

в пультах ду не всегда манчестер

...у Вас есть поток данных, т.е Вы передаете данные и вдруг он прерван. Как определить какую часть данных надо передать когда канал связи востановится? Как долго ждать когда канал связи востановится? Достоверны полученные данные? Как долго принимать данные (т.е. сколько)? Как определить начало блока данных, конец блока данных? Таким образом чтобы все это выполнить необходима определенная последовательность действий и некая служебная информация в потоке. Это все и есть протокол.

UART-протокол - это протокол физического уровня и его недостаточно чтобы ответить на вопросы заданные выше. Что касается пультов ДУ, то там нет обратной связи, а это означает что мы не можем определить принял приемник нашу информацию или нет.