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 ?
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
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.
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 ?
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
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
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.