Отправлено: 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 
 

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

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

 Отправлено: 05.06.08 15:55. Заголовок: Логическое объяснени..

Логическое объяснение почему так происходит есть?

 Отправлено: 16.12.08 18:42. Заголовок: Давненько эту тему н..

Давненько эту тему не поднимали.
Насколько я помню предаются/принимаются байты только через паузу, равную по длительности времени передачи байта. Если паузу не сделать - то ошибка - передаётся/принимается только через один.
В двух вариантах кода разница такая:
- В первом сначала передаваемый байт размещается в буфер передатчика, а потом ожидание его отправки.
- Во втором варианте кода - сначала проверяется ушёл ли предыдущий байт, и затем в буфер передатчика размещается следующий.
Тема актуальна - как себя поведёт программа при использовании USB-COM преобразователя?

 Отправлено: 16.12.08 23:23. Заголовок: kaligraf пишет: чер..

kaligraf пишет:

цитата:

через паузу, равную по длительности

Скорее - не менее. Более можно.
Это делается для страховки, от ложного срабатывания приёмника.
Допустим, по какой-то причине, приёмник не сработал по стартовому импульсу.
Тогда он запустится по первому отрицательному перепаду в посылке, т.е. по нулевому биту данных.
Начинает работать внутренний механизм приёма, который тупо отсчитывает 10 периодов. На 10 периоде может быть задействована проверка стопового бита.
Если посылки будут следовать друг за другом непрерывно, время, когда приёмник начнёт очередную проверку стартового бита, опять совпадёт с в/у отрицательным перепадом. Програмная проверка стопового бита не спасёт ситуацию, поскольку, раз был отрицательный перепад, следовательно, перед нулевым битом был единичный. Десятый такт придётся именно на него, и приёмник интерпретирует его как стоповый.
Пауза в период передачи байта даст возможность приёмнику гарантировано завершить приём "ложного" байта.

В Ваших вариантах совершенно не понятно, каким образом организуется пауза.

 Отправлено: 17.12.08 19:38. Заголовок: Dmitry Dubrovenko пи..

Dmitry Dubrovenko пишет:

цитата:

В Ваших вариантах совершенно не понятно, каким образом организуется пауза.

У меня в программах, как для компа, так и для МК вызов передатчиков по таймеру через 2 миллисекунды для скорости 9600.
Приёмник в МК по прерыванию отрабатывает. А в компе - счётчик принятых байт есть - тоже по таймеру проверяется.
Вопрос в том, что не получалось пока организовать передачу инфы сплошным потоком, то есть без миллисекундной паузы между байтами. Хотя в принципе должна быть такая возможность.

 Отправлено: 18.12.08 16:17. Заголовок: Без паузы, никак не ..

Без паузы, никак не обойтись. Такова специфика работы этого модуля. Хочешь не хочешь, а паузу он сам делает.
Может быть, паузу можно уменьшить переходом на более высокую скорость обмена?
Я, этого не проверял.
У меня, при скорости обмена между компьютером и ПИКом =9600, пауза =0,5-0,7мс. Это со стороны ПИКа.

 Отправлено: 19.12.08 06:05. Заголовок: Работает у меня и на..

Работает у меня и на скорости 19200 - таймеры через 1 миллисекунду. Но всё равно пауза получается равна длительности передачи байта, хотя и становится в 2 раза короче.

 Отправлено: 19.12.08 11:37. Заголовок: Не понятно, чего нуж..

Не понятно, чего нужно добится? Уменьшения паузы которую вырабатывает модуль USART? Или поймать момент выдачи последнего бита передаваемого байта сдвиговым регистром TSR ?

 Отправлено: 19.12.08 12:41. Заголовок: Добиться желательно ..

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

 Отправлено: 19.12.08 13:13. Заголовок: kaligraf пишет: Кол..

kaligraf пишет:

цитата:

Количество байт в таком блоке зависит от буфера в МК(у меня максимум 40).

40- чего? Байт в блоке?
У ПИКа, как известно, помещается не более 3-х байт одновременно.
И всё же, я не понял. Для чего повышать скорость передачи?
Сформулирую вопрос по другому.
Скорость передачи нужно повысить со стороны компьютера или ПИКа?
Если со стороны компьютера, то это скорее всего вопрос к Петру.
Если со стороны ПИКа, то опять вопрос: для чего?
Если затягивание передачи от ПИКа к КОМПУ, мешает выполнению каких то важных задач, в основном теле программы, то можно сделать с опросом флага.
Т.е. загрузить в буфер байт данных, и пускай они передаются. В то время, как этот самый байт будет передаватся модулем USART, рабочая точка программы может спокойно делать полезные дела в основном теле. При этом, периодически должен опрашиватся флаг TRMT (1-й бит регистра TXSTA).
Как только он установится в 1, это значит, что ушёл последний бит передаваемого байта.
Тогда мы опять загужаем байт данных, и после чего свободно гуляем по программе. Периодически опрашивая флаг.
Или я опять, всё не так понял?

 Отправлено: 19.12.08 13:32. Заголовок: igor пишет: 40- чег..

igor пишет:

цитата:

40- чего? Байт в блоке?

Это реализовано в пике программно. 40 регистров буфера. Программатор считывает 40 байт из программируемого МК - затем отправляет их в комп. От компа так-же. Пик принимает 40 байт затем записывает их в прогрммируемый МК.
igor пишет:

цитата:

При этом, периодически должен опрашиватся флаг TRMT (1-й бит регистра TXSTA)

У меня такой проверки нет - байт через заданную паузу по прерыванию таймера отправляется. Хотя это хорошая мысль - можно ведь и прерывания от передатчика USART пика отслеживать

 Отправлено: 06.05.09 15:47. Заголовок: Всем привет! Тему вс..

Всем привет! Тему все закончили в 2007 году, а я только начал с ней знакомиться.
Если можно два вопроса. Асинхронный режим. С практической точки зрения, какой скоростной режим предпочтительней при одинаковой скорости передачи информации- низкоскоростной или высокоскоростной и почему? Второй вопрос, если это возможно, то как определить частоту внутреннего такта передатчика (приемника), не имея ввиду частоту передачи данных?
И еще, я рискну ответить на последний заданный вопрос, если Петр сможет сделать уточнение, пропадает каждый второй, или все таки каждый первый байт? Спасибо.

 Отправлено: 06.05.09 15:56. Заголовок: ­Извините, со словом ..

*PRIVAT*

 Отправлено: 06.05.09 16:35. Заголовок: Я обычно использовал..

Я обычно использовал скорость 9600 Бод при чатоте генератора, равной 4МГц, поэтому использовал высокоскоростной режим. Если не ошибаюсь, низкоскоросной режим не позволяет использовать данную скорость и вообще его целесообразно использовать лишь при очень низких скоростях обмена или при высокой чатоте задающего генератора. При его испорльзовании тактовые импульсы поступают в модуль USART через предделитель.

nik_nik пишет:

цитата:

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

Пропадает лишь при неправильном способе передачи данных.
Выше об этом писалось.

 Отправлено: 06.05.09 17:12. Заголовок: Петр, в соответствии..

Петр, в соответствии с даташитом из талиц, выбор скорости немного отличается только для высоких частот, а так в основном одинаковые, поэтому непонятно как лучше поступать? Например, кварц 20 Мгц, в обоих режимах можно установить скорость передачи/приема от 0,3 до 300 Кбит - низкоскоростной, от 9,6 до 1250 Кбит для высокоскоростного, например в районе 96-300. А вот насчет почему целесообразно тот или другой?
Что касается передачи, я понял, что при одном варианте проходит, а при другом нет. А на суть вопроса, какие байты пропадают, наверное уже не помнишь точно?

 Отправлено: 06.05.09 18:20. Заголовок: Пропускался каждый в..

Пропускался каждый второй байт

 Отправлено: 07.05.09 01:12. Заголовок: Причину я понял, объ..

Причину я понял, объяснение в виде материала в Обмен (коротко не получается) уже отослал Евгению Адександровичу,
так что через денек и вам поступят. Успехов и с днем Радио. Если будут другие мнения можно продолжить через форум в этой ветке.

 Отправлено: 07.05.09 19:30. Заголовок: В статье обмена 2_42..

В статье обмена 2_42 Поддорогина Николая "Решение проблемы режима асинхронной передачи модуля USART", выполняется опрос флага TRMT до победного конца.

             bsf        Status,RP0   ; переход в 1 банк   
             btfss      TXSTA,TRMT   ; Байт данных передан или нет? 
             goto        $-1         ; Нет, то ожидаем 
             bcf         Status,RP0  ; Да, переход в 0 банк и продолжение 
                                     ; программы 
             movwf      TXREG        ; Загрузка очередного байта в буфер 
                                     ; передатчика 

Считаю что это трата драгоценного машинного времени. Модуль USART, довольно долго передаёт информацию, если мне не изменяет память, то один байт передаётся несколько миллисекунд.
За это время, рабочая точка вместо топтания на месте, сделает кучу полезных дел.
Надо просто разбросать опрос флага TRMT по телу программы и переодически опрашивать его. Если поднят, то загрузка следующего байта, если опущен, то программа исполняется далее.
У меня, опрос этого флага, и уход в ПП загрузки очередного байта, осуществляется в ПП ENTER_BF, PAUSE и т.д.
Если посмотреть внимательно, то большую часть времени, рабочая точка находится именно в этих ПП (ПП ожидания чего-то). Вот и пускай во время ожидания делаются полезные дела.

 Отправлено: 07.05.09 20:51. Заголовок: Не согласиться с эти..

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

 Отправлено: 07.05.09 20:54. Заголовок: Игорь, это желател..

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

PS: Николай изложил суть (самое сложное). Спасибо ему за это. Ну а развитие темы никто не отменял.

 Отправлено: 07.05.09 23:07. Заголовок: nik_nik пишет: по с..

nik_nik пишет:

цитата:

по сути было бы интересней

По сути, скажу следующее. Лично у меня, не наблюдалось потери каждого второго байта при передаче. Терялись последние два байта. И терялись они не в ПИКе. ПИК, как ему и положено, выдавал все пять байт на передатчик RS485 (проверял осциллографом, чётко были видны пять пачек импульсов). Терялись они, по причине преждевременного запрещения работы на передачу передатчика RS485 (опять же, проверял осциллографом - на входе передатчика RS485 присутствуют все пять байтов данных, а на выходе только три байта). Грешил на инерционность микросхемы MAX485, а инерционным оказался сам модуль USART. В чём меня и поправил Липин Руслан.
При этом, опрашивал флаг TXIF по известной всем схеме

             movwf      TXREG       ; Запись очередного байта в буфер передатчика. 
             btfss      PIR1,TXIF   ; Буфер передатчика полон? 
             goto       $-1         ; Да, полон, то ожидаем 
             ....       ....        ; Нет, пуст, продолжение программы 
  

Ну не было у меня потери каждого второго байта, все они выходили из ПИКа живые и здоровые. Была моя невнимательност и незнание работы модуля USART.
После "вождения носом по батарее"_{(слова и музыка КЕА)}, всё стало на свои места. Сначала применил задержку на выключение передатчика RS485, а потом заменил её на опрос флага TRMT.

 Отправлено: 08.05.09 01:29. Заголовок: 1. C точки зре..

1. C точки зрения использования времени в промежутке между передачами байтов для меня вопрос очевидный, Игорь поднял тему, ему и высказываться в Обмене. Если внимательно почитаете концовку моего материала, то я даю маленькую рекомендацию по использованию того или иного модуля и обращаю внимания (поясняю), что модуль

btfss PIR1,TXIF ; Буфер передатчика полон?
goto $-1 ; Да, полон, то ожидаем
movwf TXREG ; Пуст, Запись очередного байта в буфер передатчика

предпочтительнее (это относится и к модулю в случае использовании флага TRMT), потому что можно использовать все время между передачами байтов в основной программе, а в точку ожидания мы попадаем только после того,как все дела в основной сделаны. Если для этих дел времени передачи 1 байта до очередного мало, то тогда и дополнительный опрос флага можно организовать в разных местах программы.
2. Теперь о модуле, который ты привел в последнем высказывании, он же предмет моего материала в Обмене.

movwf TXREG ; Запись очередного байта в буфер передатчика.
btfss PIR1,TXIF ; Буфер передатчика полон?
goto $-1 ; Да, полон, то ожидаем
.... .... ; Нет, пуст, продолжение программы

Наконец то стало известно, что ты применял именно его, когда была потеря 2-х байтов. Да, Липин Руслан в своем дополнении (в верхней части) очень точно описал какая ситуация у тебя должна быть при этом модуле (если бы он работал правильно) - потеря только 1 байта. Что касается нижней части его дополнения, он рассуждает (предполагает, потому что не было живого материала в руках для анализа):
"Если же программа микроконтроллера переводит микросхему MAX485 на приём сразу же после записи 5-го байта в TXREG, то в этот момент в регистре TXREG и сдвиговом регистре TSR (см. даташит DS30292C стр.96) будут находиться 5-й и 4-й байт соответственно и они не уйдут в линию...".
В твоем случае, после того как 4 байт передается, а 5 запишется в буфер, то начинается ожидание и только после того как 4 будет передан, произойдет перемещение 5 байта в TSR, поднимется флаг, происходит выход из модуля и только после этого ты запрещаешь передачу МАХ485, 4-ый байт уже передан. Не передается 1 байт - 5-ый. Тогда вопрос - почему 2? Кстати интересно в каком месте программы после этого модуля ты делал запрет передачи на микросхему и какой кварц применяешь? Кварц можно предположить, на схеме не изображен резонатор, значит RC - до 4Мгц.
Вот почему материал без примеров - сырой материал в Обмене, нельзя посмотреть, а значит и обсудить детально, а ошибаемся мы все.
Теперь о том, что ты утверждаешь, что пересылаются только 3 из 5 байтов и именно 2 последних теряются. Я то думал, что ты на ПК отследил какие байты теряются, ты же с этой связкой работал, а оказывается осцилографом? Во-первых, осцилографом по пачкам импульсов ты не мог отследить какие именно байты не доходят, два последних или все таки каждый второй, тоесть не получаешь 2 и 4 байты, это можно отследить в связке ПИК --- ПК посмотрев содержание байтов в компьютере и я думаю, что кто то это сделает, у меня пока нет времени и я писал тебе об этом в личном письме, только после этой проверки можно утверждать.
Во-вторых, так как все таки не доходят 2 байта, в связке с приведенным тобой модулем можно с уверенностью предполагать, что у тебя тот же вариант, что описан в моем материале, ошибка работы данного модуля.

 Отправлено: 08.05.09 09:22. Заголовок: nik_nik пишет: Во-п..

nik_nik пишет:

цитата:

Во-первых, осцилографом по пачкам импульсов ты не мог отследить какие именно байты не доходят, два последних или все таки каждый второй

nik_nik пишет:

цитата:

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

Ещё раз повторюсь. На выходе модуля USART присутствуют все пять байтов, живые и здоровые. Это я хорошо видел на осциллограмме. Такими же живыми и здоровыми, они доходили и до входа передатчика RS485.
Постараюсь на выходных выбрать время, и занятся этим вопросом. Всё будет сфотографировано и задокументировано.

 Отправлено: 08.05.09 21:15. Заголовок: Сильно извиняюсь, у ..

Сильно извиняюсь, у меня действительно был безглючный вариант опроса флага TXIF.

btfss PIR1,TXIF  
 goto $-1  
 movwf TXREG

Вот так, было:

;============================================================================ 
 ; ПП передачи байта данных (USART). 
 ;============================================================================ 
 RS232          bcf         STATUS,RP0    ; переход в 0-й банк 
                 bsf         PORTC,4       ; разрешить передачу,запретить приём. 
                movlw       .250   
                call        RS232_1 
 ;--------------------> 
                movlw       .1            ; номер устройства 
                call        RS232_1 
 ;--------------------> 
                movlw       .1 
                call        RS232_1   
 ;--------------------> 
                movf        DANNIE_,0 
                call        RS232_1 
 ;-----------------> ;------------------------------------ 
 ;ПОдсчёт контрольной суммы для отправки компьютеру. 
 ;---------------------------------- 
                clrf        VICHISLEN_ 
                movlw       .250 
                subwf       VICHISLEN_,1 
    
                movlw       .1            ; номер устройства 
                subwf       VICHISLEN_,1 
    
                movlw       .1 
                subwf       VICHISLEN_,1 
    
                movf        DANNIE_,0 
                subwf       VICHISLEN_,0 
                movwf       KS_ 
                 
                bcf         STATUS,Z 
                sublw       .250 
                btfsc       STATUS,Z 
                goto        KS_MINUS_PERED 
                movf        KS_,0 
                 
                call        RS232_1 
  ;----------------> 
                bcf         PORTC,4       ;запретить передачу. 
                return 
 ;----------------------------- 
 KS_MINUS_PERED decf        KS_,0 
                call        RS232_1 
 ;---------------------------> 
 ;---------------------------------------  
                bcf         PORTC,4       ;запретить передачу. 
                return 
 ;----------------------------------- 
 RS232_1       btfss       PIR1,TXIF     ; Предыдущий байт данных передан или  
                                          ; нет? 
                goto        $-1           ; Если еще не передан, то ожидаем. 
                movwf       TXREG         ; Если передан, то загрузка следующего 
                                          ; байта данных в буфер передатчика. 
                clrwdt 
                return                    ; Возврат.             
 

Команды запрещающие MAX485 работать на передачу, выделены синим цветом.
Если оставить так как есть, то будут терятся два последних байта. Если перед этими командами врезать ПП задержки, то всё придёт в норму. Это говорит о том, что модулю USART, естественно требуется какое-то время на передачу байта.
Это был, мой самый первый вариант.
Сейчас, просто опрашиваю флаг TRMT и никаких проблем.

P.S. Ошибки свойственны нормальному человеку.Не ошибается тот, кто ничего не делает.

 Отправлено: 08.05.09 21:32. Заголовок: Продолжаю тему и док..

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

movwf TXREG ; Запись очередного байта в буфер передатчика.
btfss PIR1,TXIF ; Буфер передатчика полон?
goto $-1 ; Да, полон, то ожидаем
.... .... ; Нет, пуст, продолжение программы

теряется каждый второй байт. В моем учебном проекте была организована передача потоком 6-ти байтов, каждые три байта(адресный, информационный и контрольный) в определенной последовательности высвечивали светодиоды в другом МК после приема. Я думал как проверить без применения ПК, и вот через каждый информационный байт я вставил передачу дополнительного неинформационного байта, кроме того в каждых 3-х информационных байтах присутствовала контрольная сумма, которая проверялась в принимающем МК. И так вместо 6 передавал 11 байтов (12-ый не имел смысла), в связке с этим модулем в работе принимающего МК ничего не изменилось, контрольные суммы проверялись и светодиоды высвечивались как им и положенов в той же последовательности. Таким образом каждый второй байт никак не повлиял на работу по передаче данных в другой МК, то есть неинформационные байты так и не вышли из передатчика передающего МК. На этом подтему считаю исчерпанной, а подраздел 2/33 Обмена надеюсь дополниться более достоверной информацией.

 Отправлено: 08.05.09 21:55. Заголовок: Игорь, пока писал св..

Игорь, пока писал свое сообщение ты прислал свое. Теперь по программе четко видно, что два последних байта не успели покинуть микроконтроллер, а МАХу запретили дальше передавать, то есть на входе его ты наблюдал 5 пачек, а на выходе 3. Хорошо, что все точки расставлены и все предельно ясно. Успехов в работе.

 Отправлено: 11.05.09 17:20. Заголовок: Ниже, по просьбе ..

Ниже, по просьбе Радченко Владимира (цитирование разрешено Владимиром. В списке, №258), опубликовано его сообщение (относится к статье 2_42 "Обмена…").

А если написать, как того требует логика работы UART:
(The TXIF interrupt flag bit of the PIR1 register is set whenever the USART transmitter is enabled and no character is being held for transmission in the TXREG.)

 btfss         PIR1,TXIF   ; Байт данных передан или нет? 
 goto          $-1         ; Если байт еще не передан, то ожидаем. 
 movwf         TXREG       ; Загрузка байта в буфер передатчика,

то всё станет на свои места и потоковый режим будет соблюдаться.

 Отправлено: 11.05.09 23:16. Заголовок: Ответ Владимиру. Мы ..

Ответ Владимиру. Мы не всегда живем по писанному, а изобретаем и во многих случаях выигрываем, и поэтому наши программисты занимают первые места в международных конкурсах. Тот и другой модуль имеет право на жизнь, и в разных случаях может оказаться востребованным. Но тем не менее, именно этот модуль рекомендовался в материалах Обмена (2/42) и выше по форуму, как самый предпочтительный, кроме того наши коллеги давно его используют. Вопрос неразрешенный был в другом и его надо было разрешить, а в материалах целью было пояснить программно-аппаратную задержку и во что она выливается (с ней особо не по изобретаешь), это не единичный случай а скорей закономерность ПИКов, которую надо учитывать в своей работе, например использование порта PortB, запись в который производиться в конце машинного цикла, а чтение вначале, если сразу после записи начать читать, то скорее прочитаем старое значение, а не новое - из документации.

 Отправлено: 15.06.09 15:01. Заголовок: Я сегодня связал два..

Я сегодня связал два компьютера с ПИКом. Один, через отладчик ICD2, второй, через модуль USART.
Короче говоря, с помощью одного компьютера, передаю данные ПИКу и принимаю их от него. А с помощью другого, отслеживаю работу программы в МПЛАБе.
Обнаружил некоторые интересные особенности (мне ранее не известные) модуля USART.
Например.
Если в модуль USART, загнать байт, потом считать его, загнать следующий, считать и т.д., то всё идёт как по маслу. Здесь прекрасно работает опрос флага RCIF (PIR1<5>)

btfss     PIR1,5 
 goto     $-1 
 ...............

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

btfss     PIR1,5        ;считываем  
 goto     $-1             ;1-й  
 movf     RCREG,W       ;байт 
 ........................ 
 ........................ 
 btfss     PIR1,5         ;считываем  
 goto     $-1              ;2-й 
 movf     RCREG,W        ;байт

Первый байт считается без проблем, а на втором, программа зависнет на выделенных синим командах.
Потому, что флаг RCIF является флагом прерывания от приёмника USART.
Он поднимается при прохождении принимаемого байта в буфер и сигнализирует об этом.
После считывания первого байта, флаг RCIF опустится и не поднимется при проскальзывание в RCREG, второго байта из буфера.
Здесь нужно или сразу считывать второй байт, следом за первым ( знать бы что он там точно находится ) без применения опроса флага, или следить, чтобы в приёмнике не находилось одновременно более одного байта.
Хотя, если посмотреть на диаграмму приёма данных модулем USART (рис.10-5) русского перевода даташита, то там флаг RCIF остаётся поднятым во время считывания второго байта.
Но на деле, это не так.

 Отправлено: 16.06.09 11:18. Заголовок: Насколько я помню, в..

Насколько я помню, в приёмнике нет буфера (могу ошибаться).
Стопориться может из-за ошибки кадра RCSTA,1, если бит поднимается, то пока не выполнишь сброс RCSTA,4 работать не будет.
Сейчас опять собираюсь заняться USARTтом, ести идея.

           btfsc       RCSTA,1     ; Проверка на наличие ошибки кадра, 
                   call        RESERR       ; если ошибка была, то в ПП сброса ошибки. 
 ;------------------------------------   
 RESERR       bcf         RCSTA,4 
                   bsf         RCSTA,4 
                   return  

 Отправлено: 16.06.09 11:46. Заголовок: Из даташита: Регистр..

Из даташита: Регистр RCREG имеет двойную буферизацию, т.е. представляет собой двухуровневый буфер FIFO. Поэтому можно принять два байта данных в FIFO RCREG и третий в регистр RCR.
RCSTA,1 это флаг переполнения приёмника.
Из даташита:Если FIFO заполнен и обнаружен стоповый бит третьего байта, устанавливается бит переполнения приёмникаOERR(RCSTA<1>)
Тогда сброс будет выглядеть так

  btfsc       RCSTA,1     ; Проверка на переполнение приёмника  
                    call        RESERR       ; если ошибка была, то в ПП сброса ошибки.  
  ;------------------------------------    
  RESERR       bcf         RCSTA,4  
                    bsf         RCSTA,4  
                    movf    RCREG,W 
                    movf    RCREG,W 
                    return  

Бит ошибки кадра FERR(RCSTA<2>) устанавливается в "1", если не обнаружен стоповый бит.

 Отправлено: 16.06.09 13:09. Заголовок: igor пишет: ..

igor пишет:

цитата:

movf RCREG,W movf RCREG,W

Это я понимаю очистка буфера, который может принять два байта?
Под рукой нет даташита, что за RCR?

 Отправлено: 16.06.09 13:20. Заголовок: Описка вышла. Не RCR..

Описка вышла. Не RCR а RSR - cдвиговый регистр приёмника.
P.S.Да. Команды чтения из RCREG это очистка приёмника от сидящих в нём байтов данных.

 Отправлено: 16.06.09 14:28. Заголовок: igor пишет: Описка ..

igor пишет:

цитата:

Описка вышла. Не RCR а RSR - cдвиговый регистр приёмника.

Понятно.igor пишет:

цитата:

btfss PIR1,5 ;считываем goto $-1 ;1-й movf RCREG,W ;байт ........................ ........................ btfss PIR1,5 ;считываем goto $-1 ;2-й movf RCREG,W ;байт

А для чего применять такую тактику, ради спортивного интереса?

 Отправлено: 16.06.09 14:31. Заголовок: igor пишет: ;-----..

igor пишет:

цитата:

;-----------------> ;------------------------------------ ;ПОдсчёт контрольной суммы для отправки компьютеру. ;----------------------------------

О какой контрольной сумме идёт речь?

 Отправлено: 16.06.09 15:13. Заголовок: Sergey Roslik пишет:..

Sergey Roslik пишет:

цитата:

А для чего применять такую тактику, ради спортивного интереса?

А как же иначе?

btfss PIR1,5      ;ждём прихода 
 goto $-1           ; байта 
 movf RCREG,W ;считываем байт 
  
 btfss PIR1,5      ;ждём прихода 
 goto $-1           ; 2-го байта 
 movf RCREG,W ;считываем  2-й байт 
 

Я не сказал, что у меня опрос модуля USART происходит без прерываний. Все прерывания запрещены.
Опрашиваю по ходу программы. Данные пришли? Перехожу на считывание. Нет? Работаем дальше.
Поэтому по приходу первого байта (он у меня всегда должен быть равен числу .250), перехожу на приём остальных четырёх байт.

Sergey Roslik пишет:

цитата:

О какой контрольной сумме идёт речь?

Данные от компьютера к ПИКУ идут в следующем формате:
1-й байт - число .250 (стартовый байт)
2-й байт - порядковый номер ПИКа
3-й байт - порядковый номер команды
4-й байт - данные (если данных нет - то 00)
5-й байт - контрольная сумма полученная вычитанием из предварительно обнулённого регистра первых четырёх байт.

ПИК, на своей стороне, принимает стартовый байт. Если он равен .250 значит это не помеха а начало посылки. Переходит на приём следующих байт.
Если не равен .250, то очищает приёмник путём двойного считывания регистра RCREG и программа исполняется далее.
Если всё прошло нормально, и все пять байт приняты то, ПИК сравнивает полученную от компьютера контрольную сумму с вычисленной им самим контрольной суммой. Затем сравнивает эти два значения. Если суммы одинаковы, то отправляет компьютеру данные запрошенные им. Если принятая и вычисленная контрольные суммы не равны то, ПИК отсылает компьютеру сообщение об ошибке.

ПИК отсылает компьютеру информацию в следующем формате:
1-й байт - число .250 (стартовый байт)
2-й байт - порядковый номер ПИКа
3-й байт - Результат приёма данных. 01- данные от компьютера приняты без ошибок в контрольной сумме, 02 - ошибка в контрольной сумме.
4-й байт - данные (если данных нет - то 00)
5-й байт - контрольная сумма полученная вычитанием из предварительно обнулённого регистра первых четырёх байт.

 Отправлено: 16.06.09 16:46. Заголовок: igor Я делал приём в..

igor
Я делал приём в программе программатора, используя прерывания от таймера. Для скорости 9600 проверка приёмника в прерывании от таймера раз в 2 миллисекунды. Для скорости 19200 раз в 1 миллисекунду - неплохо работает. То-же возможно и с передатчиком.