Версия для печати темы
Форум разработчиков электроники ELECTRONIX.ru _ RS232/LPT/USB/PCMCIA/FireWire _ Параллельный интерфейс
Автор: IJAR Oct 27 2017, 08:57
Возможно ли создать или существует параллельный интерфейс
в котором будут только шины передачи данных (например 8)
а шина стробирования передачи будет отсутствовать?
Автор: novikovfb Oct 27 2017, 09:03
И как передать 2 одинаковых байта через такой интерфейс?
Автор: IJAR Oct 27 2017, 09:07
Цитата(novikovfb @ Oct 27 2017, 12:03)
И как передать 2 одинаковых байта через такой интерфейс?
Просьба отвечать на вопрос.
"ДА вот ссылка или краткое описание"/"НЕТ" или "НЕТ потому что"
Автор: Lmx2315 Oct 27 2017, 09:25
Цитата(IJAR @ Oct 27 2017, 12:07)
Просьба отвечать на вопрос.
"ДА вот ссылка или краткое описание"/"НЕТ" или "НЕТ потому что"
есть такой интерфейс - это jesd204 из нескольких лейнов, например 8-ми или XAUI из четырёх лейнов.
Ну и по аналогии - все прочие безклоковые интерфейсы которые можно пустить паралельно рядом.
Автор: iosifk Oct 27 2017, 09:39
Цитата(IJAR @ Oct 27 2017, 11:57)
Возможно ли создать или существует параллельный интерфейс
в котором будут только шины передачи данных (например 8)
а шина стробирования передачи будет отсутствовать?
Да, возможно. Видел такое в телефонной станции для управления платами с абонентскими линиями. Если знаете, что такое I2C, то там данные передаются последовательно. А в станции данные одновременно гнались по 8-ми шинам. А управление - по одной линии вместе с данными...
Автор: novikovfb Oct 27 2017, 09:48
Цитата(Lmx2315 @ Oct 27 2017, 13:25)
есть такой интерфейс - это jesd204 из нескольких лейнов, например 8-ми или XAUI из четырёх лейнов.
Ну и по аналогии - все прочие безклоковые интерфейсы которые можно пустить паралельно рядом.
Правильно ли я понял, что это будет не параллельный интерфейс, а 8 или сколько там еще одновременно работающих последовательных?
Автор: jcxz Oct 27 2017, 10:55
Цитата(novikovfb @ Oct 27 2017, 12:03)
И как передать 2 одинаковых байта через такой интерфейс?
Кодировать поток таким образом, чтобы не было подряд двух одинаковых.
Цитата(IJAR @ Oct 27 2017, 11:57)
Возможно ли создать или существует параллельный интерфейс
в котором будут только шины передачи данных (например 8)
а шина стробирования передачи будет отсутствовать?
Возможно. Когда то давно (ещё в своей программистской юности
делал подобное.
Да и в стародавние времена видел реализации передачи данных через LPT на другой LPT, судя по скоростным характеристикам которых, там как раз так и передавались данные.
Цитата(novikovfb @ Oct 27 2017, 12:48)
Правильно ли я понял, что это будет не параллельный интерфейс, а 8 или сколько там еще одновременно работающих последовательных?
Нет. Можно передавать именно параллельно. Ничего трудного нет если немного подумать.
Автор: Raven Oct 27 2017, 12:19
Так какие проблемы-то? Берете нужное количество регистров, выставляете их параллельные выходные линии наружу с какой-нибудь буферизацией-защитой,- вот вам и искомое.
Ну, или вы не описали задачу полностью .
Автор: LII Oct 27 2017, 14:22
Цитата(jcxz @ Oct 27 2017, 12:55)
Возможно. Когда то давно (ещё в своей программистской юности
делал подобное.
Да и в стародавние времена видел реализации передачи данных через LPT на другой LPT, судя по скоростным характеристикам которых, там как раз так и передавались данные.
И при этом не использовали, присутствующие в LPT, служебные сигналы, например "Data strobe", а использовали только Data 0-7? Это мазохизм какой-то.
Автор: Lmx2315 Oct 27 2017, 14:28
Цитата(LII @ Oct 27 2017, 17:22)
И при этом не использовали, присутствующие в LPT, служебные сигналы, например "Data strobe", а использовали только Data 0-7? Это мазохизм какой-то.
..может нужен паралленый rs232 ?
Автор: leocat Oct 27 2017, 14:54
Цитата(LII @ Oct 27 2017, 15:22)
И при этом не использовали, присутствующие в LPT, служебные сигналы, например "Data strobe", а использовали только Data 0-7? Это мазохизм какой-то.
Т.е. по UART передавать данные без синхронизации - это не мазохизм, вроде как штатное явление, а по LPT - мазохизм...
Автор: LII Oct 27 2017, 15:18
Цитата(leocat @ Oct 27 2017, 16:54)
Т.е. по UART передавать данные без синхронизации - это не мазохизм, вроде как штатное явление, а по LPT - мазохизм...
Если использовать готовый LPT порт, как было сказано выше, то у всех LPT пин синхронизации уже есть по умолчанию. Не использовать его, а применять некие программные ухищрения это и есть мазохизм.
Автор: IJAR Oct 27 2017, 16:04
Цитата(LII @ Oct 27 2017, 18:18)
Если использовать готовый LPT порт, как было сказано выше, то у всех LPT пин синхронизации уже есть по умолчанию. Не использовать его, а применять некие программные ухищрения это и есть мазохизм.
Естественно.
Но если на компе pin строба убит или шлейф в стене и оборвался строб,
т.е. восстановлению не подлежит. замена оборудования невозможна,
но очень нужно восстановить работоспособность.
Но мой вопрос в теме не об этом. Там надо все понимать буквально.
И главное надо определить что же такое параллельный интерфейс.
А то если взять 2 SPI с одним общим синхром - то это что 2 сериальных
или 2-х битный параллельный?
Автор: k155la3 Oct 27 2017, 16:34
Цитата(jcxz @ Oct 27 2017, 13:55)
Кодировать поток таким образом, чтобы не было подряд двух одинаковых.
. . .
Если развить и углУбить мысль в этом направлении, то можно попробовать использовать код Грея,
но для передачи байтов все равно нужна избыточность, хотябы 9 линий
Если же надо передать именно по 8 линиям - то последовательно передавать тетрады байта.
Автор: aaarrr Oct 27 2017, 16:50
Цитата(IJAR @ Oct 27 2017, 19:04)
А то если взять 2 SPI с одним общим синхром - то это что 2 сериальных
или 2-х битный параллельный?
Зависит от разрядности передавыемых данных: если передаются 2-битные слова, тогда параллельный; если же нужна сериализация-десериализация - последовательный.
Автор: Сергей Борщ Oct 27 2017, 16:55
Поищите в сети книгу "Синхронизация в телекоммуникационных системах. Анализ инженерных решений". Насколько помню, там описано множество разных решений подобных задач. Возможно в ней вы найдете то, что вам нужно.
Автор: x736C Oct 27 2017, 17:51
Вопрос еще в железе. Если у вас стандартный LPT в старой машине и именно на ней нужно поднять такой интерфейс программным способом, то это один расклад.
Если же в вашем вопросе не содержится ограничений на аппаратную реализацию, то это совсем другой вариант. И тут решений можно придумать множество. Частично их тут предлагали. Скремблирование и какое-то подобие ФАПЧ, старт-стоп последовательности и прочие штучки.
Автор: jcxz Oct 27 2017, 18:23
Цитата(LII @ Oct 27 2017, 17:22)
И при этом не использовали, присутствующие в LPT, служебные сигналы, например "Data strobe", а использовали только Data 0-7? Это мазохизм какой-то.
Нет. Использовали
все имеющиеся сигналы для передачи данных. Все, а не только D0-D7.
Цитата(k155la3 @ Oct 27 2017, 19:34)
Если развить и углУбить мысль в этом направлении, то можно попробовать использовать код Грея,
но для передачи байтов все равно нужна избыточность, хотябы 9 линий
Если есть 9 линий, то при оптимально построенном алгоритме можно передавать примерно до 8.994 бит данных за одну операцию вывода.
Надо просто подмешать сигнал стробирования в данные. При достаточных вычислительных ресурсах на обеих сторонах (приёма и передачи) можно вплотную приблизиться к пределу == 8.994 бит данных за такт на 9-разрядном параллельном интерфейсе.
Автор: x736C Oct 27 2017, 18:43
Цитата(jcxz @ Oct 27 2017, 21:23)
можно вплотную приблизиться к пределу == 8.994 бит данных за такт на 9-разрядном параллельном интерфейсе.
Я так понимаю, что это число в итоге зависит от нестабильности кварцевых генераторов приемника и передатчика.
Если разница между частотами небольшая, то информация о тактовой частоте приемнику нужна реже. В противном случае, чаще.
Предел, равный 8.994 бита, соответствует одному 9-битному слову, отведенному для синхронизации, на 1500 информационных слов.
Почему именно такой предел?
Автор: jcxz Oct 27 2017, 18:46
Цитата(x736C @ Oct 27 2017, 21:43)
Я так понимаю, что это число в итоге зависит от нестабильности кварцевых генераторов приемника и передатчика.
Если разница между частотами небольшая, то информация о тактовой частоте приемнику нужна реже. В противном случае, чаще.
Предел, равный 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 Oct 27 2017, 19:09
Цитата(jcxz @ Oct 27 2017, 21:46)
Нет. При чём тут частоты? Никакие выделенные сигналы тактирования не нужны - сигнал тактирования можно подмешать в данные. Для достижения максимального использования линий.
Видимо, вы меня не поняли. В конечном итоге все сводится все равно к разнице частот передатчика и приемника без ФАПЧ.
Для максимального использования линии для передачи информации необходимо свести к минимуму отношение служебной информации к полезным данным. А это напрямую зависит от нестабильности генераторов. Вы обозначили это отношение, как 1/1500.
Стало интересно, что за алгоритм. Почему именно такое отношение. На мой взгляд, очень неплохая цифра.
UPD. Написал ответ до того, как вы дополнили верхний пост.
Автор: Огурцов Oct 28 2017, 01:50
Цитата(jcxz @ Oct 27 2017, 19:46)
Ну и между кадрами вставляем символы границ кадра == '1' для кадровой синхронизации.
и при потере одного бита будет вылетать целый кадр ? или в среднем половина
а что будет, если происходит задержка одного или нескольких бит относительно других, как такое принять ?
что мешает "неэффективно" использовать девятый (восьмой) бит для простой и надёжной синхронизации ?
можно по обоим фронтам на половинной частоте, чтобы полосу не расширять
Автор: jcxz Oct 28 2017, 06:29
Цитата(Огурцов @ Oct 28 2017, 04:50)
и при потере одного бита будет вылетать целый кадр ? или в среднем половина
Здесь интерфейс параллельный, а не последовательный - передаются
слова.
Цитата(Огурцов @ Oct 28 2017, 04:50)
а что будет, если происходит задержка одного или нескольких бит относительно других, как такое принять ?
Точно так же как при наличии отдельной линии стробирования.
Цитата(Огурцов @ Oct 28 2017, 04:50)
что мешает "неэффективно" использовать девятый (восьмой) бит для простой и надёжной синхронизации ?
Мешает Ваше неумение читать исходные сообщения авторов тем.
Цитата(Огурцов @ Oct 28 2017, 04:50)
можно по обоим фронтам на половинной частоте, чтобы полосу не расширять
Хоть по одному хоть по двум - всё равно используя все 9 бит для данных можно передавать быстрее.
Автор: Огурцов Oct 28 2017, 10:32
Цитата(jcxz @ Oct 28 2017, 07:29)
Здесь интерфейс параллельный, а не последовательный - передаются слова.
а как же это ?:
Цитата
преобразуем 9-битовые символы в битовый поток
любой сбой и весь поток накрылся
Цитата(jcxz @ Oct 28 2017, 07:29)
Точно так же как при наличии отдельной линии стробирования.
нет, линия стробирования стробирует уже устоявшиеся данные
тогда как неустоявшиеся данные сами себя стробировать никак не могут - стробов будет 8 штук, по одному на каждую линию
Цитата(jcxz @ Oct 28 2017, 07:29)
Мешает Ваше неумение читать исходные сообщения авторов тем.
вот пусть и он и ответит, дурацкие желания желательно как-то обосновывать
Цитата(jcxz @ Oct 28 2017, 07:29)
Хоть по одному хоть по двум - всё равно используя все 9 бит для данных можно передавать быстрее.
в теории да, когда канал идеальный
Автор: jcxz Oct 28 2017, 13:27
Цитата(Огурцов @ Oct 28 2017, 13:32)
а как же это ?:
любой сбой и весь поток накрылся
Читайте внимательнее: "это" - описание
алгоритма работы ПО.
Цитата(Огурцов @ Oct 28 2017, 13:32)
нет, линия стробирования стробирует уже устоявшиеся данные
тогда как неустоявшиеся данные сами себя стробировать никак не могут - стробов будет 8 штук, по одному на каждую линию
Почитайте ниже и подумайте "как":
for (;...; recentValue = newValue) {
while (
ReadPort() == recentValue);
newValue =
ReadPort();
...
}
Автор: Огурцов Oct 28 2017, 14:48
Цитата(jcxz @ Oct 28 2017, 13:27)
Читайте внимательнее: "это" - описание алгоритма работы ПО.
алгоритм он или работает, или не работает, а уж в по он или в железе - не суть важно
вы берёте длинное число и последовательно его делите, любой сбой в любом бите приведёт к тому, что все последующие за сбоем данные будут не верны
Цитата(jcxz @ Oct 28 2017, 13:27)
Почитайте ниже и подумайте "как":
да никак, я уже вижу
каждый изменившийся бит станет стробом, получите до восьми стробов на слово
слово гонки слышали когда-нибудь ?
хотя да, у вас же по, в по гонок не бывает
Автор: jcxz Oct 28 2017, 22:34
Цитата(Огурцов @ Oct 28 2017, 17:48)
вы берёте длинное число и последовательно его делите, любой сбой в любом бите приведёт к тому, что все последующие за сбоем данные будут не верны
Когда включаете комп, не удивляетесь как это он работает? Ведь там миллиарды битов! А если в каком-то из этих битов случится сбой - ведь всё же сразу потеряется и все буковки перепутаются! Ужас!!
Цитата(Огурцов @ Oct 28 2017, 17:48)
слово гонки слышали когда-нибудь ?
хотя да, у вас же по, в по гонок не бывает
да уж... no comments... тот случай когда "слышал звон да не знаю где он"
Автор: Огурцов Oct 29 2017, 01:29
Цитата(jcxz @ Oct 28 2017, 22:34)
Когда включаете комп, не удивляетесь как это он работает? Ведь там миллиарды битов! А если в каком-то из этих битов случится сбой - ведь всё же сразу потеряется и все буковки перепутаются! Ужас!!
там везде стробирование, вот ничего и не путается
Цитата(jcxz @ Oct 28 2017, 22:34)
да уж... no comments... тот случай когда "слышал звон да не знаю где он"
вы не поверите, и там - тоже
Автор: kolobok0 Oct 29 2017, 12:33
Цитата(IJAR @ Oct 27 2017, 11:57)
Возможно ли создать или существует ...будут только шины передачи данных (например 8) ...
странный вопрос, от опытного товарища и с большим опытом в данной области.
собственно ответ прозвучал - на стандартном centronics-е делали в своё время и свои, на какой нить 8255 (PPI) - сразу 24 пина (8+8+2*4) и дистанционно сливали-форматировали винты,
до эпохи сетевых карт, при ремонте писюков...по разному было..
Если чиссо по теме - ближе помнится мне, решение связи по стандартному LPT с передачей по полубайту в одну сторону. С полной шинкой(8бит) получается полный дуплекс(по 4) постоянно. При этом
по скорости лучше подходит стробирование делать на аппаратном уровне(+1 бит в каждую сторону, в данном примере), а подтверждение достоверности - софтово.
как то так
(круглый)
ЗЫ
Параллельным имхо, обзываем возможность засунуть одинаковые по типу сигналы на физ. уровне за один строб(как физический так и логический - пофигу) передачи.
Автор: Огурцов Oct 29 2017, 13:57
с некоторого весьма далёкого времени lpt имел двунаправленный режим и стробирование на аппаратном уровне
так что передавать половинки вместо целого байта было бы весьма криво, медленно и вообще неправильно
Автор: IJAR Oct 29 2017, 17:49
Автор: jcxz Oct 30 2017, 12:01
Цитата(IJAR @ Oct 29 2017, 20:49)
И тем не менее вынужден поднять тему.
Так ответы Вам уже были даны. Они чем то не подходят?
Автор: IJAR Oct 30 2017, 12:57
Цитата(jcxz @ Oct 30 2017, 15:01)
Так ответы Вам уже были даны. Они чем то не подходят?
Спасибо за обсуждение
Автор: Shivers Dec 5 2017, 05:41
Может немного запоздало. Но да, такие интерфейсы существуют с 70-80х годов. Читайте книги В.И. Варшавского. Если кратко - вводится вторая (служебная) фаза передачи, и (в качестве одного из вариантов) парафазное кодирование сигналов. Данные передаются в рабочей фазе, служебная фаза используются в качестве разделителя. На принимающей стороне фаза определяется по коду в сигнальных линиях. Сигнал сопровождения при таком протоколе передачи не нужен, кодирование в линиях противогоночное - состязания отсутствуют. Из-за второй фазы протокол не самый быстрый, а при парафазном кодировании еще и сильнопотребляющий (переключательная активность проводов 100% за цикл передачи). На практике вроде бы это в TRIMOSBUS применялось, но не уверен.
Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)