Jump to content

    
Sign in to follow this  
IJAR

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

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

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

 

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

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

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

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

Share this post


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

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

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

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

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

Share this post


Link to post
Share on other sites
Я так понимаю, что это число в итоге зависит от нестабильности кварцевых генераторов приемника и передатчика.

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

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

Share this post


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

Видимо, вы меня не поняли. В конечном итоге все сводится все равно к разнице частот передатчика и приемника без ФАПЧ.

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

Стало интересно, что за алгоритм. Почему именно такое отношение. На мой взгляд, очень неплохая цифра.

 

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

Share this post


Link to post
Share on other sites
Ну и между кадрами вставляем символы границ кадра == '1' для кадровой синхронизации.

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

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

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

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

 

Share this post


Link to post
Share on other sites
и при потере одного бита будет вылетать целый кадр ? или в среднем половина

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

 

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites
Здесь интерфейс параллельный, а не последовательный - передаются слова.

а как же это ?:

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

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

 

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

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

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

 

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

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

 

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

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

 

Share this post


Link to post
Share on other sites
а как же это ?:

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

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

 

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

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

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

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

while (ReadPort() == recentValue);

newValue = ReadPort();

...

}

Share this post


Link to post
Share on other sites
Читайте внимательнее: "это" - описание алгоритма работы ПО.

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

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

 

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

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

 

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

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

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

Edited by Огурцов

Share this post


Link to post
Share on other sites
вы берёте длинное число и последовательно его делите, любой сбой в любом бите приведёт к тому, что все последующие за сбоем данные будут не верны

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

 

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

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

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

Share this post


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

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

 

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

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

 

 

 

 

Share this post


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

 

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

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

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

 

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

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

 

как то так

(круглый)

ЗЫ

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

 

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this