Никак, естественно. Так сразу бы написали, а то "на скоростях близких к максимальной" - что тут можно еще подумать?

Понятно. Просто этот эффект уменьшается со скоростью, поэтому так написал.
Видимо, это связано с делением/умножением частоты.

Сообщение отредактировал x736C - Aug 24 2009, 23:09

Единственное объяснение, какое приходит в голову: в какой-то микросхеме могла быть использована ФАПЧ для умножения тактовой частоты. В самом же UART-e никаких ФАПЧ не используется, он тактируется от фиксированной частоты.

Чаще всего приемный тракт UART тактируют от частоты в 16 раз большей, чем бодовая. По приходу падающего фронта старт-бита отсчитывают 8 тиков, чтобы попасть в середину тактового интервала. После этого через каждые 16 тиков берут самплы в середине каждого бита. В простейшем случае берут 1 сампл. Если тактовые частоты приемника и передатчика не совпадают, то сампл постепенно "съезжает" из центра, однако за время передачи байта "съезжает" не так уж далеко, чтобы прием был с ошибками. Достаточно, чтобы частоты не сопадали не более чем примерно на 2%, чтобы гарантировать уверенный прием. К ФАПЧ все это не имеет ни малейшего отношения.

Что-то совсем не понял. Я например, делал autobaud модема и совсем не заметил разницы м/у 1 и 0. Более того, имея представление о цифровой реализации схемы не могу поверить в такое. Конвертер - это врят ли фиксированная аппаратная фича. Не те времена. Это встроенный мк который имеет 2 интерфейса. Соответственно UART реализован стандартно. Так откуда взятся такой разнице??? Если брать CP, то там сразу виден МК, который применён. В FTDI не так очевидно, но косвенно тоже понятно. Могу только предположить что у вас что-то с преобразователями уровня не то. Хотя это только догадка.

По поводу эха. А что команда "ate0" уже перестала работать? Или список команд модема почитать религия запрещает?

По своему опыту реализации autobaud rate, пришел к выводу, что измерять длительность передачи одиночных битов - не самое лучшее решение. Сейчас измеряю время от начала старт-бита до начала стоп-бит и делю на количество бит. Получается много лучше, точнее. И описанные выше проблемы (даже если они есть) уже не критичны. Естественно, нужно знать, что передается, чтобы пропустить "лишние" фронты. Пока эта методика не подводила...

Немного отклонились от темы, но все-таки.
Если не заметили разницы, значит, скорее всего у вас ее и не было. UART интерфейсы по-разному паршивы.
У меня есть табличка со снятыми значениями для Huge Pine конвертера. Разве что осциллограммы не делал. Но и это не долго, если надо.

Если что-то с преобразователем уровня, то в конвертере.
Микросхема бескорпусная, так что бог ее знает.
На конвертерах подороже в той или иной степени тоже это проявляется. Смотрел еще конвертер ST-Lab.


@Ark, как вы достоверно определяете стоп-бит? И что значит «знать, что передается»?
На произвольных данных, в том числе непрерывном потоке, ваша реализация не ошибется?

Сообщение отредактировал x736C - Aug 25 2009, 11:34

Ну, конечно, не на произвольном и непрерывном потоке.
Этот способ хорошо работает для обмена, построенного по принципу "запрос-ответ", с паузами ожидания.
Предполагается, что формат и заголовок запроса известны устройству, неизвестна только текущая скорость...
Ждем паузы (прекращения текущей передачи), далее ожидаем начала следующего запроса. Достаточно знать только первый передаваемый байт. Он выбирается так, чтобы последний бит был нулевой - чтобы обнаружить начало стоп-бита. Ну, а дальше - дело техники программирования...

Тогда ясно. В моем случае это не подходило.
В вашем случае, когда заголовок посылки известен, можно измерить и первый стартовый бит, заранее зафиксировав в протоколе ограничение следующей за ним единицей.
Смещения (1/0) можно учесть доверительным интервалом. Значения БИ для разных скоростей при неблагоприятных смещениях не перекрываются. И это самое главное. Так что не суть, как измерять.
Поправьте, если неправ.

Все немного проще. По первому фронту (начало старт-бита) снимаете показания таймера, затем пропускаете известное количество фронтов, и по фронту начала стоп-бита снимаете второе значение таймера. Разница значений таймера - это суммарная длительность 9-ти бит (для 8-ми битного формата). Смысл в том, что измерив интервал из 9 бит подряд, получите в 9 раз меньшую ошибку длительности одного бита.

Отличный "алгоритм" откуда это вдруг количество фронтов на произвольном байте статет "известным". А если байт известный, то проблема выеденного яйца не стоит и городить ловлю фронтов и прочее лишнее.

А Вы внимательно читать не пробовали?

Пробовал, пробовал.... сначала пауза гарантированная, потом байт гарантированный, потом бит в байте гарантированный... Повторяю "отличый" алгоритм . Непонятно, отчего это только вдруг скорость не принять тоже известной . Ну его в болото.
P.S.
Модемы 100 лет в субботу, как по известным "AT" скорость детектят, причем молча. Аппаратная подержка автодетекта в микроконтроллерных UART тоже уже часто имеет место быть.

А кто вам сказал, что я проверяю единичные биты?

У меня проверяются биты и разница битов и прогнозируется длительность байта. Восстанавливается инфа включая первый байт с вероятностью 98%. Хотя этого и не требуется так как это в модеме стоит и первый байт чаще всего a. Тем не менее восстанавливается всё подряд, кроме символов восстановить которые нельзя. Всё это восстанавливается прямо в потоке.

Да-да, конечно. Все просто и не интересно, когда тактовый генератор от кварца. Тогда можно и перебором нужную скорость найти... Какие проблемы...
P.S. Попробуйте на некалиброванном RC-генераторе UART реализовать, в целях экономии...

SasaVitebsk, человек вообще-то мне оппонировал.

«Восстанавливается инфа включая первый байт с вероятностью 98%».
Странно, что вы указываете вероятность успешного приема первого байта, хотя не известна вероятность получения конкретных байт.
Вероятность успешного приема первого байта, имхо, сильно зависит от того, какой это будет байт. Поэтому откуда взята цифра 98% ?
Вероятность появления неблагоприятного байта при «случайном» обмене, конечно, можно посчитать, но не думаю, что вы это делали.
@Ark этот вопрос решил просто, сделал её единицей (около того), пожертвовав первым байтом.

И потом, по моему мнению, вы сильно усложнили. Проверять одно, второе, прогнозировать третье. В погоне за этим первым байтом что ли?

Сообщение отредактировал x736C - Aug 25 2009, 13:57