UART без кварца

Mar 21, 2005 Last reply: 21 years ago 42 Replies

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

Понедельник Март 28 2005 00:34, Alexander Golov wrote to George Shepelev:

AG>>> Мне тоже нужно будет сделать изделие как раз на этом же МК AG>>> (из-за корпуса TSSOP-14 и UART'а), причём единичиное и AG>>> работающее от минус 20 С до +60 C. Ставить кварц не хочется, он AG>>> практически удвоит площадь занимаемую узлом, да и режим работы AG>>> тяжёлый по вибрациям (узел закреплён консольно на штанге в AG>>> воздушном потоке), так что чем меньше кварцев тем лучше. В общем AG>>> действительно интересно, как там у него со стабильностью (в AG>>> принципе готов отобрать из нескольких экземпляров). GS>> Отбирать экземпляры - на редкость тоскливое "удовольствие", с GS>> учётом, что отбирать придётся с проверкой работы _в диапазоне GS>> температур_. Работать, скорее всего, будет. В виде макета и GS>> опытного экземпляра. Hо делать так массовую продукцию всё-таки GS>> стрёмно (к примеру трудно угадать, что у RC-генератора будет с GS>> временнОй стабильностью). AG> Hу какая ещё массовая продукция?

Тебе виднее! ;-)

AG> Я ведь прямо сказал: мне нужен _ОДИH_ экземпляр изделия, ну может на AG> всякий случай сделаю второй.

Устройство отвественное и работает в широком диапазоне температур? В таком случае я бы на стабильность RC-генератора не закладывался...

AG>>> Подстраивать OSCTUNE не могу: зацепиться не за что (связь AG>>> однонаправленная), разве что применить какое-то автоопределение AG>>> скорости на приёмном конце (dsPIC30F4011), правда там МК очень AG>>> сильно нагружен. GS>> Я бы всё-таки поставил кварц - куча головняка исчезнет GS>> _принципиально_. Идея работы без кварца хороша _в комнатных_ GS>> условиях (или когда небольшое отклонение частоты не слишком GS>> важно). AG> Hу уж такая куча исчезнет!

;)

AG> А то, что вибронагрузка на узел торчащий в сверхзвуковом потоке будет AG> просто труднопредсказуемой и мне совсем не светит производить AG> эксперименты (такие простые и дешёвые, надо заметить, не то, что

Ладно, уговорил. Вот тебе ещё пара идеек:

1) Подать опорную частоту снаружи (контроллер с PLL сможет "разогнать" её "вверх" до требуемой)

2) Взять интерфейс с более простой синхронизацией (к примеру SPI),

В любом случае добавляется простенький/дешёвый "внешний" узел (кварцевый генератор или однокристаллка), но на фоне прочей механики это просто копейки...

Георгий

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

Понедельник Март 28 2005 00:40, Alexander Golov wrote to George Shepelev:

OR>>>> Можно перейти на 5-битовую посылку в UART, это немного OR>>>> расширит диапазон частот, в которых ещё будет нормально OR>>>> приниматься - допустимое отклонение будет в 1.4 раза больше. OR>>>> 5-ый бит в послыке использовать для индикации - это старший OR>>>> ниббл или младший, на самом нижнем уровне делать OR>>>> разборку/сборку байтов, верхние уровни протокола ничего и не OR>>>> заметят. AG>>> Вот! Это действительно интересный вариант. GS>> А девайс "с другой стороны" на такой режим получится настроить? GS>> Кстати, видимо придётся использовать два стоп-бита... AG> А что там настраивать? Меняется только содержимое байта (только 5 AG> значащих разряжов, остальные -- возбуждение линии) и никакие доп. AG> стоп-биты конечно не требуются.

Hу, по такой методе и 4-х, и 3-х битные посылки выдавать можно ;) Требования к точности частоты ещё больше снизятся, правда скорость упадёт...

Кстати, в своё время я игрался с однопроводным интерфейсом, в котором данные передавались скважностью импульсов, идущих с постоянной частотой. При этом требования к точности тактовой частоты ещё ниже, поскольку синхронизация производится на _каждом_ бите. Скорость чуть ниже, чем у "манчестера", зато нет проблем с вхождением в синхронизм и можно работать в асинхронном режиме.

время ──┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─────┼─>

логические 0 0 1 1 0 биты ┌──┐ ┌──┐ ┌────────┐ ┌────────┐ ┌──┐ ┌ сигнал │ │ │ │ │ │ │ │ │ │ │ в линии ──┘ └────────┘ └────────┘ └──┘ └──┘ └────────┘

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

Георгий

Tue Mar 29 2005 03:13, Alexander Golov wrote to Vladislav Baliasov:

AG> Т.е., если я правильно понял, ты предлагаешь использовать, скажем, пару AG> UART'вских битов в качестве одного манчестерского?

Оверхед большой, а тольку-то. Принимать все равно на UART.

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

Мне очень понравился вариант с перекодированием 6 полезных битов в 8 битов UART. Без постоянки, эффективная полоса частот примерно от 1/10 до 1/2 от битрейта, плюс шесть служебных символов.

AG> Бинго! И всё ценой 2-х простейших таблиц.

Аналогично.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Привет!

Mon Mar 28 2005 03:34, Alexander Derazhne wrote to Alexander Golov:

... VB>>> А если ты не ограничен именно UARTом, то можно использовать и VB>>> синхронную передачу, манчестерское или бифазное кодирование. Там VB>>> допуски еще больше...

AG>> Hасчёт синхронного вряд ли -- у меня только одна пара. Остальное AG>> попробовать можно, правда это уже совсем другой уровень нагрузки на AG>> приёмную сторону (хотя бы чисто алгоритмически).

AD> Если эта пара действительно физическая пара и протокол взаимодействия AD> можно слегка подкорректировать, то пусть приёмная сторона инициирует AD> передачу байта (пакета) передачей байта нулей, т.е. 9 бит, а приёмная AD> пусть засекает их длительность.

Пара физическая. В основе 50-метровый экранированный 4-парный кабель CAT5: одна пара питание 5 В (внутри 3,3 В), две -- основные данные в две стороны (LVDS) и оставшуюся хочу применить вот для передачи этой дополнительной информации.

AD> А может быть получится ещё проще - передать по той-же паре тактовую AD> от приёмной стороны, разделив её с данными не слишком сложными фильтрами. AD> Или противоместной схемой. И питание туда-же...

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

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Mon Mar 28 2005 08:34, Vladislav Baliasov wrote to Alexander Golov:

...

VB>>> А если ты не ограничен именно UARTом, то можно использовать и VB>>> синхронную передачу, манчестерское или бифазное кодирование. Там VB>>> допуски еще больше...

AG>> Hасчёт синхронного вряд ли -- у меня только одна пара.

VB> Я имею в виду самосинхронизирующиеся протоколы (бифазное и манчестерское VB> кодирование обладает такой возможностью), а вовсе не выделение отдельной VB> линии для передачи синхронизации

AG>> Остальное попробовать можно, правда это уже совсем другой уровень AG>> нагрузки на приёмную сторону (хотя бы чисто алгоритмически).

VB> Если есть аппаратный USART - то практически нисколько (но нужно VB> обеспечить поиск синхропреамбулы и, при необходимости восстанавливать VB> синхронизацию - но при зашумленном канале и асинхронный протокол тоже VB> может сбиться). Если приемник программный - да и в этом случае большого VB> различия от UART нет.

Т.е., если я правильно понял, ты предлагаешь использовать, скажем, пару UART'вских битов в качестве одного манчестерского? В общем это на ту же тему перекодировки исходных 8 значащих разрядов в меньшее количество значащих, но без постоянной составляющей. В пределе я задаюсь условием не более двух одинаковых битов подряд, обрамляю каждый байт UART'овскими стартом и стопом и получаю 44 доступных комбинации. Вполне хватит для кодирования 4/5-разрядных данных, плюс целая куча служебных символов и устойчивость к сдвигу частоты процентов на 20 минимум. Бинго! И всё ценой 2-х простейших таблиц.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Hello George.

24 Mar 05 13:26, you wrote to me:

GS> Даже если первые пришедшие информационные биты имеют тот-же логический GS> уровень, что и старт-бит? ;-)

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

Alexey

Пpивет, Alexander!

*** 29 Mar 05 01:13, Alexander Golov wrote to Vladislav Baliasov:

VB>> асинхронный протокол тоже может сбиться). Если приемник VB>> программный - да и в этом случае большого различия от UART нет.

AG> Т.е., если я правильно понял, ты предлагаешь использовать, скажем, AG> пару UART'вских битов в качестве одного манчестерского?

Hет, вообще использовать синхронный режим передатчика (если есть) или сделать его программную реализацию. Заодно исчезнет постоянная составляющая, что может облегчить реализицию развязки (если вдруг нужно).

AG> каждый байт UART'овскими стартом и стопом и получаю 44 доступных AG> комбинации. Вполне хватит для кодирования 4/5-разрядных данных, плюс AG> целая куча служебных символов и устойчивость к сдвигу AG> частоты процентов на 20 минимум. Бинго! И всё ценой 2-х простейших AG> таблиц.

Вообще любопытно, но я бы отказался от UARTа. Впрочем, случаи - они разные....

с уважением Владислав

Привет!

Tue Mar 29 2005 08:51, Alexey Gushin wrote to George Shepelev:

...

GS>> Даже если первые пришедшие информационные биты имеют тот-же логический GS>> уровень, что и старт-бит? ;-)

AG> В реальных протоколах всегда есть пауза > времени посылки одного байта.

Совершенно не обязательно.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Mon Mar 28 2005 12:37, George Shepelev wrote to Alexander Golov:

...

GS> Ладно, уговорил. Вот тебе ещё пара идеек:

GS> 1) Подать опорную частоту снаружи (контроллер с PLL сможет "разогнать" GS> её "вверх" до требуемой)

GS> 2) Взять интерфейс с более простой синхронизацией (к примеру SPI),

GS> В любом случае добавляется простенький/дешёвый "внешний" узел (кварцевый GS> генератор или однокристаллка), но на фоне прочей механики это просто GS> копейки...

Всё это ничем неоправданное усложнение.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Tue Mar 29 2005 10:39, Vladislav Baliasov wrote to Alexander Golov:

...

VB>>> асинхронный протокол тоже может сбиться). Если приемник VB>>> программный - да и в этом случае большого различия от UART нет.

AG>> Т.е., если я правильно понял, ты предлагаешь использовать, скажем, AG>> пару UART'вских битов в качестве одного манчестерского?

VB> Hет, вообще использовать синхронный режим передатчика (если есть) или VB> сделать его программную реализацию. Заодно исчезнет постоянная VB> составляющая, что может облегчить реализицию развязки (если вдруг нужно).

У dsPIC только UART, а не USART. Из синхронных интерфейсов свободен только I2C.

AG>> каждый байт UART'овскими стартом и стопом и получаю 44 доступных AG>> комбинации. Вполне хватит для кодирования 4/5-разрядных данных, плюс AG>> целая куча служебных символов и устойчивость к сдвигу AG>> частоты процентов на 20 минимум. Бинго! И всё ценой 2-х простейших AG>> таблиц.

VB> Вообще любопытно, но я бы отказался от UARTа. Впрочем, случаи - они VB> разные....

А зачем, ведь UART то второй свободен? А так получается полоса как у манчестера (2T...T), лишь двухкратный рост запросов на прерывание, а наличие множества уникальных служебных символов делают протокол бронебойным без анализа и откатов, а приёмо-передающий автомат совсем примитивным. Вот если выделить UART нет возможности, тогда да, интересными становятся другие варианты.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Tue Mar 29 2005 03:46, Vladimir Vassilevsky wrote to Alexander Golov:

...

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

VV> Мне очень понравился вариант с перекодированием 6 полезных битов VV> в 8 битов UART. Без постоянки, эффективная полоса частот примерно от VV> 1/10 VV> до 1/2 от битрейта, плюс шесть служебных символов.

В дисковом накопителе APPLE II использовался код 6&2, насколько я помню всего там было 66 кодов. А как у тебя получилось 70 кодов применительно к UART'у? Я как не считал, самое близкое что получается это 82 кода при условии не более 2 нулей и 3 единиц подряд.

Кстати, весьма интересно выглядит условие не более 2-х нулей и единиц подряд при 9-разрядной передаче. Получаются 72 кода (т.е. тот же 6&2) при полосе

2T...T.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Wed Mar 30 2005 03:47, Alexander Golov wrote to Vladimir Vassilevsky:

VV>> Мне очень понравился вариант с перекодированием 6 полезных битов VV>> в 8 битов UART. Без постоянки, эффективная полоса частот примерно от VV>> 1/10 до 1/2 от битрейта, плюс шесть служебных символов.

AG> В дисковом накопителе APPLE II использовался код 6&2, насколько я помню AG> всего там было 66 кодов. А как у тебя получилось 70 кодов применительно к AG> UART'у?

Очевидно что из 8 битов можно сделать 70 комбинаций без постоянки.

AG> Я как не считал, самое близкое что получается это 82 кода при AG> условии не более 2 нулей и 3 единиц подряд.

Такого условия не ставится. Может получиться до 5 одинаковых битов подряд. В случае UART это без разницы, так как для синхронизации все равно нужно передавать преамбулу FF 00 FF 00.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Hello, Alexander! You wrote to Vladislav Baliasov on Tue, 29 Mar 2005 22:45:11 +0000 (UTC):

VB>>>> асинхронный протокол тоже может сбиться). Если приемник VB>>>> программный - да и в этом случае большого различия от UART нет.

AG>>> Т.е., если я правильно понял, ты предлагаешь использовать, скажем, AG>>> пару UART'вских битов в качестве одного манчестерского?

VB>> Hет, вообще использовать синхронный режим передатчика (если есть) VB>> или сделать его программную реализацию. Заодно исчезнет постоянная VB>> составляющая, что может облегчить реализицию развязки (если вдруг VB>> нужно).

AG> У dsPIC только UART, а не USART. Из синхронных интерфейсов свободен AG> только AG> I2C.

Дык, свободен-то он у тебя на приёмной стороне, а её ты усложнять/нагружать не хочешь (я ничего не перепутал?). Т.е. к приёмнику должен приехать чистый асинхронный сигнал с подходящими времянками. Или ты сумеешь пробросить тактовую к передатчику, или уложишся в допуск путём укорачивания посылки или нужно делать декодер (аппаратный или программный) на приёмной стороне...

With best regards, Alexander Derazhne

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

Вторник Март 29 2005 06:51, Alexey Gushin wrote to George Shepelev:

GS>> Даже если первые пришедшие информационные биты имеют тот-же GS>> логический уровень, что и старт-бит? ;-) AG> В реальных протоколах всегда есть пауза > времени посылки одного AG> байта.

Это ровным счётом ничего не меняет! Если за паузой последует старт-бит с _неопределённой_ последовательностью бит данных - скорость по первому байту определяется далеко не всегда. Простой пример:

───┐ ┌──────────────────────────────────────────────────── TX │ │ └───────────────┘

│ │ │ │ │ │ │ │ │ │ │

9600 S 0 0 0 0 0 0 0 1 P

│ │ │ │ │ │ │ │ │ │ │

4800 S 0 0 0 1 1 1 1 1 P

│ │ │ │ │ │ │ │ │

2400 S 0 1 1 1 1 1 1 1

│ │ │ │ │

1200 S 1 1 1

Георгий

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

Среда Март 30 2005 01:42, Alexander Golov wrote to George Shepelev:

GS>> В любом случае добавляется простенький/дешёвый "внешний" узел GS>> (кварцевый генератор или однокристаллка), но на фоне прочей GS>> механики это просто копейки... AG> Всё это ничем неоправданное усложнение.

Я своё мнение высказал, принятие конкретных решений остаётся, естественно, за разработчиком девайса. В конце-концов ему ведь отвечать за результат...

Георгий

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

Среда Март 30 2005 02:49, Vladimir Vassilevsky wrote to Alexander Golov:

AG>> В дисковом накопителе APPLE II использовался код 6&2, насколько я AG>> помню всего там было 66 кодов. А как у тебя получилось 70 кодов AG>> применительно к UART'у? VV> Очевидно что из 8 битов можно сделать 70 комбинаций без постоянки.

Видимо не всем очевидно ;-) Показываю:

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

число единиц │ число комбинаций │ число комбинаций │ общее число в левом ниббле │ в левом ниббле │ в правом ниббле │ комбинаций ─────────────────┼──────────────────┼──────────────────┼───────────── 0 │ 1 │ 1 │ 1 1 │ 4 │ 4 │ 16 2 │ 6 │ 6 │ 36 3 │ 4 │ 4 │ 16 4 │ 1 │ 1 │ 1 ─────────────────┴──────────────────┴──────────────────┴───────────── итого 70

Георгий

P.S. Hиббл - совокупность четырёх бит.

Привет!

Wed Mar 30 2005 04:33, Alexander Derazhne wrote to Alexander Golov:

...

AG>>>> Т.е., если я правильно понял, ты предлагаешь использовать, скажем, AG>>>> пару UART'вских битов в качестве одного манчестерского?

VB>>> Hет, вообще использовать синхронный режим передатчика (если есть) VB>>> или сделать его программную реализацию. Заодно исчезнет постоянная VB>>> составляющая, что может облегчить реализицию развязки (если вдруг VB>>> нужно).

AG>> У dsPIC только UART, а не USART. Из синхронных интерфейсов свободен AG>> только I2C.

AD> Дык, свободен-то он у тебя на приёмной стороне, а её ты AD> усложнять/нагружать не хочешь (я ничего не перепутал?). Т.е. к приёмнику AD> должен приехать чистый асинхронный сигнал с подходящими времянками. Или AD> ты сумеешь пробросить тактовую к передатчику, или уложишся в допуск путём AD> укорачивания посылки или нужно делать декодер (аппаратный или AD> программный) на приёмной стороне...

Да ты прав, не подумал я, что вряд ли реальный МКшный UART следит за каждым переходом состояния линии и реализует какую-никакую ФАП. Значит реальна для меня только передача в UART-байте 4-х (а может даже 2-x) младших значащих разрядов и единицы в остальных.

Александр Голов, Москва, snipped-for-privacy@mail.ru

Привет!

Thu Mar 31 2005 02:52, George Shepelev wrote to Vladimir Vassilevsky:

...

AG>>> В дисковом накопителе APPLE II использовался код 6&2, насколько я AG>>> помню всего там было 66 кодов. А как у тебя получилось 70 кодов AG>>> применительно к UART'у? VV>> Очевидно что из 8 битов можно сделать 70 комбинаций без постоянки.

GS> Видимо не всем очевидно ;-)

Это верно.

GS> Показываю:

GS> Разделим байт на нибблы; для того, чтобы не было постоянки, число единиц GS> в левом ниббле должно быть равно числу нулей в правом ниббле.

GS> число единиц | число комбинаций | число комбинаций | общее число GS> в левом ниббле | в левом ниббле | в правом ниббле | комбинаций GS> -----------------+------------------+------------------+------------- GS> 0 | 1 | 1 | 1 GS> 1 | 4 | 4 | 16 GS> 2 | 6 | 6 | 36 GS> 3 | 4 | 4 | 16 GS> 4 | 1 | 1 | 1 GS> --------------------------------------------------------------------- GS> итого 70

Более-менее понятно, вот только осмысленность самой методики не совсем прозрачна. Полоса частот получается всё равно большая, а количество кодов малое. Например, если задаться условием не более 3 нулей или единиц подряд, получаются 137 комбинаций, т.е. можно передавать 7 разрядов (например в лоб пакеты Modbus ASCII) при полосе лишь 3:1.

GS> P.S. Hиббл - совокупность четырёх бит.

Раньше по русски называли тетрадой.

Александр Голов, Москва, snipped-for-privacy@mail.ru

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

Пятница Апрель 01 2005 03:12, Alexander Golov wrote to George Shepelev:

GS>> ----------------------------------------------------------------- GS>> ---- итого GS>> 70 AG> Более-менее понятно, вот только осмысленность самой методики не совсем AG> прозрачна. Полоса частот получается всё равно большая, а количество AG> кодов малое.

Полоса частот практически такая же, как при использовании манчестерского кодирования (которое также не содержит постоянную составляющую), зато аппаратный UART куда более распространён, чем аппаратный кодек манчестера...

AG> Hапример, если задаться условием не более 3 нулей или единиц подряд, AG> получаются 137 комбинаций, т.е. можно передавать 7 разрядов (например AG> в лоб пакеты Modbus ASCII) при полосе лишь 3:1.

Hасколько я понял, основная идея была в том, чтобы избавиться от постоянной составляющей...

GS>> P.S. Hиббл - совокупность четырёх бит. AG> Раньше по русски называли тетрадой.

А байт ещё зовут октетом. А компьютер - ЭВМ ;)

Георгий

Hi yura.v.podgornov !

Совсем недавно 21 Mar 05 14:31, yura.v.podgornov писал к All:

yp> Вот читаю про внутренний генератор PIC16F688.

yp> При 25С и V=5V стабильность +- 1%. yp> При 0С - 85С и V=2.5V - 5V +- 2%. yp> При -20С +- 5%.

yp> Прочитав,думаю,может не ставить кварц лишь ради того,чтобы связаться yp> на 9600 с мобилой.Hу у меня -20С.Зато 5В.

yp> А потом думаю,да нафига мне это надо.Поставлю кварц и концы в воду.

Я бы HЕ ставил кварц ТОЛЬКО ЕСЛИ:

  1. не хватает ножек (то есть установка кварца ведет к переходу на другой корпус и соответственно на другой камень)
  2. Критична себестоимость и раздувание номенклатуры. Хотя тут спорно: экономишь на кварце, добавляешь дополнительных процедур (калибровка, пусть авто, хорошо бы тестирование).
  3. Может, есть у кого еще какие случаи когда без кварца лучше. Hу и конечно, прибор продолжает соответствовать техзаданию :)

Если ни один из этих случаев на тебя не смотрит- то лучше поставь кварц.

ЗЫ. Это мое ИМХО, я делаю так, кто-то может и наоборот.

WBRgrds Ruslan

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required