Перейти к содержанию
    

Параллельный интерфейс

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос еще в железе. Если у вас стандартный LPT в старой машине и именно на ней нужно поднять такой интерфейс программным способом, то это один расклад.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

но для передачи байтов все равно нужна избыточность, хотябы 9 линий :)

Если есть 9 линий, то при оптимально построенном алгоритме можно передавать примерно до 8.994 бит данных за одну операцию вывода.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я так понимаю, что это число в итоге зависит от нестабильности кварцевых генераторов приемника и передатчика.

Если разница между частотами небольшая, то информация о тактовой частоте приемнику нужна реже. В противном случае, чаще.

Предел, равный 8.994 бита, соответствует одному 9-битному слову, отведенному для синхронизации, на 1500 информационных слов.

Почему именно такой предел?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я так понимаю, что это число в итоге зависит от нестабильности кварцевых генераторов приемника и передатчика.

Если разница между частотами небольшая, то информация о тактовой частоте приемнику нужна реже. В противном случае, чаще.

Предел, равный 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. Написал ответ до того, как вы дополнили верхний пост.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

а как же это ?:

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

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

 

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

нет, линия стробирования стробирует уже устоявшиеся данные

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

 

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

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

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а как же это ?:

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

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

 

нет, линия стробирования стробирует уже устоявшиеся данные

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

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

for (;...; recentValue = newValue) {

while (ReadPort() == recentValue);

newValue = ReadPort();

...

}

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

алгоритм он или работает, или не работает, а уж в по он или в железе - не суть важно

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

 

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

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

 

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

слово гонки слышали когда-нибудь ?

хотя да, у вас же по, в по гонок не бывает

Изменено пользователем Огурцов

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

слово гонки слышали когда-нибудь ?

хотя да, у вас же по, в по гонок не бывает

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

странный вопрос, от опытного товарища и с большим опытом в данной области.

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

до эпохи сетевых карт, при ремонте писюков...по разному было..

 

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

по скорости лучше подходит стробирование делать на аппаратном уровне(+1 бит в каждую сторону, в данном примере), а подтверждение достоверности - софтово.

 

как то так

(круглый)

ЗЫ

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...