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

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

 Отправлено: 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 миллисекунду - неплохо работает. То-же возможно и с передатчиком.

 Отправлено: 16.06.09 19:10. Заголовок: igor пишет: , ПИК с..

igor пишет:

цитата:

, ПИК сравнивает полученную от компьютера контрольную сумму с вычисленной им самим контрольной суммой.

Меня это интересует, хочу применить CRC, только не знаю какой лучше.
CRC-8 или CRC-16. У тебя не эти коды применены?

 Отправлено: 16.06.09 19:19. Заголовок: Честно говоря, не зн..

Честно говоря, не знаю. Компьютерную программу писал Пётр. Он же и предложил, для вычисления контрольной суммы использовать вышеуказанный мной алгоритм.

 Отправлено: 16.06.09 20:37. Заголовок: igor пишет: 5-й бай..

igor пишет:

цитата:

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

Видимо какойто свой метод.
Я сейчас занялся разработкой протокола для связи с OPC сервером UniOpc.
Думаю применить может CRC как в вычислении контрольной суммы для DS1820.

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

Sergey Roslik пишет:

цитата:

Видимо какойто свой метод

Не совсем. Этот метод используется при расчёте контрольной суммы HEX файлов, в которых хранятся прошивки контроллеров.