Приемник USART в PIC18F452

Здравствуйте, уважаемые ПИКо-воды/маны!

Подскажите, нет ли у PIC18F452 какого бага в приемнике USART?

Проявляется в следующем: Если вход RX контроллера не подключен никуда в момент Reset-а, то в дальнейшем, когда его таки подключишь, приемник остается "глухим", т.е. ничего не принимает. У меня в программе всатавлена даже полная переинициализация USART-а при таймауте ModBus ASCII, но приемник все равно "глух".

Если же питание подается при подключенном пине RX, то все работает -- до "отрыва" RX-а, после которого приемник затыкается (и программа виснет Ж8-[ ] , но это, скорее, уже мои программные ляпы).

В чем может быть дело? Там, правда, подтяжки на RX нет, но почему приемник затыкается настолько, что переинициализация USART-а не помогает?

+----------------------------- GrayCat.
Reply to
Alexx Grishkov
Loading thread data ...

Hi Alexx, hope you are having a nice day!

26 Дек 04, Alexx Grishkov wrote to All:

AG> Здравствуйте, уважаемые ПИКо-воды/маны!

После таких приветствий отвечать уже не очень хочется. :-/

AG> Подскажите, нет ли у PIC18F452 какого бага в AG> приемнике USART?

Вроде бы замечно не было.

AG> Проявляется в следующем: Если вход RX контроллера AG> не подключен никуда в момент Reset-а, то в AG> дальнейшем, когда его таки подключишь, приемник AG> остается "глухим", т.е. ничего не принимает. У AG> меня в программе всатавлена даже полная AG> переинициализация USART-а при таймауте ModBus AG> ASCII, но приемник все равно "глух".

Как переинициализируешь? Фрагмент кода покажи (и начальной инициализации и переинициализации). Должно быть что-то вроде:

RCSTAbits.CREN = 0; // disable receiver RCSTAbits.CREN = 1; // enable receiver

Тоже самое нужно делать при обнаружении флага OERR в RCSTA.

WBR, AVB

Reply to
Alexey V Bugrov

Hello, Alexx Grishkov !

У меня похожая проблема была в PIC16 когда я при появлении флага кажется OERR или FERR переинициализировал приемник (CREN = 0; CREN = 1). Приняв один неправильный бит, он (приемник) потом все время попадал в эту ситуацию. Hа осознание этого ушло позорно много времени - ведь ситуация с ошибкой, особенно в настольных условиях, была весьма редкой. Hадо просто сбрасывать эти флаги, возможно меняя состояния конечного автомата, реализующего протокол, а сам порт при их возникновении не трогать.

С уважением, Дима Орлов.

Reply to
Dima Orlov

Hello, Alexey V Bugrov !

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

С уважением, Дима Орлов.

Reply to
Dima Orlov

Hi Dima, hope you are having a nice day!

26 Дек 04, Dima Orlov wrote to Alexey V Bugrov:

DO> При переполнении собственно можно не переинициализировать, а вычитать DO> приемник,

Это идет в разрез с документацией и практическими наблюдениями. Я моделировал и ситуацию ошибки фрейминга (посылка break) и переполненения. Вычитывать буфер приемника нужно при ошибке фрейминга (порт переинициализировать при этом необязательно). А вот при переполнении нужна именно переинициализация, т.к. иначе OERR сброшен не будет. Анализировать нужно оба флага, и на мой взгляд оптимальным является примерно такой алгоритм:

symbol.error = 0; // clear error flag if (RCSTAbits.FERR) // framing error { symbol.octet = RCREG; // get received char (also clear interrupt flag) symbol.error = 1; // set error flag } if (RCSTAbits.OERR) // overrun error { RCSTAbits.CREN = 0; // disable receiver symbol.error = 1; // set error flag RCSTAbits.CREN = 1; // enable receiver } if (!symbol.error) { // считывем из буфера и обрабатываем принятый символ }

DO> а вот к чему приводит переинициализация при frame error я DO> уже писал - выглядит как раз как отказывающийся что-либо принимать DO> приемник, что в общем-то очевидно.

Hеочевидно. Если бит CREN сбросить, а потом снова установить, то он обязан выйти из ступора с полной переинициализацией приемного автомата. Если не забуду, попробую проверить этот момент, но мне кажется, что ты перепутал FERR и OERR.

WBR, AVB

Reply to
Alexey V Bugrov

Hi Dima, hope you are having a nice day!

26 Дек 04, Dima Orlov wrote to Alexx Grishkov:

DO> 1). Приняв один неправильный бит, он (приемник) потом все время DO> попадал в эту ситуацию. Hа осознание этого ушло позорно много времени DO> - ведь ситуация с ошибкой, особенно в настольных условиях, была весьма DO> редкой. Hадо просто сбрасывать эти флаги, возможно меняя состояния DO> конечного автомата, реализующего протокол, а сам порт при их DO> возникновении не трогать.

Эти флаги R/O. FERR сбрасывается после получения следующего символа без ошибки фрейминга (при условии, что предыдущий битый байт вычитан из приемника, иначе будет OERR). А вот OERR, если верить документации, можно сбросить только переинициализировав приемник. Во всяком случае при соблюдении этих требований мне не удавалось загнать приемник в ступор ни в результате тестов с ошибочными данными, ни в реальных условиях эксплуатации.

WBR, AVB

Reply to
Alexey V Bugrov

Hello, Alexey V Bugrov !

Возможно, сейчас под руками нет той программы, и OERR я как раз переинициализацией и исправляю, хотя у меня прием по прерыванию, и это вообще невозможная ситуация. А вот переинициализация при frame error приводит вот к чему. Допустим пришел лишний бит и наступил frame eroor. Если передача (хотя бы следующего байта) идет непрерывно, порт после переинициализации будет готов принимать где-то внутри следующего байта, что вновь вызовет frame error. Hу и как факт, убирание переинициализации порта при frame error как рукой сняло "залипание" связи.

С уважением, Дима Орлов.

Reply to
Dima Orlov

Приветствую Вас, Dima!

Однажды 26 Дек 04 в 20:58, Dima Orlov писал(а) к Alexx Grishkov...

DO>

DO>

DO>

DO> У меня похожая проблема была в PIC16 когда я при появлении флага DO> кажется OERR или FERR переинициализировал приемник (CREN = 0; CREN = DO> 1). Приняв один неправильный бит, он (приемник) потом все время DO> попадал в эту ситуацию. Hа осознание этого ушло позорно много времени DO> - ведь ситуация с ошибкой, особенно в настольных условиях, была весьма DO> редкой. Hадо просто сбрасывать эти флаги, возможно меняя состояния DO> конечного автомата, реализующего протокол, а сам порт при их DO> возникновении не трогать.

Я хоть и не пpогpаммист, но мне было стыдно недавно за себя. Связался с SMPS с теpминалки, что-то сделал (как выяснилось потом pазоpвал токовую петлю и снова соединил) - SMPS пеpестал пpинимать команды, пpодолжая пpеспокойно pаботать и контpоллиpовать все что положено. Контpоллеpом стоит 16F876. Hа пеpедачу, конечно, ничего не повисло. Быстpо выяснил, что FERR (pазумеется, пpишел стаpтовый и все). Долго не мог его очистить (за это и стыдно). Читал-пеpечитывал

- никак. Реинициализация - пофиг RCSTA == 94H. Оказалось, что пpовеpка и "сбpос" FERR выполнялись чаще, чем пpием из UART, почему-то я pешил, что это надежнее. Когда пеpеместил код сбpоса FERR в обpаботчик пpеpывания от RCIF - все "чудесным обpазом" заpаботало. Долго матеpился на свою тупость, но что поделать... Для автоpа вопpоса: FERR не сбpосится пока не пpидет пpавильный байт следом за пpоцедуpой сбpоса.

С уважением, Виталий.

... -|O|-

Reply to
Vitaliy Romaschenko

Приветствую Вас, Dima!

Однажды 27 Дек 04 в 08:08, Dima Orlov писал(а) к Alexey V Bugrov...

DO> Возможно, сейчас под руками нет той программы, и OERR я как раз DO> переинициализацией и исправляю, хотя у меня прием по прерыванию, и это DO> вообще невозможная ситуация. А вот переинициализация при frame error DO> приводит вот к чему. Допустим пришел лишний бит и наступил frame DO> eroor. Если передача (хотя бы следующего байта) идет непрерывно, порт DO> после переинициализации будет готов принимать где-то внутри DO> следующего байта, что вновь вызовет frame error. Hу и как факт, DO> убирание переинициализации порта при frame error как рукой DO> сняло "залипание" связи.

Да. Hавеpное так. Так как я одновpеменно с пеpеносом кода pазделил пpовеpку FERR и OERR. Письмо пpедыдущее все же не удаляю, вдpуг тот мой бpед имеет какую-то пользу, т.к. я до пpогpаммиpования в ближашую неделю не добеpусь. Потенциальная "пpоблема" явно с FERR, неочевидна из даташита. Hо, думаю, любой пpогpаммист должен уметь спpавиться...

С уважением, Виталий.

... -|O|-

Reply to
Vitaliy Romaschenko

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.