Problem mit EUSART beim PIC18F4520

[Klaus (Gast)]

Hallo zusammen,

an alle PIC-Profis hier: Ich habe ein Problem mit der EUSART beim 
PIC18F4520. Prinzipiell habe ich die Kommunikation über RS232 mit 
19200bps stabil am laufen, allerdings wird als erstes Zeichen nach einem 
Hardware-Reset immer eine 0 ausgelesen. Der Interrupt zum Empfangen 
kommt ganz normal beim ersten Zeichen, aber dieses Zeichen steht immer 
als 0 im RCREG.
Sobald dieses Zeichen durch ist, funktioniert alles wie erwartet, auch 
nach Kommunikationspausen gibt es keine Probleme, es ist immer nur das 
erste Zeichen nach einem Reset, auch wenn der Reset schon etliche 
Sekunden her war.

Hat einer so ein Problem schonmal gehabt, oder weiß so, was ich falsch 
mache?

Gruß
Klaus

[günny (Gast)]

Klingt ja fast nach einem Initialisierungsproblem.
Poste doch mal Deinen code, wie Du die Schnittstelle initialisierst!

gruß

[Paul (Gast)]

Hallo Klaus,

die PIC-EUSARTs weisen so manches merkwürdige Verhalten auf. Je nach 
PIC-Typ und Herstellungsdatum (Jahr und KW steht auf dem Gehäuse unter 
der Typenbezeichnung) gibt es unterschiedliche Verhalten.

Tausche vielleicht mal den Controller gegen einer aus aktueller 
Fertigung. Du kannst ihn als kostenloses Muster direkt über die 
Microchip-Internetseite anfordern.

Vielleicht arbeitet Du auch mit dem REAL ICE mit nicht ganz aktueller 
Firmware und einer älteren MPLAB-Version. Gerade im letzten Update 
wurden in diesem Bereich einige Fehler korrigiert. Alternativ arbeite 
mal mit dem ICD 2.

Ich habe in letzter Zeit einige PICs mit EUSART als serielle 
Schnittstelle programmiert. Zumindest der Datenempfang arbeitete bei mir 
ab dem ersten Byte einwandfrei. Beim Senden sind zwingend die 
Errata-Sheets zu beachten.

Gruß Paul

[Klaus (Gast)]

TriRS232TX = 1;
  TriRS232RX = 1;
  TXSTA = 0x64;  // EUSART senden konfigurieren
      // asysnchron
      // 9-bit
      // high-speed
  RCSTA = 0xF0;  // EUSART empfangen konfigurieren
      // Empfang aktiv
      // Port aktiv
      // 9-bit
  BAUDCON = 0x0A;  // 16-bit Baud-Rate Generator

  SPBRGH = 1;  // 19200bps
  SPBRG = 3;  // 19200bps, 3


  RCIE=1;    //RX Interrupt enable

so initialisiere ich die EUSART

Ich arbeite mit dem ICD2, und das Problem ist sowohl beim debuggen als 
auch mit fest einprogrammiertem Code vorhanden.

[Paul (Gast)]

Hallo Klaus,

Deine Initialisierung macht einen guten Eindruck.

Füge doch mal folgende Zeile in ans Ende Deiner Initialisierungssequenz 
ein:

   movf   RCREG,W

Wenn der Fehler dann immer noch auftritt, hängt das Problem vermutlich 
nicht mit dem Reset und der Initialisierung zusammen.

Auch kannst Du ein Oszilloskop an Deine Schnittstelle halten um zu 
sehen, ob vielleicht nicht doch eine Null als erstes Zeichen gesendet 
wird.

Gruß Paul

[Meister E. (edson)]

Nur mal ne Frage: Wen stört das denn?

Versende Zahlenwerte in ASCII, da ist die Null bei 30h. Meines Wissens 
werden sog. 'Null-Bytes' mit dem Inhalt 00h schlicht ignoriert. Wer das 
bei eigenen Programmen nicht berücksichtigt, fängt sich Fehler ein, das 
ist klar.

Gruss,
Edson

[Klaus (Gast)]

@Paul, das bringt mir leider auch keinen Vorteil und das erste Zeichen 
ist eigentlich immer eine 0x02, weil ich ein 3964-Protokoll abarbeite. 
Das habe ich auch überprüft.

@Meistee Eder
Störend ist nicht die Null an sich, sondern dass das erste gültige 
Zeichen verschluckt wird.

Ich kann mit dem Phänomen leben, da das Protokoll ja den Fehler 
ausbügelt, aber schön ist das halt nicht.

[Paul (Gast)]

Hallo Meister Eder,

> Nur mal ne Frage: Wen stört das denn?

Es gibt Protokolle, da sind auch Nullen gültige Daten. Es gibt weitaus 
mehr Arten der Datenübertragung als nur die Übertragung von 
ASCII-Werten.

Und wer sagt Dir, dass der gesuchte Fehler nur in Bezug auf das Senden 
einer Null Probleme bereitet, sonder auch keine andere Auswirkungen hat?

Es macht für eine saubere Programmierung sehr viel Sinn auftretende 
Fehler zu analysieren um nicht irgendwann mit einem weiteren Effekt des 
Fehlers voll gegen die Wand zu laufen. Das unterscheidet übrigens einen 
guten Programmierer von jemanden, der auftretende Fehler nur irgendwie 
zuschmiert. Fehler kommen oft dann zurück, wenn man es absolut nicht 
gebrauchen kann.

Gruß Paul

[Meister E. (edson)]

>Das unterscheidet übrigens einen guten Programmierer von jemanden, der 
>auftretende Fehler nur irgendwie zuschmiert.

In aller Unbescheidenheit meinst du mit guten Programmierer wohl dich 
selbst, oder? Von zuschmieren kann keine Rede sein, um meine 
Programmierfähigkeiten brauchst du dich auch nicht zu kümmern.

>Es gibt Protokolle, da sind auch Nullen gültige Daten. Es gibt weitaus
>mehr Arten der Datenübertragung als nur die Übertragung von
>ASCII-Werten.

Setzt der TE ein solches Protokoll ein? Was spricht gegen die 
ASCII-codierung, wenn man sichs aussuchen kann?

>Und wer sagt Dir, dass der gesuchte Fehler nur in Bezug auf das Senden
>einer Null Probleme bereitet, sonder auch keine andere Auswirkungen hat?

Stabil laufende Anwendungen, die ausser dem Senden einer unerwünschten 
Null einwandfrei funktionieren. Im übrigen habe ich hier einen 
Sick-Barcodeleser, der ebenfalls gerne Nullen ausspuckt, ohne damit 
einen weiteren Sinn zu verfolgen.

Gruss,
Edson

[NOP (Gast)]

Ich hatte das gleiche Problem

Das erste Byte war immer 0 die gleich darauffolgenden Bytes waren zwar 
nicht mehr 0 sondern einfach Falsch.

Darauf hin habe ich die Initialisierung so gemacht wie es im Datenblatt 
steht (exakte reienfolge). Danach trat der Fehler nicht mehr auf.

Auszug aus Datenblatt

To set up an Asynchronous Transmission:
1. Initialize the SPBRGH:SPBRG registers for the
appropriate baud rate. Set or clear the BRGH
and BRG16 bits, as required, to achieve the
desired baud rate.
2. Enable the asynchronous serial port by clearing
bit, SYNC, and setting bit, SPEN.
3. If interrupts are desired, set enable bit, TXIE.
4. If 9-bit transmission is desired, set transmit bit,
TX9. Can be used as address/data bit.
5. Enable the transmission by setting bit, TXEN,
which will also set bit, TXIF.
6. If 9-bit transmission is selected, the ninth bit
should be loaded in bit, TX9D.
7. Load data to the TXREG register (starts
transmission).
8. If using interrupts, ensure that the GIE and PEIE
bits in the INTCON register (INTCON<7:6>) are
set.