падает скорость на rs232 Опции

[borischi]

здравствуйте!
Такая проблема-использую АТ89S52 для чтения информации с мобильника (эрик т28).На коротких посылках всё нормально а свыше 13-15 байт-не успеваю вычитывать похоже.Допустим посылка из 30 байт-меня в ней интересует 25-й для проверки и я в него не попадаю.Если чуть опережаю события(на один вызов getch меньше)-удается попасть в нужный байт-но это ж не дело.
В терминальной программе эрик выдает всё как надо.Уровни его на интерфейсе до 5 вольт подтянул.
Может кто сталкивался с подобным-буду очень благодарен за совет

[Dog Pawlowa]

Может кто сталкивался с подобным-буду очень благодарен за совет

С поиском телепатов - конечно
Приведите Ваш исходник, или часть его, или хоть что-то, за что можно зацепиться.

[AHTOXA]

Кварц какой? Может скорость не совсем точно совпадает?
Ну и, если обработка символов занимает какое-то время, можно использовать буферизованный приём по прерываниям.

[manul78]

Была у одного знакомого такая-же проблема.
Компьютер читал через СОМ порт промышленный контроллер Дельта Электроникс как часы, а вот МК
посредством USART - ну никак ! И кварцев кучу перепробовали, и скорости меняли, короче "танцы
с бубнами" были конкретные... А все потому, что USART у МК не имеет в отличие от компьютерной
микросхемы ФАПЧ (фазовую автоподстройку частоты) !

Победили написав программный USART через прерывания... Аппаратный отправили "фтоппку"...

[zltigo]

А все потому, что USART у МК не имеет в отличие от компьютерной
микросхемы ФАПЧ (фазовую автоподстройку частоты) !

Вы бредите.

[manul78]

Вы бредите.

Обоснуйте ? В каком месте ?

[borischi]

Кварц какой? Может скорость не совсем точно совпадает?
Ну и, если обработка символов занимает какое-то время, можно использовать буферизованный приём по прерываниям.

Кварц 11.059
Настроил передатчик на стандартный 2-й режим 10 бит(старт,стоп и 8 бит дата).Скорость 9600 с соотв.перезагрузкой таймера.Никакой обработки символов нет-тупо вычитываю по готовности.проверяю на наличие определенного символа и всё.Там только и есть,что CJNE

[manul78]

Кварц 11.059
Настроил передатчик на стандартный 2-й режим 10 бит(старт,стоп и 8 бит дата).Скорость 9600 с соотв.перезагрузкой таймера.Никакой обработки символов нет-тупо вычитываю по готовности.проверяю на наличие определенного символа и всё.Там только и есть,что CJNE

А как организован RS232 в телефоне ? Есть схема ?
Возможно у компьютера высокое входное сопротивление и соответственно в "терминалке" все работает
гуд. А вот в МК может быть более низкоомная входная цепь, которая в процессе работы медленно
подсаживает RS232 схему телефона и она начинает пороть чушь... Это мои догадки...

С телефона идет "чиcтый RS-232" ? Уровни +10, -10 ?

Сообщение отредактировал manul78 - Aug 23 2009, 15:52

[borischi]

А как организован RS232 в телефоне ? Есть схема ?
Возможно у компьютера высокое входное сопротивление и соответственно в "терминалке" все работает
гуд. А вот в МК может быть более низкоомная входная цепь, которая в процессе работы медленно
подсаживает RS232 схему телефона и она начинает пороть чушь... Это мои догадки...

Ну поставил я последовательно резисторы на Rx и Tx.По 100 ом.А как организовано входное сопротивление каналов rs232 контроллера-честно говоря не знаю.Пробовал вписывать 1 в Rx контроллера конечно-не помогло

С телефона идет "чиcтый RS-232" ? Уровни +10, -10 ?

Нет конечно TTL 0 +- 2.5 V

[manul78]

Нет конечно TTL 0 +- 2.5 V

Осциллограф цифровой возможно пролил-бы свет на данную проблему...

Попробуйте буферную микросхему чтобы привести уровни в приемлемый вид...

Последняя догадка, возможно телефон передает не поток, а пакеты (15 байт данных + 16-тый CRC) ?

[borischi]

Осциллограф цифровой возможно пролил-бы свет на данную проблему...

Попробуйте буферную микросхему чтобы привести уровни в приемлемый вид...

Последняя догадка, возможно телефон передает не поток, а пакеты (15 байт данных + 16-тый CRC) ?

Осциллографа пока нету,-но жду его с нетерпением
Bus tranceiver ставил-не помогло.
А вот насчет пакета поподробнее если можно

[AHTOXA]

Кварц 11.059

Это гуд.

Настроил передатчик на стандартный 2-й режим 10 бит(старт,стоп и 8 бит дата).Скорость 9600 с соотв.перезагрузкой таймера.Никакой обработки символов нет-тупо вычитываю по готовности.проверяю на наличие определенного символа и всё.Там только и есть,что CJNE

Какого таймера? Какое значение перезагружается? Может, приведёте кусочки кода с инициализацией и обработкой?

Нет конечно TTL 0 +- 2.5 V

При пятивольтовом контроллере? Я б поставил хоть транзистор для порядка

[manul78]

А вот насчет пакета поподробнее если можно

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

Формат пакета: первый байт - количество передаваемых байт данных.
следующие байты - собственно данные.
последний байт - контрольная сумма. (CRC)

Передаем 100 байт пакетами по 15 :

Первый пакет: 15, х,х....х,х, CRC - Получив его приемник быстро обрабатывает результат и
отвечает передатчику что все гут либо просит повторить
первый пакет...
Второй пакет: 15,х,х.....х,х, CRC ................................................................................
.....................

................................................................................
................................................................................
.

Седьмой пакет: 10,х,х.....х,х,CRC - Последний пакет.

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

[borischi]

При пятивольтовом контроллере? Я б поставил хоть транзистор для порядка

Уровни на приеме от эрика я подтянул к 5 вольтам-поставил 2 инвертора на транзисторах.

Причина редактирования: Урезание цитаты.

[Сергей Борщ]

Обоснуйте ? В каком месте ?

Если совсем откровенно - во всех. Для начала: "компьютерная микросхема" - 16550 и ее более продвинутые версии. Найдите в ее даташите хотя бы упоминание о ФАПЧ.

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

Телефоны используют протокол, унаследованный от модемов Hayes. Обычный текст, текстовые же команды, начинающиеся с AT. Отсюда название - AT-команды. Никаких CRC.
borischi: лучше покажите код. Телепатией заниматься просто лень. Последняя попытка телепатии: У вас в системе используются прерывания? Если да, то нет ли где-то в прерываниях больших участков кода, время исполнения которых больше времени приема символа?

Уровни на приеме от эрика я подтянул к 5 вольтам-поставил 2 инвертора на транзисторах.

А инверторы там как раз и не нужны. Если у вас нет ничего, кроме инверторов - поставьте их два последовательно. И инверторы лучше взять интегральные. Что-то вроде 74HCT14.

[AHTOXA]

Пожалуйста.Тем более что он не мой. Почти целиком взят тут http://www.gsmpager.spb.ru/soft/a.a51

Не грузится...

Если у вас нет ничего, кроме инверторов - поставьте их два последовательно.

Насколько я понял, он так и сделал.

[borischi]

А инверторы там как раз и не нужны. Если у вас нет ничего, кроме инверторов - поставьте их два последовательно. И инверторы лучше взять интегральные. Что-то вроде 74HCT14.

И то верно-лучше один раз увидеть.Так это подключено
А это код,если не грузится

Прикрепленные файлы

 rxtx.bmp ( 328.58 килобайт ) Кол-во скачиваний: 15
 kod.txt ( 7.6 килобайт ) Кол-во скачиваний: 56

 

[AHTOXA]

А, загрузилось. Мне кажется, я знаю в чём дело.
Там сначала вызывается PUTSTR, а потом несколько раз GETCH, чтобы пропустить эхо. Но дело в том, что телефон выдаёт эхо сразу. Вот оттого и не работает ничего.

Тут два выхода. Либо писать буферизованный приём, как я советовал выше. Либо переделать PUTSTR так, чтобы она при передаче символа сразу ждала эхо этого символа.

[borischi]

Там сначала вызывается PUTSTR, а потом несколько раз GETCH, чтобы пропустить эхо. Но дело в том, что телефон выдаёт эхо сразу. Вот оттого и не работает ничего.

Не понял...Телефон сразу выдает эхо с первой буквы комманды? Не дождавшись её конца?
Кстати код рабочий.Так во всяком случае ребята утверждают

[AHTOXA]

Не понял...Телефон сразу выдает эхо с первой буквы комманды? Не дождавшись её конца?

Естественно. Попробуйте в терминалке понабирать команды.

Кстати код рабочий.Так во всяком случае ребята утверждают

Может быть, что скорость 19200 (более быстрая отправка), + некоторая задержка при отправке эха тем телефоном, для которого это писалось, позволяют этому коду как-то работать. Но я лично сомневаюсь.

[borischi]

Естественно. Попробуйте в терминалке понабирать команды.

Вы совершенно правы.Вижу это в терминалке.Как раньше не пришло в голову проверить..... Отскакивает эхо не дожидаясь кода CR
Щас перепишу код.Большое спасибо

[AHTOXA]

Щас перепишу код.Большое спасибо

Да не за что
Обратите внимание, что на CR может приходить эхо CR+LF. Проверьте это в своём телефоне.

[borischi]

Да не за что
Обратите внимание, что на CR может приходить эхо CR+LF. Проверьте это в своём телефоне.

Точно .Есть такое дело
Еще раз спасибо

[manul78]

Если совсем откровенно - во всех. Для начала: "компьютерная микросхема" - 16550 и ее более продвинутые версии. Найдите в ее даташите хотя бы упоминание о ФАПЧ.

Обязательно найду и приложу документ, в котором я вычитал про ФАПЧ в контроллере RS-232. Я помню
тоже удивлялся. Там приводилась аналогия с радиоприемником. Возможно, данная схема называется
немного по другому, но я точно помню про Автоматическую Подстройку Частоты...

[rezident]

Обязательно найду и приложу документ, в котором я вычитал про ФАПЧ в контроллере RS-232.

К вашему сведению, "контроллеров RS-232" нету. Есть стандартный интерфейс RS-232 (стандарт TIA/EIA-232-F) и существуют контроллеры, поддерживающие (стандартный) интерфейс RS-232. Сам стандарт, кстати, имеется на местном ФТП. Там вообще ни про UART, ни про ФАПЧ нет ни слова.

Там приводилась аналогия с радиоприемником. Возможно, данная схема называется
немного по другому, но я точно помню про Автоматическую Подстройку Частоты...

Вот только не нужно приводить журнальных статей, в которых какой-нибудь ламернахватавшийся верхушек пользователь пишет про "контроллер RS-232" и про ФАПЧ в этом "контроллере RS-232" Не стоит смешить местных профессионалов. Точно также как и не стоит упорствовать в своих заблуждениях

[aaarrr]

Обязательно найду и приложу документ, в котором я вычитал про ФАПЧ в контроллере RS-232. Я помню
тоже удивлялся. Там приводилась аналогия с радиоприемником. Возможно, данная схема называется
немного по другому, но я точно помню про Автоматическую Подстройку Частоты...

Может, с autobaud'ом перепутали, а?

[manul78]

Получив "по башке" сразу от двух модераторов ZLtigo и Rezident я конечно...

"Не буду смешить местных профессионалов. Точно также как и не буду упорствовать в своих заблуждениях "

Понятно, что интерфейс RS-232 (стандарт TIA/EIA-232-F) это одно, а например USART 82C51 контроллер
это разные вещи... Панцырь черепахи - это её скелет, как не парадоксально...

Но,... "не буду упорствовать в своих заблуждениях "...

А про автоматическую подстройку частоты в USART (UART) конкретных чипах постараюсь найти и предоставить, не приснилось-же мне это ? Я не Менделеев...

[x736C]

Была у одного знакомого такая-же проблема.

Писал в прошлом году autobaud rate на hdl и обнаружил следующее.
Как оказалось, переходники usb-com на современных чипах имеют очень неравное соотношение положительного БИ к отрицательному.
На скоростях близких к максимальной (115200) коэф. заполнения двухбитового интервала «10» отклонялся на 10% от нормы.
Проверял на конвертерах двух разных производителей.
Это не сильно принципиально для фиксированных скоростей.
Другое дело для автоматической подстройки, которая должна это учитывать.

Они выполняются как правило на счетчике. С ФАПЧ в классическом смысле что-то не встречал, хотя активно тогда гуглил.
Скорее всего у вас что-то было с МК или с программой.
Имею в виду программно-аппаратную неисправность , а не изначальную кривость USART.

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

[aaarrr]

Как оказалось, переходники usb-com на современных чипах имеют очень неравное соотношение положительного БИ к отрицательному.
На скоростях близких к максимальной (115200) коэф. заполнения двухбитового интервала «10» отклонялся на 10% от нормы.

На встроенных в материнки портах они порой отклоняются еще сильнее, но это вина преобразователей уровней. На USB-COM то же самое наблюдается, скорее всего.

[x736C]

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

[aaarrr]

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

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

[x736C]

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

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

[=AK=]

Обязательно найду и приложу документ, в котором я вычитал про ФАПЧ в контроллере RS-232. Я помню
тоже удивлялся. Там приводилась аналогия с радиоприемником. Возможно, данная схема называется
немного по другому, но я точно помню про Автоматическую Подстройку Частоты...

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

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

[SasaVitebsk]

Писал в прошлом году autobaud rate на hdl и обнаружил следующее.
Как оказалось, переходники usb-com на современных чипах имеют очень неравное соотношение положительного БИ к отрицательному.
На скоростях близких к максимальной (115200) коэф. заполнения двухбитового интервала «10» отклонялся на 10% от нормы.
Проверял на конвертерах двух разных производителей.
Это не сильно принципиально для фиксированных скоростей.
Другое дело для автоматической подстройки, которая должна это учитывать.

Они выполняются как правило на счетчике. С ФАПЧ в классическом смысле что-то не встречал, хотя активно тогда гуглил.
Скорее всего у вас что-то было с МК или с программой.
Имею в виду программно-аппаратную неисправность , а не изначальную кривость USART.

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

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

[Guest_@Ark_*]

Писал в прошлом году autobaud rate на hdl и обнаружил следующее.
Как оказалось, переходники usb-com на современных чипах имеют очень неравное соотношение положительного БИ к отрицательному... Это не сильно принципиально для фиксированных скоростей.
Другое дело для автоматической подстройки, которая должна это учитывать.

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

[x736C]

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

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


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

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

[Guest_@Ark_*]

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

[x736C]

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

[Guest_@Ark_*]

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

[zltigo]

...затем пропускаете известное количество фронтов

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

[Guest_@Ark_*]

... откуда это вдруг количество фронтов на произвольном байте статет "известным".

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

[zltigo]

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

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

[SasaVitebsk]

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

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

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

[Guest_@Ark_*]

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

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

[x736C]

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

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

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

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

[zltigo]

P.S. Попробуйте на некалиброванном RC-генераторе UART реализовать, в целях экономии...

Не валите в кучу две разных задачи. Подстройка под RC генератор может вообще осуществляться периодически по длительности специально передаваемого Break и соответственно совершенно не быть завязаным на какие-либо протокольные вещи.

[x736C]

Не валите в кучу две разных задачи. Подстройка под RC генератор может вообще осуществляться периодически по длительности специально передаваемого Break и соответственно совершенно не быть завязаным на какие-либо протокольные вещи.

А может быть осуществлена гораздо проще, в рамках процедуры обмена, как и было сделано.

P. S. Попытка с менторским тоном придумать эту разницу уважения к вашему профессионализму, в котором лично у меня не возникает никаких сомнений, не добавляет.

[zltigo]

А может быть осуществлена гораздо проще, в рамках процедуры обмена, как и было сделано.

При этом налагая ДОПОЛНИТЕЛЬНЫЕ НЕНУЖНЫЕ ограничения на эту самую процедуру, вместо того, что-бы процедура только выбрасывала битые фреймы в ней начинают наворачивать поиск пауз, подсчет фронтов в байте следущим после паузы, протокольные ограничения....

Попытка с менторским тоном придумать эту разницу...

Эта разница, простите, совершенно не придумана , она объективно есть. Любую задачу можно решить максимально извращенным способом - тут спору нет, но лучше проще. Предки, например, заложили тот-же Break совсем не зря.

[rezident]

Может, с autobaud'ом перепутали, а?

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

[x736C]

Вы тоже налагаете ограничение в виде постоянной посылки break. Шило на мыло.
Замена одного априорно известного байта, на другой «байт», который надо:
1. отделить от других данный (в том числе на стороне передатчика);
2. измерить тем же счетчиком.
Ну и третье. Так как скорость передачи неизвестна, то как этот break не спутать с нулевым БИ или их комбинацией, следующей на пониженной скорости, мне не ясно.
Опять-таки, в кучу свалено две задачи, калибровка и автоподстройка.

Калибровка RC-генератора при известной скорости передачи не представляется настолько простецкой, чтобы в данном контексте ей пренебрегать.
http://www.atmel.com/dyn/resources/prod_do...nts/doc2563.pdf

Добавить сюда еще autobaud rate — вообще сомнительное предприятие для случая @Ark.

Добавлю: что в предложенном appNote от Atmel к сигналу break добавлен еще байт синхронизации. Разве ж это проще.

Так что где изврат — это еще вопрос.
С уважением.

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

[zltigo]

Вы тоже налагаете ограничение в виде постоянной посылки break. Шило на мыло.

Это НЕ ограничение на протокол - протокол совершенно ничего не знает о калибровках. Совсем ничего.

1. отделить от других данный (в том числе на стороне передатчика);

Это вообще-то не байт совсем. Это с точки зрения приемника битый фрейм, который отделяется, даже если у чипа нет поддержки детектирования break по ошибке фрейма
и выбрасывается.

2. измерить тем же счетчиком.

Ну поскольку именно Вы а не я свалили в кучу две задачи и получали уравнение с двумя неизвестными, то для данного случая, да, надо менять.

Ну и третье. Так как скорость передачи неизвестна, то как этот break не спутать с нулевым БИ или их комбинацией, следующей на пониженной скорости, мне не ясно.

Все очень просто - break по определению должен быть длиннее самого длинного байта

Опять-таки, в кучу свалено две задачи, калибровка и автоподстройка.

Это не я так задачу за уши притянул. Для решения одной из двух задач никакие дополнительные таймера и почие извращения не нужны.

[x736C]

«Break должен быть длиннее самого длинного байта».. Это ли не ограничение на протокол передачи? Длинный break, перекрывающий все возможное, решает проблему калибровки. Но остается необходимость реализовывать отдельно autobaud rate.
(То, что это существует аппаратно где-то и в чем-то отношения к теме не имеет).
Я ничего не сваливал в кучу, вы что-то напутали по ходу наших рассуждений, все было свалено до меня.
«Для решения одной из двух задач..» Да кто ж с этим спорит? Только зачем навязывать «простое» решение для задачи, которая перед человеком не стояла.
В общем бессмысленный спор, думаю, вы со мной согласитесь хотя бы в этом.

[zltigo]

«Break должен быть длиннее самого длинного байта».. Это ли не ограничение на протокол передачи?

Повторяю третий и последний раз - протокол передачи НИКАК при этом не ограничивается - ему по барабану есть там break, нет его, и что он там делает или не делает. Break отрабатывает таймер c обработчиком - это исключительно его епархия.

Длинный break, перекрывающий все возможное, решает проблему калибровки. Но остается необходимость реализовывать отдельно autobaud rate.

Длинна break и кроме всего прочего и задает baud - получили break, откалибровались по его длительности и вычислили по нему baud на которой с нами хочет общаться master.

[x736C]

Мы уже пошли по кругу.
Если вам надо в линию что-то передавать кроме данных, то это уже ограничение.
Если нужно передавать брейк, который длиннее одного байта (300 бод), то это почти в 400 раза длиннее байта минимально возможной длинны.
То есть протокол должен учитывать тот факт, что на 3,3 мс передача ему будет недоступна.
Передавать брейк на той же скорости, на которой вы планируете передачу, занятие бессмысленное, если приемник не будет ее (эту скорость) знать.
Я вроде понятно излагаю.

«Длинна break и кроме всего прочего и задает baud - получили break, откалибровались по его длительности и вычислили по нему baud на которой с нами хочет общаться master».
Тут я вижу ошибку.
См. выше. Если брейк передается на скорости передатчика, а именно это вы имеете в виду, раз предлагаете по нему подстраивать скорость, то не получится так просто отличить его от данных. Ваша схема может не отличить комбинацию нулей на одной скорости, от сигнала брейк на другой.

Например break на скорости 115200 просто удивительно точно совпадает с 1 нулем на скорости 9600.
То есть байт синхронизации или брейк делиметер тут необходим со всем вытекающим.
Я же говорю, это шило на мыло.

[zltigo]

Я вроде понятно излагаю.

Разумеется нет - ведомое устройство просто должно изначально ожидать соединения на МАКСИМАЛЬНОЙ скорости. Соответсвенно брейк должен только длиннее предлагаемой "новой" скорости. Посему все Ваши последующие рассуждения ложны.

[Guest_@Ark_*]

Во, дискуссия развернулась...

Не валите в кучу две разных задачи...

Да, я бы рад не валить, но реале они, часто, уже находятся в одной куче... И почему бы это не использовать?
Связать процедуры автоопределения скорости и протокол обмена. Например, предложенная мною методика, достаточно просто и логично вписывается в общеизвестный протокол MODBUS (правда, пока устройство одно на линии). После определения скорости, проверяем контрольную сумму запроса. Если все совпало, то с очень хорошей достоверностью скорость определена правильно. Иначе - не отвечаем и ждем следующего запроса...
Аналогично поступаем в случае сбоев (возможно из-за "ухода" текущего значения частоты RC)...
Самое главное, что абсолютно никаких дополнительных "усилий" со стороны Мастера для реализации автокалибровки в этом случае не требуется. Он даже "не знает" об этом...

[SasaVitebsk]

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

Честно говоря так по памяти выдал. Немного ошибся. Сейчас посчитал примерно 95% получается.
Нельзя по первому байту (моим алгоритмом) восстановить следующие байты ff,fe,fc,f8,..,80,00. Короче байты с одним перепадом после старта. Ну и ещё наверное пару байт с 2 перепадами равноширинными. Если модифицировать алгоритм, то можно уменьшить число "неверно детектируемых" байт ещё вдвое. Останутся только ff,fe,f8,80. Если обрабатывать поток непрерывно, либо анализировать возможность ошибки, то можно гарантированно востанавливать поток полностью.

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

Наоборот. Немного упростил. Поленился. Посмотрел, что US Robotics Courier даёт примерно аналогичный результат и успокоился. Но проанализировал, что можно лучше. Зато получил P&P / диагностику под виндой. А народ даже и не догадывается что работает не аппаратный UART. Сбоев никогда не наблюдал. Выпускали несколько лет.

[x736C]

Как правило наименьший БИ двигает скорость в сторону увеличения, а у вас специальный символ брейк двигает скорость в сторону уменьшения. Это конечно «проще», это конечно «эффективнее».
Обратно как собираетесь скорость возвращать, если она изменится?
Вы с таким упорством пытаетесь доказать, что предложили нечто лучшее, чем реализовал @Ark для тех элементарных требований, которые у него были.
Проще вы это не сделаете так, как описываете. Я вам попытался доказать, но у меня не получилось.

SasaVitebsk, сложно, не значит плохо и я лишь предположил. Я рад за вас, что все работает успешно.
У вас, опять же, видимо была своя задача. Немного не понимаю, почему вы говорите о восстановлении потока. Что-то связано с модем.
95% это очень мало. Скорее всего мы о разном тут говорим.
Если скорость определяется верно, а петля автоподстройки охватывает вероятность появления «неудачных» байт в случайном потоке, то схема автоподстройки должна гарантировать попадание близкое к единице.

[zltigo]

реализовал @Ark для тех элементарных требований, которые у него были.

Элементарные частные требования были озвучены только в прошлом посте. Я рассуждал и рассуждаю о максимально универсальном независимом и отвязанном от протокола варианте. Частные случаи на то они и частные, что бы позволять применять частные заточенные решения.

Проще вы это не сделаете так, как описываете.

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

Обратно как собираетесь скорость возвращать, если она изменится?

Что значит "она изменится"? Сама Вы вдуг зачем-то захотите прыгнуть по бодовым скоростям вверх процессе работы? Неведомо зачем, но для этого можно, например, подать брейк многократно превыщающий текущюю байтовую длительность и по этом признаку уйти на максимальную, или использовать длительности break не в сетке бодовых скоростей.

[x736C]

Ой, да, мы о разном.
Вы о первом байте, а я вообще.
Все понял, пересчитывать за вами не буду.

[zltigo]

Вы о первом байте, а я вообще.

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

[x736C]

Элементарные частные требования были озвучены только в прошлом посте. Я рассуждал и рассуждаю о максимально универсальном [/b]независимом и отвязанном от протокола[/b] варианте. Частные случаи на то они и частные, что бы позволять применять частные заточенные решения.

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

Что значит "она изменится"? Сама Вы вдуг зачем-то захотите прыгнуть по бодовым скоростям вверх процессе работы? Неведомо зачем, но для этого можно, например, подать брейк многократно превыщающий текущюю байтовую длительность и по этом признаку уйти на максимальную, или использовать длительности break не в сетке бодовых скоростей.

С одной стороны говорите об универсализме, с другой стороны начинаете «высасывать из пальца» алгоритм универсальной автоподстройки.
Брейк — это усложнение, неужели не очевидно? В случае калибровки — да, я с вами согласился.
Скорость может меняться по разным причинам, не будем об этом.
Ладно, всем удачи. Спасибо за общение.

Ой, да я вообще о байтах не говорю - ни о первых, ни о вторых, и не о последующих.

Я писал не вам, а отвечал SasaVitebsk. Просто вы успели написать сообщение между.

[SasaVitebsk]

Наверное просто надо расставить все точки над i. Точнее говоря систематизировать понятия и знания. Кстати, недавно был удивлён. Оказывается основным достижением Менделеева во всём мире считается не таблица элементов, а то что он заложил основы систематизации как таковой. И, как мне кажется, это очень показательно что мы это его изобретение незаметили. Уж очень восточные славяне сумбурны и слабо поддаются причёсыванию. Не то что немцы. У тех даже в концлагерях шёл чёткий учёт выбитых зубов.

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

Я бы всётаки тоже постарался не сваливать всё в кучу и сделал бы максимально независимыми задачи.
Давайте сначала их выделим.

1) Подстройка частоты проца.
2) Автоопределение скорости передачи
3) Приём байта
4) Приём пакета (инфы).

Автоопределение скорости, на мой взгляд, должно работать уже при гарантированной частоте кварца. Так как при любом алгоритме вы не получите точной величины. Например при частоте МК AVR в 8МГц, без применения специальных мер (типа завести Rx на две ноги), полингом вы получите точность измерения импульса 4 такта. При скорости 115200 точность измерения длительности составит ~6%. То есть совершенно очевидно, что для подстройки частоты кварца необходимо выбирать больший интервал. Один из вариантов вам предлогал zltigo. Кто-то на форуме предлогал по часовому кварцу калиброваться. Это уже другой вопрос как.

А если калибровка присутствует, то само автоопределение скорости может быть сделано и мастером. Например он посылает пакеты на разных скоростях и ждёт ответа. С момента установки соединения посылает команду перестройки частоты. Если идут ошибки в линии слэйв переходит на более низкую скорость. Это я как пример привёл.

[Guest_@Ark_*]

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

Тоже как пример. Камень из серии PIC12 - простенький MK c 8-ю ногами. Две ноги - питание и земля. Занимать еще две кварцем - слишком расточительно (хотя и возможно). Обычно используется встроенный генератор 4МГц. Имеется возможность программно откалибровать, но не вижу в этом особого смысла. Все равно частота немного будет плыть от питания и температуры.
Аппаратный UART не предусмотрен, поэтому - только программный. Калибрую по своей методе, получаю значение БИ с точностью в 1 команду (номинально 1мкс) - лучше, в данном случае, не бывает. При скорости 9600 (длительность БИ 104мкс) имею погрешность порядка 1%. Для нормальной работы UART вполне достаточно. Все всегда работает.

А если калибровка присутствует, то само автоопределение скорости может быть сделано и мастером.

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

[SasaVitebsk]

Вот ниграмма не возражаю и даже поддерживаю. Если вы внимательно читали, то в моём посте от 25.08 я оговариваюсь "Если обрабатывать поток непрерывно...". Это как раз данный случай.
Если реализовывать совтовый UART, то вы полностью контролируете всё: последовательность бит/байт/пакет. Это даёт вам возможность гарантировано востанавливать инфу (с момента однозначности), а также контролировать любые интервалы. То есть подстраивать кварц можно не побитно, а побайтно или 1 раз в 4 байта. Иными словами к моменту завершения приёма пакета вы имеете откалиброванный RC и выдаёте ответ с откалиброванным генератором.

Но я писал про другой вариант (думаю zltigo тоже). Думаю что вы не возражаете, против того, что совтовый UART с автободом и автокалибровкой отнимает значительное количество ресурсов? Кроме того, бывают ситуации, когда требуется реальное время и по другим задачам. То есть есть ещё источники прерываний. Поэтому приходится принять первый байт, а потом перейти в аппаратный режим чтобы иметь возможность отрабатывать параллельно другую задачу. В этом случае ваш вариант непролазит. Так как:

1) С момента переключения на аппаратный UART - автокалибровка и приём - совершенно разные задачи
2) По первому байту нет возможности гарантировать точную калибровку.

[Guest_@Ark_*]

Вы знаете, я когда-то тоже был "фанатом" универсальных решений, а сейчас все больше склоняюсь к прямо противоположной позиции. Все надо применять к месту, в зависимости от поставленной задачи. И универсальность решений - не исключение, imho.
Программный UART имеет свои преимущества и недостатки. Про недостатки Вы уже написали - съедает много ресурсов, накладывает ограничения на использование прерываний, плохо работает на высоких скоростях...
Но есть и неоспоримые преимущества перед аппаратным UART-ом: во-первых - на многих простых МК аппаратного UART-та просто нет (а он нужен), во-вторых - нет необходимости калибровать тактовый генератор (используем как есть), в третьих - можно использовать встроенный генератор и сэкономить на кварце. Кроме того, в некоторых случаях, кварц вообще нельзя использовать, например в случае сильных ударных вибраций. Много случаев, когда программному UART-у просто нет альтернативы...
К процедуре автоопределения скорости (автокалибровке) - у меня аналогичный подход... Конечно, общение с единичным устройством по MODBUS - частный случай. Тем не менее - достаточно широко распространенный, чтобы специально под него сделать процедуру автоопределения скорости. Причем, не налагая каких-либо дополнительных ограничений на сам протокол...

[SasaVitebsk]

Ещё раз повторюсь. Я ничуть не оспариваю принятое вами решение. Считаю его правильным и обоснованным. Поддерживаю вас и в плане универсальности. Программа на МК уже сама по себе неуниверсальна.
Вместе с тем данное решение задачи не везде применимо - вот она неуниверсальность.

А к универсальности мы всётаки двигаемся. И это заметно. Кто раньше на 20 ногом МК планировал применить вытесняющую ОС и писал на С++?