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

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

Просьба отвечать на вопрос.
"ДА вот ссылка или краткое описание"/"НЕТ" или "НЕТ потому что"

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

Да, возможно. Видел такое в телефонной станции для управления платами с абонентскими линиями. Если знаете, что такое I2C, то там данные передаются последовательно. А в станции данные одновременно гнались по 8-ми шинам. А управление - по одной линии вместе с данными...

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

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


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


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

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

Ну, или вы не описали задачу полностью .

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

..может нужен паралленый rs232 ?

Т.е. по UART передавать данные без синхронизации - это не мазохизм, вроде как штатное явление, а по LPT - мазохизм...

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

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

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

Зависит от разрядности передавыемых данных: если передаются 2-битные слова, тогда параллельный; если же нужна сериализация-десериализация - последовательный.

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

Вопрос еще в железе. Если у вас стандартный LPT в старой машине и именно на ней нужно поднять такой интерфейс программным способом, то это один расклад.
Если же в вашем вопросе не содержится ограничений на аппаратную реализацию, то это совсем другой вариант. И тут решений можно придумать множество. Частично их тут предлагали. Скремблирование и какое-то подобие ФАПЧ, старт-стоп последовательности и прочие штучки.

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


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

Я так понимаю, что это число в итоге зависит от нестабильности кварцевых генераторов приемника и передатчика.
Если разница между частотами небольшая, то информация о тактовой частоте приемнику нужна реже. В противном случае, чаще.
Предел, равный 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/1500.
Стало интересно, что за алгоритм. Почему именно такое отношение. На мой взгляд, очень неплохая цифра.

UPD. Написал ответ до того, как вы дополнили верхний пост.

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

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


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


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


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

а как же это ?:

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


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


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


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

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


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

алгоритм он или работает, или не работает, а уж в по он или в железе - не суть важно
вы берёте длинное число и последовательно его делите, любой сбой в любом бите приведёт к тому, что все последующие за сбоем данные будут не верны


да никак, я уже вижу

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

Когда включаете комп, не удивляетесь как это он работает? Ведь там миллиарды битов! А если в каком-то из этих битов случится сбой - ведь всё же сразу потеряется и все буковки перепутаются! Ужас!!


да уж... no comments... тот случай когда "слышал звон да не знаю где он"

там везде стробирование, вот ничего и не путается


вы не поверите, и там - тоже

странный вопрос, от опытного товарища и с большим опытом в данной области.
собственно ответ прозвучал - на стандартном centronics-е делали в своё время и свои, на какой нить 8255 (PPI) - сразу 24 пина (8+8+2*4) и дистанционно сливали-форматировали винты,
до эпохи сетевых карт, при ремонте писюков...по разному было..

Если чиссо по теме - ближе помнится мне, решение связи по стандартному LPT с передачей по полубайту в одну сторону. С полной шинкой(8бит) получается полный дуплекс(по 4) постоянно. При этом
по скорости лучше подходит стробирование делать на аппаратном уровне(+1 бит в каждую сторону, в данном примере), а подтверждение достоверности - софтово.

как то так
(круглый)
ЗЫ
Параллельным имхо, обзываем возможность засунуть одинаковые по типу сигналы на физ. уровне за один строб(как физический так и логический - пофигу) передачи.

с некоторого весьма далёкого времени lpt имел двунаправленный режим и стробирование на аппаратном уровне
так что передавать половинки вместо целого байта было бы весьма криво, медленно и вообще неправильно

Так ответы Вам уже были даны. Они чем то не подходят?

Спасибо за обсуждение

Может немного запоздало. Но да, такие интерфейсы существуют с 70-80х годов. Читайте книги В.И. Варшавского. Если кратко - вводится вторая (служебная) фаза передачи, и (в качестве одного из вариантов) парафазное кодирование сигналов. Данные передаются в рабочей фазе, служебная фаза используются в качестве разделителя. На принимающей стороне фаза определяется по коду в сигнальных линиях. Сигнал сопровождения при таком протоколе передачи не нужен, кодирование в линиях противогоночное - состязания отсутствуют. Из-за второй фазы протокол не самый быстрый, а при парафазном кодировании еще и сильнопотребляющий (переключательная активность проводов 100% за цикл передачи). На практике вроде бы это в TRIMOSBUS применялось, но не уверен.