aaarrr 69 24 августа, 2009 Опубликовано 24 августа, 2009 · Жалоба Кстати сказать, для одних скоростей ширина единицы превалирует над шириной нуля, а для других скоростей наоборот. Поясните, пожалуйста, как это может быть связано с преобразователем уровней. Никак, естественно. Так сразу бы написали, а то "на скоростях близких к максимальной" - что тут можно еще подумать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 24 августа, 2009 Опубликовано 24 августа, 2009 (изменено) · Жалоба Понятно. Просто этот эффект уменьшается со скоростью, поэтому так написал. Видимо, это связано с делением/умножением частоты. Изменено 24 августа, 2009 пользователем x736C Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 11 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба Обязательно найду и приложу документ, в котором я вычитал про ФАПЧ в контроллере RS-232. Я помню тоже удивлялся. Там приводилась аналогия с радиоприемником. Возможно, данная схема называется немного по другому, но я точно помню про Автоматическую Подстройку Частоты... Единственное объяснение, какое приходит в голову: в какой-то микросхеме могла быть использована ФАПЧ для умножения тактовой частоты. В самом же UART-e никаких ФАПЧ не используется, он тактируется от фиксированной частоты. Чаще всего приемный тракт UART тактируют от частоты в 16 раз большей, чем бодовая. По приходу падающего фронта старт-бита отсчитывают 8 тиков, чтобы попасть в середину тактового интервала. После этого через каждые 16 тиков берут самплы в середине каждого бита. В простейшем случае берут 1 сампл. Если тактовые частоты приемника и передатчика не совпадают, то сампл постепенно "съезжает" из центра, однако за время передачи байта "съезжает" не так уж далеко, чтобы прием был с ошибками. Достаточно, чтобы частоты не сопадали не более чем примерно на 2%, чтобы гарантировать уверенный прием. К ФАПЧ все это не имеет ни малейшего отношения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба Писал в прошлом году autobaud rate на hdl и обнаружил следующее. Как оказалось, переходники usb-com на современных чипах имеют очень неравное соотношение положительного БИ к отрицательному. На скоростях близких к максимальной (115200) коэф. заполнения двухбитового интервала «10» отклонялся на 10% от нормы. Проверял на конвертерах двух разных производителей. Это не сильно принципиально для фиксированных скоростей. Другое дело для автоматической подстройки, которая должна это учитывать. Они выполняются как правило на счетчике. С ФАПЧ в классическом смысле что-то не встречал, хотя активно тогда гуглил. Скорее всего у вас что-то было с МК или с программой. Имею в виду программно-аппаратную неисправность , а не изначальную кривость USART. Что-то совсем не понял. Я например, делал autobaud модема и совсем не заметил разницы м/у 1 и 0. Более того, имея представление о цифровой реализации схемы не могу поверить в такое. Конвертер - это врят ли фиксированная аппаратная фича. Не те времена. Это встроенный мк который имеет 2 интерфейса. Соответственно UART реализован стандартно. Так откуда взятся такой разнице??? Если брать CP, то там сразу виден МК, который применён. В FTDI не так очевидно, но косвенно тоже понятно. Могу только предположить что у вас что-то с преобразователями уровня не то. Хотя это только догадка. По поводу эха. А что команда "ate0" уже перестала работать? Или список команд модема почитать религия запрещает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба Писал в прошлом году autobaud rate на hdl и обнаружил следующее. Как оказалось, переходники usb-com на современных чипах имеют очень неравное соотношение положительного БИ к отрицательному... Это не сильно принципиально для фиксированных скоростей. Другое дело для автоматической подстройки, которая должна это учитывать. По своему опыту реализации autobaud rate, пришел к выводу, что измерять длительность передачи одиночных битов - не самое лучшее решение. Сейчас измеряю время от начала старт-бита до начала стоп-бит и делю на количество бит. Получается много лучше, точнее. И описанные выше проблемы (даже если они есть) уже не критичны. Естественно, нужно знать, что передается, чтобы пропустить "лишние" фронты. Пока эта методика не подводила... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 25 августа, 2009 Опубликовано 25 августа, 2009 (изменено) · Жалоба Немного отклонились от темы, но все-таки. Если не заметили разницы, значит, скорее всего у вас ее и не было. UART интерфейсы по-разному паршивы. У меня есть табличка со снятыми значениями для Huge Pine конвертера. Разве что осциллограммы не делал. Но и это не долго, если надо. :) Если что-то с преобразователем уровня, то в конвертере. Микросхема бескорпусная, так что бог ее знает. На конвертерах подороже в той или иной степени тоже это проявляется. Смотрел еще конвертер ST-Lab. @Ark, как вы достоверно определяете стоп-бит? И что значит «знать, что передается»? На произвольных данных, в том числе непрерывном потоке, ваша реализация не ошибется? Изменено 25 августа, 2009 пользователем x736C Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба Ну, конечно, не на произвольном и непрерывном потоке. :) Этот способ хорошо работает для обмена, построенного по принципу "запрос-ответ", с паузами ожидания. Предполагается, что формат и заголовок запроса известны устройству, неизвестна только текущая скорость... Ждем паузы (прекращения текущей передачи), далее ожидаем начала следующего запроса. Достаточно знать только первый передаваемый байт. Он выбирается так, чтобы последний бит был нулевой - чтобы обнаружить начало стоп-бита. Ну, а дальше - дело техники программирования... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба Тогда ясно. В моем случае это не подходило. В вашем случае, когда заголовок посылки известен, можно измерить и первый стартовый бит, заранее зафиксировав в протоколе ограничение следующей за ним единицей. Смещения (1/0) можно учесть доверительным интервалом. Значения БИ для разных скоростей при неблагоприятных смещениях не перекрываются. И это самое главное. Так что не суть, как измерять. Поправьте, если неправ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба Все немного проще. По первому фронту (начало старт-бита) снимаете показания таймера, затем пропускаете известное количество фронтов, и по фронту начала стоп-бита снимаете второе значение таймера. Разница значений таймера - это суммарная длительность 9-ти бит (для 8-ми битного формата). Смысл в том, что измерив интервал из 9 бит подряд, получите в 9 раз меньшую ошибку длительности одного бита. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба ...затем пропускаете известное количество фронтов Отличный "алгоритм" :( откуда это вдруг количество фронтов на произвольном байте статет "известным". А если байт известный, то проблема выеденного яйца не стоит и городить ловлю фронтов и прочее лишнее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба ... откуда это вдруг количество фронтов на произвольном байте статет "известным". А Вы внимательно читать не пробовали? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба А Вы внимательно читать не пробовали? :) Пробовал, пробовал.... сначала пауза гарантированная, потом байт гарантированный, потом бит в байте гарантированный... Повторяю "отличый" алгоритм :(. Непонятно, отчего это только вдруг скорость не принять тоже известной :). Ну его в болото. P.S. Модемы 100 лет в субботу, как по известным "AT" скорость детектят, причем молча. Аппаратная подержка автодетекта в микроконтроллерных UART тоже уже часто имеет место быть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба По своему опыту реализации autobaud rate, пришел к выводу, что измерять длительность передачи одиночных битов - не самое лучшее решение. Сейчас измеряю время от начала старт-бита до начала стоп-бит и делю на количество бит. Получается много лучше, точнее. И описанные выше проблемы (даже если они есть) уже не критичны. Естественно, нужно знать, что передается, чтобы пропустить "лишние" фронты. Пока эта методика не подводила... А кто вам сказал, что я проверяю единичные биты? У меня проверяются биты и разница битов и прогнозируется длительность байта. Восстанавливается инфа включая первый байт с вероятностью 98%. Хотя этого и не требуется так как это в модеме стоит и первый байт чаще всего a. Тем не менее восстанавливается всё подряд, кроме символов восстановить которые нельзя. Всё это восстанавливается прямо в потоке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 25 августа, 2009 Опубликовано 25 августа, 2009 · Жалоба ... Непонятно, отчего это только вдруг скорость не принять тоже известной. Аппаратная подержка автодетекта в микроконтроллерных UART тоже уже часто имеет место быть. Да-да, конечно. :) Все просто и не интересно, когда тактовый генератор от кварца. Тогда можно и перебором нужную скорость найти... Какие проблемы... P.S. Попробуйте на некалиброванном RC-генераторе UART реализовать, в целях экономии... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 25 августа, 2009 Опубликовано 25 августа, 2009 (изменено) · Жалоба SasaVitebsk, человек вообще-то мне оппонировал. :) «Восстанавливается инфа включая первый байт с вероятностью 98%». Странно, что вы указываете вероятность успешного приема первого байта, хотя не известна вероятность получения конкретных байт. Вероятность успешного приема первого байта, имхо, сильно зависит от того, какой это будет байт. Поэтому откуда взята цифра 98% ? :) Вероятность появления неблагоприятного байта при «случайном» обмене, конечно, можно посчитать, но не думаю, что вы это делали. @Ark этот вопрос решил просто, сделал её единицей (около того), пожертвовав первым байтом. И потом, по моему мнению, вы сильно усложнили. Проверять одно, второе, прогнозировать третье. В погоне за этим первым байтом что ли? Изменено 25 августа, 2009 пользователем x736C Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
