Hallo, für meine Projektarbeit an der FH programiere ich gerade einen PIC 16F876, welcher Kommandos über die RS232 Schnittstelle empfängt und entsprechend die Peripherie regelt. Der PIC ist an einem 13 MHz Oszillator angeschlossen, welcher auch für die restliche Hardware verwendet wird. Der Pegelwandler für RS232 ist ein MAX232. Mein Problem: Schicke ich beispielsweise das Wort "Hallo" an den PIC und lasse es zurücksenden, kommt "HX<1/2" (!/" als ein Symbol" zurück. Allerdings besteht das Problem nur in Richtung PC ==> PIC; mit dem PIC kann ich ganze Romane fehlerfrei zum PC senden. Dann dürfte es ja kein Baudratenfehler sin, oder? Testweise habe ich den im PIC eingehenden String im internen EEPROM ablegen lassen; hier war es auch falsch, der Fehler liegt also irgendwo im Einlesen denke ich. Als Compiler nutze ich den CCS C-Compiler. Schonmal danke für eure Hilfe und noch frohe Weihnachten! Gruss Thomas
Welche Hilfe und wobei? Aber auch dir ein frohes Fest! bye Frank
Hallo Ja, der Fehler liegt beim Einlesen. Das ist ja nun wirklich offensichtlich. Tipp: Bringe das Einlesen richtig zum funktionieren, dann läuft es! Gruss Michael
die Glaskugel ist bei mir zur zeit leider in der Rep bitte poste den Schaltplan und den Quellcode.
Ich glaube Frank meinte ( Betonung auf glaube =) ohne den Code ist es unmöglich beispielsweise einen Softwarefehler zu finden ^^ ansonnsten würde ich mir mal die Leitung vor nehmen also die RXD (vieleicht steck da ja der Wurm drinn) oder wie auch immer die beim PIC heißt die andere Leitung muss ja in Ordnung sein. Gruß Andreas & frohe Feiertage
Thomas wrote: > Allerdings besteht das Problem nur in Richtung PC ==> PIC; mit dem PIC > kann ich ganze Romane fehlerfrei zum PC senden. Dann dürfte es ja kein > Baudratenfehler sin, oder? Aber woll ! Wenn der eine zu schnell sendet, wartet der andere noch aufs Stopbit, während schon das nächste Startbit kommt. Umgekehrt kanns aber gehen, bei Text sind meistens nur die ersten 7 Bits signifikant, d.h. verstümmeltes 8.Bit und Stopbit merkst Du nicht gleich. Versuch mal den Fehler immer unter 1% zu halten. Darüber nimmt die Fehleranfäligkeit merkbar zu und ab etwa 3% geht fast nichts mehr. Peter
gibts von CCS beispiel-code für RS232? CCS hat eben so seine macken bei einigen, fertig zur verfügung gestellten funktionen...
Hallo,
also, hier mein Code:
in der Header - Datei:
#include <16F876.h>
#use delay(clock=13000000)
#fuses NOWDT,HS, PUT, NOPROTECT, BROWNOUT, NOLVP, NOCPD, NOWRT, NODEBUG
#use rs232(baud=19200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=9,BRGH1OK)
In der C-Datei:
char Test[20];
int i;
get_string_neu(Test);
delay_ms(100);
printf(" PIC-Test: Zurücksenden des empfangenen Werts");
printf ("\n");
printf(" ECHO : %s \n", Test);
for (i=0; i<=strlen(Test); i++) // EIngelesenes Wort in EEPROM
{
write_eeprom(i, Test[i]);
}
Das komische ist ja, dass ich eine solche Ein-/Ausgabe auf einem 16F630
bereits programmiert habe und diese dort auch lief! Zwar musste ich für
9600 Baud am PIC 9900 einstellen damit es lief, aber das half hier
nicht!
Gruß Thomas
Thomas wrote: > Das komische ist ja, dass ich eine solche Ein-/Ausgabe auf einem 16F630 > bereits programmiert habe und diese dort auch lief! Zwar musste ich für > 9600 Baud am PIC 9900 einstellen damit es lief, aber das half hier > nicht! Das solltest Du Dir schleunigst abgewöhnen. Nur mit ziellosem Rumprobieren versteckt man den Fehler nur, beseitigt ihn aber nicht. So kannst Du nie stabil funktionierende Programme schreiben. Du mußt als erstes ergründen, warum 9600 nicht funktioniert. Dazu mußt Du im Datenblatt lesen, wie der PIC die Baudrate erzeugt. In der Regel sind nur ganzzahlige Teiler möglich, d.h. bei nicht Baudquarzen ergibt sich unweigerlich ein Fehler und dieser sollte für hohe Zuverlässigkeit unter 1% liegen. Dann kannst Du im Assemblerlisting nachlesen, ob der Code-Wizzard auch den richgtigen Wert eingetragen hat. Ein Code-wizzard kann ja auch Fehler machen. Und wenn die 13MHz nicht quarzstabil sind, kann das auch ne Fehlerquelle sein. Das Datenblattlesen kann Dir keiner abnehmen. Peter
hast du mal die baud-rate beim PC überprüft? zumindest redest du von 9.6k im text und im sourcecode von 19.2k, möglich dass da was nicht stimmt...
Hallo, danke für die Tips, am PC habe ich jeweils die gleiche Baudrate eingestellt wie am PIC; habe es nur versuchsweise auch mal mit 19k2 anstatt 9k6 ausprobiert. In Ordnung, dann werde ich wohl man den Assembler-Code durchgehen, wie die Teiler gesetzt werden. An der Referenzfrequenz von 13 MHz kann es eigentlich nicht liegen, die kommt aus einem temperaturkompensierten Quarzoszillator ;-) (höchstens der wäre defekt ... werde ich nachprüfen; sicher ist sicher). Thomas
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.