Отправлено: 28.12.06 12:46. Заголовок: Модуль USART

Какой алгоритм работы с данным модулем?

 Отправлено: 28.12.06 21:39. Заголовок: Re:

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

 Отправлено: 20.02.07 13:12. Заголовок: Re:

Че то не пойму, USART и RS232 это одно и тоже или разные вещи.

 Отправлено: 20.02.07 13:28. Заголовок: Re:

В принципе я думаю, что да!
RS-рекомендуемый стандарт.

 Отправлено: 21.02.07 17:00. Заголовок: Re:

Я думаю, что только в принципе.
Ибо, RS232 - это конкретный интерфейс с электрическими характеристиками, а
USART - это больше просто способ передачи данных.
Короче говоря, всякий RS232 - USART, но не каждый USART - RS232.

 Отправлено: 26.02.07 17:09. Заголовок: Re:

Короче RS232 железка, USART протокол. Спасибо.

 Отправлено: 13.04.07 17:53. Заголовок: Re:

Т.Е. если к USART подключить драйвер MAX232, то получится интерфейс RS-232, а если драйвер RS-485 то получится интерфейс RS-485 и т.д.
Правильно я понимаю?

 Отправлено: 13.04.07 18:34. Заголовок: Re:

cerega пишет:

цитата:

если к USART подключить драйвер MAX232, то получится интерфейс RS-232,

Не совсем. Дело в том что интерфейс RS-232 содержит ещё и линии DTR, DSR и т.д. по которым идут сигналы управления обменом информации. Так что получается неполноценный интерфейс RS-232 .

 Отправлено: 13.04.07 21:14. Заголовок: Re:

я имею ввиду сигналы RX и TX (прием и передача)

 Отправлено: 14.04.07 10:43. Заголовок: Re:

cerega пишет:

цитата:

я имею ввиду сигналы RX и TX (прием и передача)

Если для правильной работы устройства требуются только эти два сигнала, тогда можно связать ПИК с устройством, имеющим интерфейс RS-232, например с компьютером. Что касается микросхемы MAX232, то в этом случае, можно её заменить двумя транзисторами. Я как раз сейчас собираюсь подобным образом подключить ПИК к компьютеру и передавать команды ПИКу.

 Отправлено: 14.04.07 16:13. Заголовок: Re:

Спасибо за ответ!
А если меня интересует RS-485 для связи двух ПИКов.

 Отправлено: 13.06.07 10:48. Заголовок: Re:

cerega пишет:

цитата:

А если меня интересует RS-485 для связи двух ПИКов.

То вместо МАХ232 чепляете МАХ 485, а там уже настраиваете по отдельным входам микросхемы (вход\выход).

 Отправлено: 12.09.07 00:02. Заголовок: Re:

На схеме подключения COM-порта к микроконтроллеру поставлены перемычки COM(4)DTR-COM(6)DSR и COM(7)RTS-COM(8)CTS

В чём их назначение ? Будет ли схема работать без них ?

 Отправлено: 12.09.07 11:09. Заголовок: Re:

Вот назначение всех сигналов COM порта компьютера.

   
  Контакт      Линия            Назначение                                            Направление 
  
      1           DCD          Несущая сигнала данных обнаружена               Вход 
      2           RXD          Приём данных                                                   Вход 
      3           TXD          Передача данных                                              Выход 
      4           DTR          Перефирийное устройство к приёму готово         Вход 
      5           SG            Общий провод                                                     - 
      6           DSR          Блок данный для передачи готов                      Выход 
      7           RTS           Запрос передачи                                              Выход 
      8           CTS          Передача разрешена                                         Вход 
      9           RI             Индикатор звонка                                             Вход 
  

kaligraf пишет:

цитата:

В чём их назначение ?

Эти перемычки нужны для эмуляции сигналов управления от перефирийного устройства потоком информации.

kaligraf пишет:

цитата:

Будет ли схема работать без них ?

Это уже зависит от конкреной программы, которыя настраивает порт. Например мои программы USART.exe и COM.exe должны нормально работать как с перемычками, так и без них (не проверял ).

Эти сигналы (которые на схеме соединины перемычками) можно использовать для аппаратного управления потоком информации от компа к ПИКу и обратно. Допустим, от компа идет инфа в ПИК и в какой-то момент, ПИК становится очень занят и временно неспособен принимать инфу от компа. Для того чтобы временно прервать передачу инфы от компа, ПИК выставляет на линии CTS определёный логический уровень (точно не помню какой) и делает свои дела. Как только ПИК освободится, он меняет логический уровень на линии CTS на противоположный и передача продолжается с того места где остановилась.

 Отправлено: 09.10.07 08:59. Заголовок: Re:

Доброе время суток! Вопрос на засыпку (для меня принципиальный, поскольку начинаю чертыхаться с USART)
При одновременном включении приёмника и передатчика USART имеет значение, что будет присвоено следующим битам:

TRMT(TXSTA,1)
FERR(RCSTA,2)
OERR(RCSTA,1)

И ещё. Во время работы USART (без рассмотрения вопроса безошибочного приёма) на эти биты нужно как либо програмно воздействовать.

 Отправлено: 09.10.07 20:25. Заголовок: Re:

В даташите написанно, что для сброса OERR, необходимо запретить, а затем разрешить приём (точнее, при запрещении приёма). Т.е., при включении приёма, его значение должно быть 0. Пока принял это "на веру", поскольку программы строил так, что переполнение буфера не возникнет, и нет необходимости в проверки.
Про FERR в русском даташите (в английском, вроде - нет) сказано, что он сбрасывается, при чтении RCREG. Это я проверил на макете (поскольку Протеус, в этом месте глючит), "индейская национальная изба". Он сбрасывался только при приёме следующего байта. Однако, я не моделировал ситуацию, когда в FIFO были заполнены оба регистра. Каков он, при включении, не проверял. И, честно говоря, не пойму, зачем это надо?
TRMT - "индикатор" состояния регистра передатчика. Поскольку, у меня, программа сперва проверяла это состояние, прежде, чем загрузить данные, логично предположить, что, при включении, он устанавливается в 1 (иначе никакой бы передачи не было).
Насколько помню, все в/у биты доступны только для чтения (да это - вообщем-то и не биты, а флаги). И тут я опять не пойму, зачем на них воздействовать программно, если они просто отображают работу аппаратного модуля?

 Отправлено: 10.10.07 04:45. Заголовок: Re:

Dmitry Dubrovenko Спасибо за ответ.
Dmitry Dubrovenko пишет

цитата:

они просто отображают работу аппаратного модуля

Если я правильно понял, на работу USART эти флаги не влияют, и даже наоборот, это USART влияет на их состояние?
Ок!
Тогда ещё один вопрсик. В подпрограмме обработки прерывания от приёмника USART есть необходимость сбрасывать бит RCIF?
По даташиту - его надо сбрасывать, а в разделе 4.5 этого сброса так и не нашёл, хотя флажёчек, на мой взгляд, очень серьёзный - ВАЖНЯК!

 Отправлено: 10.10.07 07:02. Заголовок: Re:

Ruslan Lipin пишет:

цитата:

это USART влияет на их состояние

Совершенно правильно.

Ruslan Lipin пишет:

цитата:

есть необходимость сбрасывать бит RCIF

Разумеется. Любые флаги прерываний необходимо сбрасывать, при выходе из ПП обработки. Иначе будет постоянная обработка прерывания.

 Отправлено: 11.10.07 00:41. Заголовок: Re:

Dmitry Dubrovenko пишет

цитата:

Разумеется. Любые флаги прерываний необходимо сбрасывать, при выходе из ПП обработки

Я тоже так считал и это подтверждается даташитовским описанием регистра PIR1. Вчера читал описание USART. Там про RCIF сказано, что

цитата:

Флаг RCIF доступен только на чтение, сбрасывается апаратно при чтении из регистра RCREG

Чему верить и как быть ума не дам.

 Отправлено: 11.10.07 07:59. Заголовок: Re:

Ruslan Lipin пишет:

цитата:

описание USART

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

 Отправлено: 12.10.07 00:54. Заголовок: Re:

Согласен.
Единовременно можно очистить сдвиговый регистр приёмника чтением из него при поднятии флага RCIF. Ну так вот, этот флаг подымается только при заполнении верхнего уровня этого регистра (того, который доступен для чтения к этому моменту), или при заполнении обоих уровней? В описании Евгения Александровича подразумевается первое. Однако, на первой эпюре в даташите этот флажок подымается только при приёме второго байта, правда там 9-битный приём и непонятные термины типа "детекирование адреса" Так когда же этот флаг подымается? Просто у меня есть необходимость при при чтении принятых данных очищать RCREG, но для этого нужно читать его содержимое. А сколько раз? Один или два?
А можно очистить буфер приёмника банальным его выключением (bcf RCSTA, CREN)?

 Отправлено: 12.10.07 08:17. Заголовок: Re:

Dmitry Dubrovenko пишет:

цитата:

Надо английскую версию глянуть

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

Ruslan Lipin пишет:

цитата:

очистить сдвиговый регистр приёмника

Дело-то в том, что очищать ничего не надо. Нам абсолютно "по барабану", что находится в сдвиговом регистре и буфере. Нас интересует только, являются ли эти данные принятыми по USART и считанными. Для этого нам и нужен флаг RCIF. Поднимается он, при появлении новых данных в RCREG, куда, в свою очередь, они "выталкиваются" из "низлежащих" буфера, или сдвигового регистра.
"Детектирование адреса", это - специальный режим USART, наподобие I2C, позволяет подключать несколько девайсов и обращаться к конкретному, с использованием 9-го бита.

 Отправлено: 16.10.07 05:26. Заголовок: Re:

Dmitry Dubrovenko пишет

цитата:

Нам абсолютно "по барабану", что находится в сдвиговом регистре и буфере. Нас интересует только, являются ли эти данные принятыми по USART и считанными

Отнюдь Задача для меня стала такой, что перед началом приёма нужно очистить RCREG чтобы при приёме точно знать, что принимаются новые байты а не хвостик от старых. Вот и озадачился этим вопрсом. Сейчас пока только теоретически. На выходных во время экспериментов контроллер крякнул, надо идти покупать. Сам не понял из-за чего. Сделал подпайку резистора на плату с установленным контроллером и всё, отмучился бедолага. Подаёшь на него питание, он нагревается и кренку раскаляет, хотя кренка исправна - 5,00 В, хоть приборы калибруй.

 Отправлено: 16.10.07 08:51. Заголовок: Re:

Ruslan Lipin пишет:

цитата:

нужно очистить RCREG

Повторяю ещё раз.
НИЧЕГО ОЧИЩАТЬ НЕ НУЖНО. "Хвостик от старого" может быть чем угодно, в том числе и одними нулями.
ВСЯ РАБОТА - ЧЕРЕЗ ФЛАГИ.
Для уверенного приёма надо обеспечивать нормальную скорость передачи, правильную форму импульсов, и т.д. Или организовывать передачу контрольных байтов, и/или двусторонний обмен.

 Отправлено: 17.10.07 04:22. Заголовок: Re:

Может я плохо сформулировал проблем. Тогда конкретные вопросы.
Dmitry Dubrovenko пишет

цитата:

ВСЯ РАБОТА - ЧЕРЕЗ ФЛАГИ.

RCIF подымается при приёме приёмником двух байт (без чтения из RCREG) или одного?
RCIF опускается при чтении всех принятых байт из буфера или может опуститься даже если в RCREG остался один принятый байт? Спасибо.

 Отправлено: 17.10.07 07:56. Заголовок: Re:

Ruslan Lipin пишет:

цитата:

RCIF подымается

Значит, насколько я понял, он поднимается, при поступлении новых данных в RCREG. Т.е. если у нас все буферы пустые, то принятый из сдвигового регистра байт, сразу попадает туда, RCIF поднимается, и будет торчать, пока RCREG не будет прочтан. Если же, до момента чтения, пришёл следующий байт, он помещается в буфер, а после чтения первого байта (из RCREG), и сброса RCIF, сразу же выталкивается в RCREG, и, соответственно, флаг RCIF опять поднимается.
Полностью проверить это в железе, мне не довелось, поскольку всегда принятые данные считывались сразу (без буферизации).

 Отправлено: 18.10.07 06:41. Заголовок: Re:

Кто-нибудь пробовал управлять сотовым телефоном АТ-командами и расшифровывать его отклики с помощью микроконтроллера?

 Отправлено: 18.10.07 06:42. Заголовок: Re:

спасибо, Дмитрий!

 Отправлено: 18.10.07 09:27. Заголовок: Re:

Ruslan Lipin пишет:

цитата:

Кто-нибудь пробовал

Конечно пробовали (только не я ). По-моему, у нас тут где-то даже ветка есть про это.

 Отправлено: 19.10.07 03:46. Заголовок: Re:

Ruslan Lipin пишет:

цитата:

Кто-нибудь пробовал управлять сотовым телефоном АТ-командами и расшифровывать его отклики с помощью микроконтроллера?

Смотри на этом форуме ветки:http://pic.borda.ru/?1-2-0-00000065-000-0-0-1192183612 и http://pic.borda.ru/?1-2-0-00000041-000-0-0-1181890390

 Отправлено: 09.03.08 14:16. Заголовок: Добрый день уважаемы..

Добрый день уважаемые коллеги!
Разбираю модуль USART по Практикуму. Задумка такая: два устройства на PIC один ведущий -другой ведомый объединяю по RS232. C чтением данных из ведомого вроде понятно. А вот как передать команду управления (ну например BSF PORTA,0) от ведущего ведомому не могу въехать. Не мог бы кто нибудь натолкнуть на правильную мысль. Заранее благодарен.

 Отправлено: 09.03.08 16:32. Заголовок: sergi2 пишет: А вот..

sergi2 пишет:

цитата:

А вот как передать команду управления (ну например BSF PORTA,0) от ведущего ведомому не могу въехать.

Можно сделать так (если я правильно понял вопрос): поставьте в соответствие нужной Вам команде (ну например BSF PORTA,0), какой-либо байт (ну например 0АВh), т.е. при приеме определенног байта (0АВh) ведомый МК выполнит нужную Вам команду (BSF PORTA,0). Правда желательно бы ввести "защиту от помех", т.е. ввести контроль правильной передачи/приема команды, но это уже зависит от конкретного случая.

 Отправлено: 09.03.08 17:12. Заголовок: Я имею ввиду как вед..

Я имею ввиду как ведомый распознает, что это команда а не данные. При составлении программы, а также при программировании PIC, команды распологаются в определённом MPLABом порядке и находятся в памяти программ PICа. Как PIC распознает при чтении из регистра RCREG2 что имеет дело с командой?

 Отправлено: 09.03.08 17:37. Заголовок: sergi2 пишет: как в..

sergi2 пишет:

цитата:

как ведомый распознает, что это команда а не данные

Программно.
Хотя можно задействовать 9-ти битовую передачу/приём.
Скажем, если 9-тый бит это 0, тогда это команда, а если 1, тогда - данные.

 Отправлено: 09.03.08 18:05. Заголовок: Спасибо Альберт, спа..

Спасибо Альберт, спасибо Пётр, буду пробовать

 Отправлено: 09.03.08 18:22. Заголовок: Пётр пишет: Програм..

Пётр пишет:

цитата:

Программно, если 9-тый бит это 0, тогда это команда, а если 1, тогда - данные.

можно и так, а можно передавать пакеты (так сделано в SCSI-интерфейсе, это немного сложнее) и в заголовке пакета указывать что передаваемый байт - команда или передаются данные и имеют такую-то длину, т.е. такое-то к-во байт плюс контрольный байт и т.д. Зависит от конкретного устройства, что Вам нужно: простота в реализации, надежность передаваемых данных. Где-то у меня было пару статей по данному вопросу (теория), если найду, скину на файлообменник.

 Отправлено: 09.03.08 22:56. Заголовок: sergi2 пишет: Как P..

sergi2 пишет:

цитата:

Как PIC распознает при чтении из регистра RCREG2 что имеет дело с командой?

Мне кажется Вы немного заблуждаетесь на этот счёт. По UART'у PIC отправляет, или получает только данные (с его "точки зрения"). "Превратить" эти данные в программу, т.е. заставить его выполнять определённые действия после приёма того, или иного байта, задача программиста. В этом аспекте UART не отличается от многих других интерфейсов, I2C, например.
Полагаю, что если команд довольно много, логичнее использовать вычисляемый переход.

 Отправлено: 13.03.08 20:09. Заголовок: Немного просветлело...

Немного просветлело. Если я правильно понял, ведущий не может явно передать комнду по UARTу. Если необходимо выполнить какую-либо команду ведомым, можно установить бит какого-нибудь вспомогательного регистра в программе ведущего и послать ведомому содержимое этого регистра. Ведомый прочитает установленный бит и выполнит команду. которую пропишешь в программе ведомого PICа. Длина линии связи для RS 232 интерфейса состовляет не более 15 метров, а какую длину линии связи может поддерживать протокол I2C?

 Отправлено: 13.03.08 23:43. Заголовок: sergi2 пишет: Длина..

sergi2 пишет:

цитата:

Длина линии связи для RS 232

RS-232 всего-лишь одна из разновидностей UART. У 485, например, длинна до километра.

 Отправлено: 14.03.08 02:28. Заголовок: sergi2 пишет: какую..

sergi2 пишет:

цитата:

какую длину линии связи может поддерживать протокол I2C?

согласно спецификации до 2м, при суммарной емкости линий связи не более 400пФ.

 Отправлено: 04.06.08 18:05. Заголовок: Проблема следующая. ..

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

 
 string_id   addwf       PCL,F 
             DT          "PureBasicComPort" ; текст 
  
 ok          
            movlw       0 
            movwf       i_temp 
 outbyte    movf        i_temp,0 
            call        string_id 
            movwf       TXREG 
            btfss       PIR1,4 
            Goto        $-1 
            incf        i_temp,1 
            btfss       i_temp,4 
            Goto        outbyte 
            bcf         PIR1,5 
            Return  
 

А оказалось что надо было так:

 
 string_id   addwf       PCL,F 
             DT          "PureBasicComPort" ; текст 
  
 ok          
            movlw       0 
            movwf       i_temp 
 outbyte    movf        i_temp,0 
            call        string_id 
         btfss       PIR1,4 
         Goto        $-1 
            movwf       TXREG 
            incf        i_temp,1 
            btfss       i_temp,4 
            Goto        outbyte 
            bcf         PIR1,5 
            Return 
 

Это обсуждалось тут

Может проблема в чём то другом.
Лично я не могу понять почему первый вариант глючит, а второй нет.