ich arbeitet mit einem PIC 16F877 und nutze den Usart im Asynchronen Modus zum Übertragen von Daten vom PIC auf den PC und umgekehrt ! jetzt komme ich zum Problem ! Daten übertragen vom PIC auf den PC kann ich ohne Proleme, allerdings in der andere richtung (vom PC auf den PIC) geht nicht ! eigentlich muss ja der PIC richtig konfiguriert sein da er ja senden kann ! hatte irgendwer von euch ein schon ähnliches Problem ?
RC7 als Eingang definiert, CREN gesetzt ADDEN=0? Dann sollte es gehen. MfG Steffen
also jetzt habe ich folgendes problem: wenn ich den µP neu starte (spannung abdrehen) dann funktioniert es kurz, nach einer weile funktioniert die datenübertrgung allerdings nicht mehr ! irgendwie stehe ich jetzt völlig an !
Hallo, ich habe vor längerem ein Projekt gehabt, wo alles drin vorkommt, was Du brauchst. Das Senden ist sogar mit einem Fifo realisiert. Vielleicht hilft es Dir. mfg Frank Simon
noch was, Chris, was Du schreibst klingt ja erstmal nach watchdog oder stack-Problem. mfg Frank
jetzt ist mir gerade etwas sehr eigenartiges aufgefallen ! kurze vorgeschichte: ich schicke immer einen wert vom pc an den pic und der pic schickt als antwort einen andere zahl an den pc ! vom pc schicke ich ein paar verschiedene zahlen weg und der pic antwortet je nach zahl mit einer anderen zahl ! in meinem jetztigen schicke ich den pic die zahlen 75; 77 und 77. wenn ich die zahl 75 schicke bekomme ich ne antwort vom pic, wenn ich sie mehrmals schicke bekomme ich auch immer wieder die antwort. bei der zahl 77 bekomme ich allerdings nur 1x ne antwort( auch wenn ich sie öfter schicke). wenn ich die zahl 79 schicke bekomme ich ne antwort vom pic, wenn ich sie mehrmals schicke bekomme ich auch immer wieder die antwort. ich kann die beiden zahlen 75 und 79 uach mehrmals gemischt hintereinander schicken und bekomme auch immer die dementsprechende antwort, jedoch wenn ich einmal die zahl 75 schicke bekomme ich keine antwort mehr ! dazu muss ich sagen das ich die zahl in einem unterprogramm schicke und ihm nur die zu schickende zahl übergebe, d.h. es läuft immer das selbe unterprogramm !
na, ist doch klar, der hat ne Allergie gegen die 77. mfg Frank PS: Versuch mal 127 (kein Witz), das dürfte auch nicht klappen, denn da sind hinten auch nur Einsen (wie bei 77) im Binärcode. Dann stimmt Deine Baudrate nicht exakt, ist nur ne Idee.
also, ich ahb jetzt ne testreihe gemacht ! ich schreib jetzt + für "funktioniert" und - für "funktioniert nicht " 67 + 69 - 70 + 71 + 72 - 73 - 74 + 75 + 76 - 77 - 78 + 79 + 81 - 127 + warum funktionieren nur manche zahlen ?
als einzige gemeinsamkeit die die zahlen haben die nicht funktionieren ist mir aufgefallen das sie an ster stelle vom bit 1 ( 2. von rechts) einen nuller haben ! die die funktionieren haben einen 1er ! aber warum ist das so ? und was kann ich dagegen tun ?
Poste doch mal deine genaue Konfiguration also Taktfrequenz, TXSTA, RCSTA, SPBRG. MfG
hier ist meine konfiguration:
void RS232_INI()
{
TXSTA = 0b00100100;
RCSTA = 0b10010000;
SPBRG = 25; //Baud Rate von 9600
SYNC = 0;
SPEN = 1;
TXEN = 1;
CREN = 1;
}
Also bei 4MHz Taktfrequenz sollte das so eigentlich OK sein. Stimmen die Datenübertragungsparameter beim PC? Vor allem 1xStart und 1x Stopbit, NoParity und 8 Datenbit? Wenn die Parameter OK sind, dann liegt es wohl doch am Programm im PIC. MfG
ja, mein pic ist mit 4MHz getaktet ! de parameter beim pc sind: Baud rate: 9600; Data Bits: 8; Parity: none; Stopb Bits: 1; Handshaking: none
Check mal ob evtl. ein Framing-Error beim PIC auftritt. Die Testreihe sieht verdammt danach aus, als ob Bit 6 schon als Stoppbit gewertet wird. Kommen die Werte vom PC auch mit 100%-iger Sicherheit richtig beim PIC an? Ansonsten kann ich dir ohne deinen Quellcode auch nicht mehr weiterhelfen. MfG
das FERR Bit wird nicht gesetzt !
hier ist mein quellcode:
void RS232_INI()
{
TXSTA = 0b00100100;
RCSTA = 0b10010000;
SPBRG = 25; //Baud Rate von 9600 !
SYNC = 0;
SPEN = 1;
TXEN = 1;
CREN = 1;
}
void RS232S (char x)
{
while (TXIF == 0); // PIR1.TXIF
TXREG = x;
while (TRMT == 1);
}
void RS232_EMPFANGEN()
{
zeichen = RCREG;
if (zeichen == 70)
{
RS232S (1);
}
if (zeichen == 72)
{
RS232S (2);
}
if (zeichen == 74)
{
RS232S (3);
}
if (zeichen == 76)
{
RS232S (4);
}
if (zeichen == 78)
{
RS232S (5);
}
if (zeichen == 0)
{
}
}
ups, da habe ich noch die interruptroutine vergessen !
bei einem empfängerinterrupt (RCIF) wird das programm RS232_EMPFANGEN()
aufgerufen !
#pragma origin 4
interrupt int_server()
{
GIE = 0;
int_save_registers //W, STATUS, (and PCLATH)
if (RCIF == 1) //RS_232
{
RS232_EMPFANGEN();
RCIF = 0;
}
GIE = 1;
}
und in der initialisierung wird RCIE auf 1 gesetzt !
Soweit ich das jetzt beurteilen kann (ich programmiere in Assembler) sollte der Code eigentlich OK sein. Die Abfrage while (TXIF == 0); // PIR1.TXIF könnte eigentlich entfallen. Das ist doch aber nicht der Code, mit dem du die Testreihe durchgeführt hasst oder? Die Routine Antwortet ja nur auf 70,72,74,76 und 78. Oder kommt bei den nichtfunktionierenden Werten kein Interupt?
nein, das ist nicht der exakte code ! ich habe bei diesem code ein paar zahlen rausgenommen, damit er kürzer wird ! aber eigentlich reicht mir eh wenn die hälfte funktioniert, soviele zahlen muss ich eh nicht übertragen ! kennst du dich eigentlich auch mit I2C aus ? weil da hab ich leider auch ein ziehmlcih großes problem !
Nur wenn, dann sollte schon alles funktionieren. Wie gesagt am Quellcode kann ich keinen Fehler feststellen. Gibt es keine Debugmöglichkeit mit der man feststellen könnte welcher Wert in RCREG steht? Mit dem integrierten I²C Modul habe ich bisher auch noch nicht gearbeitet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.