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

[Сергей Борщ]

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

[x736C]

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

[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' для кадровой синхронизации.

[x736C]

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

Видимо, вы меня не поняли. В конечном итоге все сводится все равно к разнице частот передатчика и приемника без ФАПЧ.
Для максимального использования линии для передачи информации необходимо свести к минимуму отношение служебной информации к полезным данным. А это напрямую зависит от нестабильности генераторов. Вы обозначили это отношение, как 1/1500.
Стало интересно, что за алгоритм. Почему именно такое отношение. На мой взгляд, очень неплохая цифра.

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

[Огурцов]

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

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

[jcxz]

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

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

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

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

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

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

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

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

[Огурцов]

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

а как же это ?:

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

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

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

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

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

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

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

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

[jcxz]

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

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

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

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

[Огурцов]

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

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

Почитайте ниже и подумайте "как":

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

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

Сообщение отредактировал Огурцов - Oct 28 2017, 14:49

[jcxz]

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

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

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

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

[Огурцов]

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

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

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

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

[kolobok0]

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

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

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

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

[Огурцов]

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