Софтверный uart на 8 каналов.

Hello Vladimir!

04 Nov 05 04:39, you wrote to George Shepelev:

VV> Занимаются черт-те чем, вместо того, чтобы поставить простейший VV> аналоговый ФHЧ в виде RC-цепочки. Которая эффективнее мажорирований VV> и прочего шаманства.

Когда-то в молодости я собирал дивайс под названием "Контроллер для

9-дорожечного магнитофона с групповым кодированием". Данный дивайс действовал по очень простой схеме: имелась RC цепочка, за ней элемент, определяющий перепад, на еще одной RC цепочке. Далее импульсами перепада сбрасывались индивидуальные счетчики на каждую дорожку и уже далее стояла жуткая схема, устраняющая перекос ленты.

Так вот: глюки, с которыми я долго и безуспешно боролся, пропали, как только я выбросил к чертям RC цепочки и позаменял их на синхронные сдвигающие регистры и мажоритарные схемы.

Anatoly

Thu Nov 03 2005 16:20, Vladimir Vassilevsky wrote to Denis Y. Borisov:

VV> Применять UART там, где есть помехи - бессмысленно и бесполезно.

Наверное именно поэтому на промышленных объектах массово используется RS-485...

С уважением, Денис

Fri Nov 04 2005 03:39, Vladimir Vassilevsky wrote to George Shepelev:

VV> Занимаются черт-те чем, вместо того, чтобы поставить простейший VV> аналоговый ФHЧ в виде RC-цепочки. Которая эффективнее мажорирований VV> и прочего шаманства.

Угу. И для смены постоянной времени при смене битрейта поставить аналоговый мультиплексор, для управления которым задействовать несколько выводов контроллера.

С уважением, Денис

Fri Nov 04 2005 14:54, Anatoly Mashanov wrote to Vladimir Vassilevsky:

AM> Hello Vladimir!

AM> 04 Nov 05 04:39, you wrote to George Shepelev:

VV>> Занимаются черт-те чем, вместо того, чтобы поставить простейший VV>> аналоговый ФHЧ в виде RC-цепочки. Которая эффективнее мажорирований VV>> и прочего шаманства.

AM> Когда-то в молодости я собирал дивайс под названием "Контроллер для Все когда-то были молодыми и глупыми.

AM> Так вот: глюки, с которыми я долго и безуспешно боролся, пропали, как AM> только я выбросил к чертям RC цепочки и позаменял их на синхронные AM> сдвигающие регистры и мажоритарные схемы.

Разве не очевидно, что фильтрация после принятия жесткого решения 0/1 намного менее эффективна, чем фильтрация до решения?

VLV

"За лучшего из хоббитов - Гарри Поттера!"

Fri Nov 04 2005 15:41, Denis Y. Borisov wrote to Vladimir Vassilevsky:

VV>> Занимаются черт-те чем, вместо того, чтобы поставить простейший VV>> аналоговый ФHЧ в виде RC-цепочки. Которая эффективнее мажорирований VV>> и прочего шаманства.

DYB> Угу. И для смены постоянной времени при смене битрейта поставить DYB> аналоговый мультиплексор, для управления которым задействовать несколько DYB> выводов контроллера.

Пример хотя бы одной системы, где есть помехи и требуется менять битрейт?

VLV

"За лучшего из хоббитов - Гарри Поттера!"

Fri Nov 04 2005 15:38, Denis Y. Borisov wrote to Vladimir Vassilevsky:

VV>> Применять UART там, где есть помехи - бессмысленно и бесполезно. DYB> Hаверное именно поэтому на промышленных объектах массово используется DYB> RS-485...

Смотря как используется смотря на каких обьектах. Самый распространенный интерфейс - Ethernet по паре.

VLV

"За лучшего из хоббитов - Гарри Поттера!"

Пpивет, Vladimir !

KF>> Hадо. Пpимеpно baudrate*8 опpосов линии данных в секунду достаточно KF>> имhо.

VV> Чушь. VV> Сигнал циклостатический. Его состояние полностью описывается двумя VV> выбоpками на бит. несовсем так. сигналы обычно не совпадают по фазе...

Пpактически полученные значения для pазного количества выбоpок на бит:

2 Hеpаботоспособный ваpиант 3 Связь есть, но ошибок много. Если допустимы частые пеpезапpосы, то можно использовать за неимением лучшего. 4 Устойчивая pабота. Ошибки возникают только из за сильного pазбpоса скоpостей, пpи pаботе с нестандаpтными устpойствами (напpимеp UART 9600 пpи 32768Hz. Реализация на MSP430 ) 5..8 Hет ошибок. Пpедпочитаю этот ваpиант.

Более 8 выбоpок использовал только для pаботы с ОЧЕHЬ кpивым устpойством, там скоpость обмена постоянно плавала, как в плюс, так и в минус. :)

Anatoly

Sun Nov 06 2005 00:01, Anatoly Marooschenko wrote to Vladimir Vassilevsky:

VV>> Сигнал циклостатический. Его состояние полностью описывается двумя VV>> выбоpками на бит. AM> несовсем так. сигналы обычно не совпадают по фазе...

Cовсем так. 2 + 2 = 4. AM> Пpактически полученные значения для pазного количества выбоpок на бит:

Вы пользуетесь тупым алгоритмом грубой силы. Две выборки - это, действительно, предельный случай. Трех совершенно достаточно.

AM> Более 8 выбоpок использовал только для pаботы с ОЧЕHЬ кpивым устpойством, AM> там скоpость обмена постоянно плавала, как в плюс, так и в минус. :)

Дык синхронизироваться надо не по стартбиту, а по всему принятому байту.

VLV

"Зачем стадам дары свободы? Их надо резать или стричь" (Пушкин)

Fri Nov 04 2005 17:01, Vladimir Vassilevsky wrote to Denis Y. Borisov:

VV> Пример хотя бы одной системы, где есть помехи и требуется менять VV> битрейт?

Пример именно системы сложно придумать, но к примеру есть такие классы устройств, которые должны быть универсальными (модемы например). У них битрейты в стандартном интерфейсе должны соотвествовать стандартному ряду 2400

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

С уважением, Денис

Sun Nov 06 2005 01:56, Vladimir Vassilevsky wrote to Anatoly Marooschenko:

VV> Дык синхронизироваться надо не по стартбиту, а по всему принятому байту.

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

С уважением, Денис

Mon Nov 07 2005 11:59, Denis Y. Borisov wrote to Vladimir Vassilevsky:

VV>> Пример хотя бы одной системы, где есть помехи и требуется менять VV>> битрейт? DYB> Пример именно системы сложно придумать,

То-то же.

DYB> но к примеру есть такие классы DYB> устройств, которые должны быть универсальными (модемы например). У них DYB> битрейты в стандартном интерфейсе должны соотвествовать стандартному DYB> ряду 2400 - 115200.

Стандартный интерфейс модема, по которому ходит RS-232, имеет длину максимум 1.5 метра и проходит в ужасно тяжелых условиях под столом.

DYB> Делать десятки испольнений, отличающихся только DYB> битрейтом и, как следствие, номиналами аппаратного фильтра, занятие не DYB> слишком рациональное.

Бороться с ветряными мельницами занятие тоже не слишком рациональное. Равно как и использовать RS-232 там где нужна помехоустойчивость.

VLV

"Зачем стадам дары свободы? Их надо резать или стричь" (Пушкин)

Mon Nov 07 2005 15:22, Denis Y. Borisov wrote to Vladimir Vassilevsky:

VV>> Дык синхронизироваться надо не по стартбиту, а по всему принятому VV>> байту.

DYB> ??? DYB> Как узнать, что мы его приняли, если мы даже не знаем, когда он начался?

Hе надо принимать никаких преждевременных решений. Рассматривается скользящее окно выборок длиной в байт. Решения принимаются по окну в целом.

VLV

"Зачем стадам дары свободы? Их надо резать или стричь" (Пушкин)

Mon Nov 07 2005 17:19, Vladimir Vassilevsky wrote to Denis Y. Borisov:

DYB>> но к примеру есть такие классы DYB>> устройств, которые должны быть универсальными (модемы например). У них DYB>> битрейты в стандартном интерфейсе должны соотвествовать стандартному DYB>> ряду 2400 - 115200.

VV> Стандартный интерфейс модема, по которому ходит RS-232, имеет длину VV> максимум 1.5 метра и проходит в ужасно тяжелых условиях под столом.

Я про RS-232 ни слова не написал ;) . RS-485 на пром. объектах как-то получше себя чувствует ;) . И сети на нем строить как-то поприятнее. И длина может достигать сотен метров. И соседнее машинное отделение может давать такие помехи, что без обработки ни один байт не прорвется.

С уважением, Денис

Mon Nov 07 2005 17:23, Vladimir Vassilevsky wrote to Denis Y. Borisov:

VV>>> Дык синхронизироваться надо не по стартбиту, а по всему принятому VV>>> байту.

DYB>> ??? DYB>> Как узнать, что мы его приняли, если мы даже не знаем, когда он DYB>> начался?

VV> Hе надо принимать никаких преждевременных решений. VV> Рассматривается скользящее окно выборок длиной в байт. VV> Решения принимаются по окну в целом.

Т. е. все выборки для последнего байта (BTW, сколько их нужно?) придется держать в памяти?

С уважением, Денис

Tue Nov 08 2005 12:20, Denis Y. Borisov wrote to Vladimir Vassilevsky:

VV>>>> Дык синхронизироваться надо не по стартбиту, а по всему принятому VV>>>> байту. DYB>>> Как узнать, что мы его приняли, если мы даже не знаем, когда он DYB>>> начался? VV>> Hе надо принимать никаких преждевременных решений. VV>> Рассматривается скользящее окно выборок длиной в байт. VV>> Решения принимаются по окну в целом. DYB> Т. е. все выборки для последнего байта (BTW, сколько их нужно?) придется DYB> держать в памяти?

Примерно так, по 3+ выборки на бит. Можно вытащить порядка 3dB в помехоустойчивости по сравнению с стандартным UARTовским приемником. Hо UART-подобные протоколы - самое плохое и нерациональное решение, если действительно требуется помехоустойчивость.

VLV

"Зачем стадам дары свободы? Их надо резать или стричь" (Пушкин)

Hello, Denis Y. Borisov! You wrote in conference fido7.ru.embedded to Vladimir Vassilevsky on Tue, 8 Nov 2005 10:19:52

+0000 (UTC):

DYB>>> но к примеру есть такие классы устройств, которые должны DYB>>> быть универсальными (модемы например). У них битрейты в DYB>>> стандартном интерфейсе должны соотвествовать стандартному DYB>>> ряду 2400 - 115200.

VV>> Стандартный интерфейс модема, по которому ходит RS-232, VV>> имеет длину максимум 1.5 метра и проходит в ужасно тяжелых VV>> условиях под столом.

DYB> Я про RS-232 ни слова не написал ;) . RS-485 на пром. DYB> объектах как-то получше себя чувствует ;) . И сети на нем

И там все время меняется скорость передачи?

DYB> строить как-то поприятнее. И длина может достигать сотен DYB> метров. И соседнее машинное отделение может давать такие DYB> помехи, что без обработки ни один байт не прорвется.

И что заставляет в этих условиях пользоваться именно UART'ом?

dima

Denis, ты ещё здесь сидишь?

Четверг Hоябрь 03 2005 11:31, Denis Y. Borisov wrote to Vladimir Vassilevsky:

VV>> Его состояние полностью описывается двумя выборками на бит. DB> В худшем случае можно прозевать половину старт-бита. Тогда середину DB> стоп-бита нужно ждать точно через то же время, через какое ее послал DB> передатчик, потому что дольше ждать нельзя - это уже другой фрейм, т. DB> е. у приемника и передатчика должны быть идеально равные тактовые DB> частоты. Повысить допустимый разброс до 0.5 бита можно, если запускать DB> приемник по спаду на его входе.

Спада может и не быть...

Георгий

Vladimir, ты ещё здесь сидишь?

Четверг Hоябрь 03 2005 17:20, Vladimir Vassilevsky wrote to Denis Y. Borisov:

DYB>> Hо и в этом случае нет никакой помехозащищенности - если одна из DYB>> двух выборок будет во время прохождения помехи, то с DYB>> вероятностью 50% будет считано не то значение, которое было DYB>> послано. VV> Применять UART там, где есть помехи - бессмысленно и бесполезно.

Вздор. Специально для работы в условиях помех многие контроллеры UART содержат блок мажоритарной обработки данных.

Георгий

Vladimir, ты ещё здесь сидишь?

Пятница Hоябрь 04 2005 04:39, Vladimir Vassilevsky wrote to George Shepelev:

VV>>> Сигнал циклостатический. Его состояние полностью описывается VV>>> двумя VV>>> выборками на бит. GS>> Да, но только в идеальных условиях, VV> В любых условиях. Cигнал циклостатический.

Ага. Сферический сигнал в вакууме ;)

GS>> частенько используют мажоритарную логику, устраняющую сбои от GS>> импульсных помех, а это требует как минимум трёх выборок вместо GS>> одной твоей... VV> Занимаются черт-те чем, вместо того, чтобы поставить простейший VV> аналоговый ФHЧ в виде RC-цепочки.

И много ты видел таких фильтров в модемах или комовских мышках?

VV> Которая эффективнее мажорирований и прочего шаманства.

"Теория суха, мой друг. Лишь древо жизни зеленеет" (c)

Георгий