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

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

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

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

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

Вы бредите.

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

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

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

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

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


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

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

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

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

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

Это гуд.



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




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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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