Ами не не съм разменил 7 и 8 крак. Мисля, че трябва да са така.


Благодаря за съвета. Ще опитам и по този начин.

и изобщо за какво ти е макс?!
на симулация?!
вържи ги на късо RX и TX още при пика

Аки не съм сигурен, но в повечето примерчета е показано че така се конфигурира хардуерният УСАРТ. Мислех си че проблемът е в битрейта (10400), но се оказва, че това не е проблема. Като го сложа на 9600 също не става. Егаси, не съм вярвал, че може едно предаване на число да е толкова трудно. Ами представям си ако тръгна да предавам цели стрингове или поредица от числа . Борбата продължава.
п.с. Ако не се влияете от мойта "програма" (която е явно супер бъгава) , как бихте го реализирали? Предавам по ТХ цифрата 1 и искам същата цифра да ми се върне по РХ и да я изобразя на ЛСД.
Когато ползвам вградения сериал порт монитор на ЦЦСа всичко е ОК. Което значи че тапата ми работи. С мойта програмка не комуникира.

Съвсем наскоро имах такъв проблем. Проблема беше, че RS-a тръгва с overrun error, която грешка трябва да се изчисти за да тръгне да приема нормално!

Пробвай това При мен работи без грешка Компилаторът ми е CCS

#include <16F877.h>
#device adc=8

#FUSES NOWDT //No Watch Dog Timer
#FUSES HS //High speed Osc (> 4mhz)
#FUSES NOPUT //No Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NODEBUG //No Debug mode for ICD

#use delay(clock=20000000)
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=9)
#include <LCD.C>
char c;

void main()
{

setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_spi(FALSE);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
lcd_init();


while(1) {

putc('*');
Delay_ms(100);
c=getc();
Delay_ms(1000);
printf(lcd_putc,"\fres= %C", c);

}


}

valioman, програмката и схемата което си ми изпратил работят. Понеже видях, че програмката ми не се различава от много от твоята помислих че проблемът е в хардуера. Така се и оказа. Махнах МАКСа232 и всичко се оправи. Сега започвам да мисля защо става така. Трябва на всяка цена да го пусна работещо с МАКСа иначе не ми върши работа. Както каза и mndsl и при мен тръгва с overrun error. Незнам защо и незнам как да я изчистя. Сигурно трябва да се инвертира байта който приемам преди да го изобразя (заради инвертираните изходи на МАКСа).

Какво означава "тръгва с overrun error" ? При включване на захранването така ти тръгва комуникацията, или при началото на всеки пакет данни ? И защо да не знаеш как да я изчистиш грешката ? RCSTA.1 го нулираш и се оправя. Появява се тази грешка, когато FIFO буфера се препълни. В частта за USART е добре описана грешката. Тази грешка, най-често се дължи на шумове влизащи в RxD линията на професора, или пък в не дотам бързата реакция при четене на входните данни ( много зает професор ).

Това за инвертираното на байта откъде ти хрумна ? MAX, че интвертира, инвертира, но нали инвертира 2 пъти, следователно няма на пракика промяна в битовете на предаваните/приеманите данни. По скоро не можеш да свържеш правилно MAX и затова ти идва и overrun error и разните инверсии.

"Какво означава "тръгва с overrun error" ? При включване на захранването така ти тръгва комуникацията"
Точно това означава.

"RCSTA.1 го нулираш и се оправя"
Този бит е read-only се нулира само хардуерно!

Overrun Error се изчиства с прочитане на RCREG, последвано от нулиране на бит CREN от регистър RCSTA и отново установяване на същия бит, т.е.:

MOVF RCREG,W
BCF RCSTA,CREN
BSF RCSTA,CREN

Sorry, нямах пред мен PDF, запомнил съм номера на бита в RCSTA.

Ако така тръгва комуникацията какъв е дерта тогава ? Прати няколко байта в повече, докато се стабилизара предаването и тогава изпращай своите данни.
Никога не съм използвал USART без прекъсвания, винаги с прекъсвания и там се обработват тези грешки. Освен това не може да се очаква, че ще се изхврлят някакви данни от проца по USART модула и те непременно ще достигнат верни до другата страна. Затова има разни протоколи на контрол на приемането/предаването на данни. Щото иначе на масата ще се изпратят данни от платката до ПК или нещо от сорта, но на къра нещата са други .

Дертът е в приемането , не в предаването и е такъв, че докато не нулираш грешката, колкото и байта да пратиш няма да тръгне да приема или ако тръгне ще бъде в случаен момент. Човек, който не знае това, може да се блъска 1 седмица с този проблем. Нека обобщим казаното: RS-a ще работи коректно когато всички грешки бъдат нулирани. И всеки път преди да се пращат или да се приемат данни трябва да се проверява статуса на USART-a!

Пич, що трябва да крещиш ? Има си документация като слънце, ама кой да я чете ....

Все пак се намираме в "Академията" и е добре да се обясни всичко нагледно и по най-простия начин. Понякога документацията не дава отговор на проблема ти, и тук идва ред на форумите, чиято цел е известна на всички. И не крещя

Ок, стори ми се че ти е надебелял нещо гласа

Ами, да. Грешката е моя. Естествено че не трябва да инвертирам. Байта ми се инвертира два пъти - при предаване и приемане, което означава, че байта си ми е един и същи. МАКа съм го вързал правилно. Окъсих Т2Оут с Р2ИН и успях да приема това което съм изпратил. Проблемът се оказва в виртуалният КОМ който ползвам КОМПИМ. Точно къде му е проблемът сега ще видя. Някой ползвал ли го е? Възможно е да не рабори точно заради тази грешка и най-вероятно ще трябва да видя как да прочета статуса и да нулирам грешката. Отделен е въпроса каква е тази грешка и защо се появява.
п.с. Възможно ли е тази грешка да възниква защото в Уиндоуса при конфигурирането на КОМа по подразбиране е 9600, а аз искам комуникация с 10400? Вероятно затова се запълва ФИФОто и от там дава грешка. Сега ще го дам на 19200 и ще видим. За съжаление ми трябва 10400 а такъв битрейт немога да задам от конфигурацията на КОМа.

Грешката и статуса, които споменахме по-горе са в пик-а, а след като си окъсил 2-та пина и програмата работи, значи няма грешки. Търси проблема във виртуалния порт или някъде другаде. А защо ти е такъв нестандартен битрейт? Според мен излишно си усложняваш живота