Связь двух мег по UART, Если кому интересно - результаты экспериментов :) Опции

[AndyBig]

Как-то я задавал тут вопрос про максимальную дальность связи двух мег по UART без дополнительных преобразователей. Недавно дошли руки попробовать все это самому.
Условия:
- две платы, на одной МЕГА8 (подчиненная), на другой МЕГА16 (ведущая)
- плоский 5-жильный кабель с сигналами: земля-txd-земля-rxd-земля, 6 метров, лежащий поверх клубка кабелей (силовые, езернет, USB) позади системного блока компьютера .
- выходной сигнал UART (txd) каждого контроллера идет через логический буфер, входной (rxd) - от разъема резистор 33 Ома, далее подтяжка 10 КОм и на вход RXD.
- параметры протокола: 9N1
- в МЕГЕ8 включен режим мультипроцессорной связи
- передаются пакеты - сначала байт адреса, потом заголовок и данные пакета, всего около 100 байт на пакет, все принимаемое проверяется по CRC.

Результаты:
- на скорости 1 МБит/сек примерно 0,4% ошибок.
- на скоростях 500 КБит/сек и меньше за время непрерывной работы в течении 5-6 часов ошибок не выявлено.

Надеюсь, эта информация окажется кому-нибудь полезной. Или хотя бы интересной .

[Woodoo]

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

Кстати, незабудем что уарт ето не рс-232, и тем более не 485. логические уровни при "клубе" кабелей могут искажаться(ЭМС епрст)... скорость скажи?!

PS.: редактирую вот, патамучто невнимательно прочитал (на счет скоростей): я так понимаю скорости не стандартные, но ето то и не важно.... если в обоих контроллерах кварц и прескалер на уарт одинаковые... рекомендация - использовать 485 с его дифференциальными сигналами и витой парой. Возможно развязку делать оптическую или на "адумах" (ну ето если припрет)

Сообщение отредактировал Woodoo - Jun 13 2006, 21:27

[AndyBig]

Кварцы 16 МГц на обоих контроллерах, прескалеры (UBRR) = 1.

Дык я ведь указал скорости в результатах .

логические уровни при "клубе" кабелей могут искажаться(ЭМС епрст)...

В этом, в основном, и стоял передо мной вопрос: можно ли при наличии близко проходящих силовых кабелях достигнуть без ошибок скорости 300-400 КБит/сек на расстоянии 1,5-2 метров.

рекомендация - использовать 485 с его дифференциальными сигналами

Так и поступлю, если понадобится протянуть сигналы на расстояние больше 5 метров . До 5 метров, как показали эксперименты, это необязательно (при скорости <= 500 КБит/сек).

[Woodoo]

возможно добиваться большей надежности не стоит, если используеться проверка црц. На счет протакола 9н1 не знаю, есть ли там возможность перезапросить испорченый пакет?, но если есть, то вроде беспокоица неочем.
На счет влияния кабелей - силовой кабель, если ето тот что питает камп, влиять не должен, памучто частота тока маловата. усб и прочее - отпадает - малая энергетика сигналоф. Ради эксперимента папробуй взять экранированый кабель (Мне даже самому интересно стало, уменьшиться ли при етом процент ошибки?!).
имхо: при таких расстояниях оправдано использовать другие последовательные, синхронизированные, чтонить типо I2C (1-Ware??? мож? )

[Alex B._]

Э-э-э, а как бы мега тут при чем? Я уверен, что такие же результаты вы получите с любыми 5 вольтовыми контроллерами.
Смысл то есть глубокий в эксперименте, или подтекст какой?
Я например знаю, что выпускаются емкостные датчики уровня топлива с UART с TTL уровнями (собираюсь в разрабатываемой системе использовать). Через всю машину тянутся провода (правда в экранированной кишке), а там ЭМ обстановка, я думаю, похуже чем сзади вашего системного блока =)
И это работает =)

[Woodoo]

интересно, ето почему там ЭМ обстановка по жощще? чему там помехи генирить? зажэганию? ну от него отфильтроваться можно(нужно). темболее при ттл? (не к-моп же!) Плюс Вы говарите в экране, да еще, возможно, 12 вольтовая логика используеться!

[kkk]

А можно ссылочку выложить по этим датчикам? Тоже очень интересуюсь.

[AndyBig]

возможно добиваться большей надежности не стоит, если используеться проверка црц. На счет протакола 9н1 не знаю, есть ли там возможность перезапросить испорченый пакет?, но если есть, то вроде беспокоица неочем.

Мне нужна определенная пропускная способность канала. Если мне придется перезапрашивать каждый 10й пакет (в среднем), это будет не очень хорошо . Ну и надежность вообще - существует ведь вероятность ошибки, не проверяемой по CRC...
По поводу 9N1 - он никак не привязан к возможности перезапросить пакет. Это делает софтовый обработчик верхнего протокола.

Ради эксперимента папробуй взять экранированый кабель

Увы, нет под рукой двухжильного экранированного кабеля...

при таких расстояниях оправдано использовать другие последовательные, синхронизированные, чтонить типо I2C

Не хочу синхронные, хочу асинхронные . К тому же в девайсах есть свои ньюансы.

Э-э-э, а как бы мега тут при чем? Я уверен, что такие же результаты вы получите с любыми 5 вольтовыми контроллерами

Ну, не факт. Это ведь зависит не только от уровня сигналов, но и, например, от количества сэмплов, по которым принимается решение о значении очередного бита. Меги принимают решение по 16 (или по 8 на удвоенной скорости) сэмплам. Кроме того, у Мег стоит на входе RXD фильтр...

а там ЭМ обстановка, я думаю, похуже чем сзади вашего системного блока =)

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

[vesago]

Спасибо. Буду знать если что. Меня тоже интересовала данная тема, но все не доходили руки эксперименты проводить.

[TomaT]

Да, интересно получилось, спасибо. Щас мне то же надо будет мегу с тиньками 2313 соединять. А там управление шаговиками и двумя аргоновыми сварочниками с осцилляторами (считай то же зажигание), да сварочники импульсные на 150А. Вот где блин ЭМП.
Думаю мож токовую петлю замутить? Как думает народ?

ЗЫ Правда скорость передачи вполне можно и 9600.

[Alex B._]

>> А можно ссылочку выложить по этим датчикам?
>> Тоже очень интересуюсь.

Да пожалуйста:
http://www.omnicomm.ru/lls.html
http://www.asva.ru/products/ckpt.asp
И это еще не все. Стоит обратить внимание, что все они, как правило, продаются в составе системы, поэтому покупку одних датчиков нужно обговаривать с производителем отдельно.

>> Ну, не факт. Это ведь зависит не только от уровня
>> сигналов, но и, например, от количества сэмплов

Тут вы наверное правы. Но частоты захвата меньше чем 8*F я чего то не видел ни в одном контроллере.

>> Вот по питанию там хуже, это да...
Ну питание, извините, подается по длинным-длинным проводам =)

[SasaVitebsk]

Когда-то случайно с одним из дисков мне попалась электронная книга про модемы. Там доступным русским языком кратко изложены методы передачи, сжатия, коррекции ошибок, протоколы, протоколы соединения. После этого я очень долго работал с этой книгой. И скажу что она совсем не бесполезна в обычных проектах не связанных с модемами. Многие, из описанных протоколов, мне позднее приходилось реализовывать. Делал сжатие и коррекцию ошибок. Проверял всё это в различных условиях. Реализовывал протокол коррекции ошибок при работе с пакетами переменной длины. (т.е. чем меньше ошибок, тем длиннее пакет) По ходу передачи обрабатывается статистика. Таким образом добивался передачи данных по линии по которой не разобрать речи. При чём скорость не сильно падала.
В часности по rs232 пришёл к аналогичным выводам. Правда высоких скоростей мне не требовалось, а так получается что при применении стандартных приёмопередатчиков на стандартных расстояниях применение протоколов типа MODBUS и т.п. не оправдано. А вот при применении стандарта rs485 в режиме двунаправленной работы протокол типа MODBUS имеет глубокий смысл.

Пришёл также ещё к одному выводу:
Надёжность изделия определяется не только надёжностью применённых деталей, качеством изготовления, но и во многом применёнными протоколами связи и выбранными алгоритмами работы с данными. Очень помогает применение многоуровнего програмного обеспечения. Где каждый уровень контролирует данные поступившие с предыдущего.

Поэтому Ваши исследования это один из важных, на мой взгляд, шагов к созданию действительно надёжных изделий.
А книга у меня сохранилась. Жаль автора нет. В любом случае выражаю ему свою благодарность.

[AndyBig]

Протоколы, разумеется, нужно выбирать, исходя из конкретных потребностей конкретной разработки. Мне, например, не нужно передавать большие объемы данных, то есть нет смысла делать адаптивную длину пакетов, нужно передавать кучу мелких пакетов (команды с параметрами) часто и быстро . Само собой, кроме отсеивания помех на уровне железа, необходимо предусматривать и коррекцию (или хотя бы обнаружение) ошибок на уровне протокола. У меня это сделано несколькими путями, CRC - только один из них. По поводу сильных внешних ЭМИ, то у меня они не предусматриваются. Но в случае TomaT-а я бы не поленился защититься не только протоколом .

А книга у меня сохранилась.

А не могли бы Вы выложить ее где-нить? Или прислать мне на мыло andybig на сервере neora.ru

[defunct]

AndyBig

на скоростях 500 КБит/сек и меньше за время непрерывной работы в течении 5-6 часов ошибок не выявлено.

Поздравляю!
Помнится у Вас задача была несколько иная - соединить несколько (больше 2х) МК в сеть по УАРТу.
Уже попробовали?

Когда-то случайно с одним из дисков мне попалась электронная книга про модемы. Там доступным русским языком кратко изложены методы передачи, сжатия, коррекции ошибок, протоколы, протоколы соединения. После этого я очень долго работал с этой книгой.
....

А книга у меня сохранилась. Жаль автора нет. В любом случае выражаю ему свою благодарность.

Если есть возможность может выложите где-нибудь? Очень заинтересовала эта книга.

Или прислать мне на мыло

и мне! ;> defunct собака freenet.de

[SasaVitebsk]

Если есть возможность может выложите где-нибудь? Очень заинтересовала эта книга.

Сканированная. В rar архиве 6М занимает. Но почитать стоит. Или когда понадобится, - заглянуть.

Говорите куда, - выложу для всеобщего. Скажем спасибо неизвестному автору. К письму не присоединится. Большая. Могу на мыло, но кому-нибудь, кто для всех выложит. А то 10 раз передавать как-то не очень ...