PIC liest Befehle über RS232 falsch ein

Thomas Gast #463959
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Andreas Kramer Gast #463974
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter D. #463986
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thomas Gast #464061
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter D. #464082
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thomas Gast #464096
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren