Параллельный интерфейс, возможно ли создать или существует? Опции

[IJAR]

Возможно ли создать или существует параллельный интерфейс
в котором будут только шины передачи данных (например 8)
а шина стробирования передачи будет отсутствовать?

[novikovfb]

И как передать 2 одинаковых байта через такой интерфейс?

[jcxz]

И как передать 2 одинаковых байта через такой интерфейс?

Кодировать поток таким образом, чтобы не было подряд двух одинаковых.

Возможно ли создать или существует параллельный интерфейс
в котором будут только шины передачи данных (например 8)
а шина стробирования передачи будет отсутствовать?

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

Правильно ли я понял, что это будет не параллельный интерфейс, а 8 или сколько там еще одновременно работающих последовательных?

Нет. Можно передавать именно параллельно. Ничего трудного нет если немного подумать.

[LII]

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

И при этом не использовали, присутствующие в LPT, служебные сигналы, например "Data strobe", а использовали только Data 0-7? Это мазохизм какой-то.

[jcxz]

И при этом не использовали, присутствующие в LPT, служебные сигналы, например "Data strobe", а использовали только Data 0-7? Это мазохизм какой-то.

Нет. Использовали все имеющиеся сигналы для передачи данных. Все, а не только D0-D7.

Если развить и углУбить мысль в этом направлении, то можно попробовать использовать код Грея,
но для передачи байтов все равно нужна избыточность, хотябы 9 линий

Если есть 9 линий, то при оптимально построенном алгоритме можно передавать примерно до 8.994 бит данных за одну операцию вывода.
Надо просто подмешать сигнал стробирования в данные. При достаточных вычислительных ресурсах на обеих сторонах (приёма и передачи) можно вплотную приблизиться к пределу == 8.994 бит данных за такт на 9-разрядном параллельном интерфейсе.

[x736C]

можно вплотную приблизиться к пределу == 8.994 бит данных за такт на 9-разрядном параллельном интерфейсе.

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

[jcxz]

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

Нет. При чём тут частоты??? Никакие выделенные сигналы тактирования не нужны - сигнал тактирования можно подмешать в данные. Для достижения максимального использования линий.
Ещё раз: ключевой момент - смешивание сигналов тактирования и данных.

Предположим: для передачи можно использовать например 9 линий некоего параллельного интерфейса (D0...D8). Как наиболее оптимально их использовать с максимальной пропускной способностью при ограниченной полосе частот по этому интерфейсу?
Например так:
Имеем на входе поток байт. Преобразуем его в поток бит. Нарезаем этот поток на 9-битные символы. Их значения будут в диапазоне: 0...511.
Сигналом строба новых данных для приёмника будет изменение состояния линий D0...D8. Это значит, что для передачи слова символа X нужно проXORить его с текущим состоянием линий D0...D8.
Приёмник увидев изменение состояния D0...D8 воспринимает это изменение как сигнал строба и считывает данные, после чего делает XOR с предыдущим состоянием D0...D8 - получает
отправленный символ.
Но конечно так можно передать символы 1...511, а вот символ '0' так передать не удастся. А значит его надо экранировать из потока 9-битовых символов.
Также желательно иметь какой-то символ границы кадра. Например это символ '1'. Таким образом нужно преобразовать поток символов так, чтобы он содержал только символы 2...511.
Самый простой способ экранировать символы '0' и '1' из исходного потока - это типа как в протоколе SLIP для последовательных линий. Но конечно он имеет недостатки - может создавать избыточность передаваемых данных.
Можно придумать более сложные способы экранирования. И более эффективные.
Например:
Если реализовать многоразрядные операции умножения/деления, то можно очень эффективно преобразовать поток 0...511 в поток 2...511. А вот как раз диапазон 2...511 содержит 510 возможных значений, а это равно log(510)/log(2) = 8.994 бит.
Вобщем - если имеем умножитель на N разрядов (скажем 128, а может больше), то преобразуем 9-битовые символы в битовый поток, нарезаем его на сегменты разрядностью (N-9) бит, а далее: последовательно умножаем полученный сегмент на 511, после каждого умножения получая в старших 9 разрядах умножителя значения в диапазоне 0...510, прибавляем к ним 2 и передаём на XOR и в канал.
На приёмной стороне выполняем обратную операцию.
Чем больше разрядность N, тем эффективнее работает алгоритм (тем ближе он к пределу == log(510)/log(2)).
Ну и между кадрами вставляем символы границ кадра == '1' для кадровой синхронизации.

[Огурцов]

Ну и между кадрами вставляем символы границ кадра == '1' для кадровой синхронизации.

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

[jcxz]

и при потере одного бита будет вылетать целый кадр ? или в среднем половина

Здесь интерфейс параллельный, а не последовательный - передаются слова.

а что будет, если происходит задержка одного или нескольких бит относительно других, как такое принять ?

Точно так же как при наличии отдельной линии стробирования.

что мешает "неэффективно" использовать девятый (восьмой) бит для простой и надёжной синхронизации ?

Мешает Ваше неумение читать исходные сообщения авторов тем.

можно по обоим фронтам на половинной частоте, чтобы полосу не расширять

Хоть по одному хоть по двум - всё равно используя все 9 бит для данных можно передавать быстрее.

[Огурцов]

Здесь интерфейс параллельный, а не последовательный - передаются слова.

а как же это ?:

преобразуем 9-битовые символы в битовый поток

любой сбой и весь поток накрылся

Точно так же как при наличии отдельной линии стробирования.

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

Мешает Ваше неумение читать исходные сообщения авторов тем.

вот пусть и он и ответит, дурацкие желания желательно как-то обосновывать

Хоть по одному хоть по двум - всё равно используя все 9 бит для данных можно передавать быстрее.

в теории да, когда канал идеальный

[jcxz]

а как же это ?:
любой сбой и весь поток накрылся

Читайте внимательнее: "это" - описание алгоритма работы ПО.

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

Почитайте ниже и подумайте "как":
for (;...; recentValue = newValue) {
while (ReadPort() == recentValue);
newValue = ReadPort();
...
}