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